Elastic Certified Analyst cheat sheet
Elastic Certified Analyst · Keep the key ideas within reach.
Search and AI: Vector, Hybrid Search, Reranking, RAG
dense_vector fields support element_type float (default) and byte; dims is required and must match the embedding model's output dimension exactly, or indexing fails.
similarity options for dense_vector: cosine, dot_product, l2_norm, max_inner_product, and (newer versions) cosine with quantized storage. For dot_product and cosine, vectors are normalized at index time; for max_inner_product they are not.
kNN search uses the approximate HNSW graph via "knn" in _search with k, num_candidates, and filter; num_candidates controls the per-shard candidate pool and trades recall against latency.
Hybrid search combines lexical (BM25) and kNN results; in the retriever framework use rrf (reciprocal rank fusion) or linear combination with weights and optional minmax normalization.
RRF ranks documents by sum of 1/(rank_constant + rank) across retriever result lists; default rank_constant is 60. It needs no score normalization, so it is robust when BM25 and cosine scores are on different scales.
text_similarity_reranker re-scores the top-k of an existing retriever using a cross-encoder inference endpoint; it improves precision at the cost of latency and requires an ML model deployed via Eland.
In the Elasticsearch open inference API, a semantic_text field plus an inference_id handles chunking, embedding, and query-time inference automatically; the inference endpoint must exist before mapping is created.
RAG patterns retrieve top-k chunks, then pass them to a completion endpoint (e.g., an OpenAI, Bedrock, or Elastic-hosted model) as context; the _stream_completion or completion inference task supplies the generation step.
Vector quantization: int8_hnsw, int4_hnsw, and bbq_hnsw reduce memory; quantized vectors require rescoring unless you accept approximate scores, and rescore_vector oversampling multiplies candidates before rescoring.
Observability: Logs, Metrics, Traces, APM
Data streams are the write target for observability: logs--, metrics--, traces--; backing indices roll over by index.lifecycle.rollover_alias or the data stream's lifecycle.
ILM phases hot → warm → cold → frozen → delete; frozen uses partially mounted searchable snapshots, so queries there are slower and need shared cache.
Metrics use time-series data streams (time_series_dimension and time_series_metric mapping params) with TSDS index mode, enabling rate aggregation and downsampling.
ES|QL is the piped query language (FROM ... | STATS ... BY ... | SORT ...); it supports LOOKUP JOIN for enrichment and is available in Discover and alerting rules.
APM stores transactions, spans, errors, and service metrics; service maps and the service inventory derive from span destination data and transaction aggregates.
SLOs are defined in Kibana with an indicator (APM latency/availability, custom KQL, or timeslice metric), a target, and a time window; error budget burn rate alerts fire when consumption outpaces the objective.
Alerting rules run on a schedule with a rule type (e.g., ES query, index threshold, APM anomaly); the rule evaluates against a data view and triggers actions through connectors such as Slack, PagerDuty, or webhook.
Logs threshold alerts and anomaly detection jobs (single metric, multi-metric, population) write results to .ml-anomalies-* indices, which can be queried directly or surfaced in Kibana.
Synthetic monitors run lightweight heartbeat checks (browser or HTTP/TCP/ICMP) from global or private locations; uptime data lands in heartbeat-* data streams.
Security: SIEM, Endpoint Protection, Native Automation
Detection rules in Elastic Security are either query rules (KQL/EQL/ES|QL) or threshold rules; rule types include custom query, machine learning, indicator match, new terms, and event correlation.
Alerts generated by detection rules are stored in .alerts-security.alerts- and are visible in the Alerts page; alert status values are open, acknowledged, and closed.
EQL is designed for ordered event sequences (sequence by ... with maxspan) and process ancestry checks; it operates on event categories such as process, network, and file.
Elastic Defend (endpoint protection) provides malware prevention, ransomware protection, memory threat protection, behavior protection, and event capture; policies are managed per integration policy.
The endpoint response actions include isolate host, kill process, and suspend process; isolate host uses an Elastic-managed network policy and requires the endpoint to check in with Fleet.
Indicator match rules join source events to threat intelligence indices (e.g., threat intel filebeat integrations) using indicator fields such as file.hash.sha256 or destination.ip.
The Elastic Security attack discovery and AI assistant features use an LLM connector configured in Kibana; no data leaves the deployment unless the connector is external.
Osquery and Beats-based integrations feed host telemetry; Fleet manages Elastic Agents centrally, and agent policies determine which integrations and data streams are collected.
Cases group alerts with attachments, comments, and connectors (e.g., Jira, ServiceNow); case templates automate field population for consistent triage.
Platform and Deployment: Serverless, Hosted, Self-Managed
Elastic Cloud Serverless offers project types: Elasticsearch (search), Observability, and Security. Serverless abstracts cluster sizing; you set project-level capacity and it scales automatically.
Serverless has no direct cluster API access for some operations (e.g., no ILM configuration, no node-level settings); data lifecycle is managed by the platform via data stream lifecycle.
Elastic Cloud Hosted (ECH) gives you a managed cluster with configurable topology (hot/warm/cold/frozen tiers), version upgrades, and snapshot management; you retain ILM control.
Self-managed deployments run on your infrastructure; you manage JVM heap, master eligibility, shard allocation, snapshots, and upgrades yourself.
Elastic Cloud Enterprise (ECE) and Elastic Cloud on Kubernetes (ECK) are orchestrators for private deployments; ECK uses Kubernetes custom resources such as Elasticsearch, Kibana, and Beat.
Snapshot repositories (S3, GCS, Azure, or shared filesystem) are required for backups; in ECH the platform manages snapshots, but you can register additional repositories.
API keys, roles, and role mappings control access; in Serverless, project-level roles are managed in the Cloud console, while API keys are created via the Security API.
Cross-cluster search and cross-cluster replication connect clusters; in Serverless, remote clusters must be configured through the project settings and are subject to platform limits.
Upgrades: ECH supports in-place minor/patch upgrades and full-cluster upgrades for major versions; self-managed requires a rolling restart with shard allocation disabled and then re-enabled.