Platform and deployment: Serverless, Cloud Hosted, and self-managed
What this domain covers
Platform and deployment tests whether you know which capabilities exist in Elastic Cloud Serverless, Elastic Cloud Hosted, and self-managed deployments, and how the deployment model changes what an analyst can do in Kibana.
The three models
- Elastic Cloud Serverless runs as projects: Search, Observability, and Security. The platform autoscales, manages shards and replicas, and exposes Kibana with project-level settings. There is no node count, tier topology, or cluster sizing to choose.
- Elastic Cloud Hosted gives you a managed cluster whose topology you select, including hot and warm tiers and availability zones, with managed snapshots and control over ILM, index templates, and most cluster settings.
- Self-managed means you operate Elasticsearch and Kibana yourself, or through Elastic Cloud Enterprise or Elastic Cloud on Kubernetes. Upgrades, snapshots, and capacity are yours.
- Serverless differences worth memorizing: ILM is not configurable, retention comes from data stream lifecycle and project settings; snapshot and restore APIs are not available to you; many cluster-level settings and plugins do not exist; replica counts are managed by the platform.
- Shared across all three: Kibana spaces for isolation, roles and API keys, Fleet and integrations for ingestion, and the same search, observability, and security applications.
Worked example
A twelve-person SOC wants SIEM, endpoint protection, and cases, has no platform engineers, needs ninety days of searchable retention, and must be able to restore one index from a snapshot taken two years ago for a regulator. A Security project in Serverless delivers detection rules, Elastic Defend, cases, and retention without operations work, but it cannot satisfy the restore requirement. Elastic Cloud Hosted with a warm tier satisfies both: managed snapshots plus an ILM policy for the ninety-day search window. The reasoning: the staffing constraint favors a managed model, and the restore requirement is the specific capability that eliminates Serverless.
Traps
Copying an ILM policy into a Serverless project and expecting it to run. Hunting for node stats or shard allocation settings in Serverless. Assuming a rule, dashboard, or data view created in one space appears in another - saved objects are space-scoped. Creating an API key with privileges broader than the creating user's; keys inherit and are capped by the owner's privileges. Treating a Kibana data view as an Elasticsearch index pattern that exists server-side. Upgrading Kibana and Elasticsearch to different versions in a self-managed stack.