Elastic Security Architecture, Deployment, and Space Configuration
The moving parts
Elastic Security is a Kibana application on top of an Elasticsearch cluster. Elasticsearch stores event data, detection rule configuration, generated alerts, and cases; Kibana hosts the Security app UI and, critically, runs the detection engine using the Kibana Alerting framework. That last point drives many exam items: detection rules execute on Kibana nodes, so Kibana availability, memory, and task capacity directly determine whether rules run on schedule. Fleet Server (usually a separate Elastic Agent) manages the enrolled agents that ship data.
Spaces as multi-tenancy
A Kibana space is a UI/configuration partition, not a data partition. Detection rules, rule exceptions, Timelines, data views, and alert documents are space-scoped - alerts are written to an index named for the space, e.g. .alerts-security.alerts-default. Raw event documents in ordinary data streams are not space-scoped; a user in Space A can query indices from Space B if their role grants index privileges. Cases are an exception to the pattern: in current versions the Cases app is shared rather than siloed per space, which is a favorite trap.
Authorization and deployment traps
Access requires Elasticsearch security enabled, matching Elasticsearch/Kibana versions, and roles that combine Kibana feature privileges (Security, Fleet, Discover) with Elasticsearch index privileges. A user who can see the Alerts page but not read the alerts index sees an empty table - check privileges, not the rule. Also check whether a rule was created in a space the analyst is not in, and whether a cluster is a single node (no resilience for rule execution) versus a multi-node deployment behind a load balancer (Fleet enrollment and Kibana base URL must be reachable by agents).
Rule of thumb: when a detection "doesn't exist" for one analyst, first verify the active space and the analyst's privileges - data is rarely the problem.