What does Elastic Cloud manage for you, and what stays your responsibility?

## Why this question gets asked Interviewers use the buy-vs-run framing to find out whether a candidate has actually operated a cluster or has only used one. The tell is whether you can name the seam accurately in both directions: what genuinely disappears from your plate, and what stubbornly does not. This answer assumes hosted Elastic Cloud deployments running Elasticsearch 8.x/9.x; the Serverless offering moves the line further toward the provider and is discussed at the end. ## What Elastic runs for you **Provisioning and topology.** You describe a deployment as sizes per component — hot tier, warm tier, cold and frozen tiers, Kibana, machine-learning nodes, an integrations server — and choose how many availability zones each spans. The platform creates the instances, configures discovery, and adds dedicated master-eligible nodes as the deployment grows rather than making you plan them. **Endpoints and TLS.** Each deployment gets a stable HTTPS endpoint with a valid certificate. You never manage node certificates, keystores, or the transport-layer security configuration between nodes. **Hardware failure.** When an instance dies, the platform replaces it and the cluster recovers shard copies onto the new node. This is why you address the deployment endpoint and never a node. **Backups.** A hosted deployment gets a managed snapshot repository backed by object storage (named `found-snapshots`) and an automatic snapshot lifecycle policy, so a baseline backup exists without you configuring one. **Version upgrades.** Selecting a new version triggers an orchestrated rolling upgrade — node ordering, restarts, and health checks are the platform's job. **Scaling mechanics.** Resizing a tier is a plan change: the platform grows instances or adds them and rebalances. Autoscaling can raise data-tier capacity as storage demand grows, and can move machine-learning capacity in both directions. ## What stays yours **Mappings and analysis.** Field types, multi-fields, analyzers, `dynamic` behaviour and the field-count budget are entirely your design. A mapping explosion from unbounded dynamic fields is your outage, not the provider's. **Shard strategy.** Primary shard counts, index sizing, rollover thresholds and the resulting shard-per-node density are yours. Oversharding is the single most common self-inflicted problem on managed clusters, and no amount of paid infrastructure fixes it. **Lifecycle policy.** ILM runs inside Elasticsearch, but the policy — when to roll over, when to move to warm, when to force-merge, when to delete — is authored by you, and it is what makes tiered storage cost-effective. **Queries and relevance.** Query shape, filter-context usage, aggregation cost, pagination strategy and relevance tuning are application concerns. Slow searches on a managed cluster are almost always query or mapping problems. **Security inside the cluster.** Roles, document- and field-level security, API keys and their scoping and rotation are yours. So is deciding on traffic filters — a hosted endpoint is internet-reachable until you restrict it with IP allow-lists or private-link connectivity. **Client behaviour.** Bulk sizing, retry-and-backoff on `429`, and circuit-breaking in the application belong to you. **Cost.** The service makes capacity a slider, which makes overspending easy. Right-sizing tiers and retention is an ongoing task with no automated substitute. ## Where the boundary bites The restrictions are the part candidates forget. There is no shell on the nodes. JVM options are not user-settable — heap follows the instance size you choose. `elasticsearch.yml` is editable only through the user-settings field, and only for allow-listed settings that vary by version. Plugins cannot be dropped onto the filesystem: supported plugins are selected from a list, and custom artifacts such as synonym or stopword dictionaries are uploaded as extensions and referenced from analyzers. If your design depends on a bespoke native plugin or a kernel-level tuning knob, the hosted service is the wrong shape and you should say so. ## Middle options and Serverless Between "fully hosted" and "you run everything" sit Elastic Cloud Enterprise, which brings the orchestration layer onto your own hardware, and Elastic Cloud on Kubernetes, an operator that manages clusters as custom resources in your own Kubernetes estate. Both hand back infrastructure control while keeping some of the orchestration benefit. Elastic Cloud Serverless goes the other way: it removes node and shard sizing from the user entirely, so the responsibility line sits further toward the provider than in a hosted deployment. Be explicit about which model you are describing, because the answer differs. ## How to answer Name three or four items on each side, then state the principle: managed hosting removes the operations that scale with node count, and removes none of the design decisions that scale with data and query volume.