Elastic Certified Analyst common mistakes
Elastic Certified Analyst · Understand the traps and how to avoid them.
When a question asks about semantic retrieval, the candidate just creates a dense_vector field and runs a plain knn search, then treats that as a complete answer without considering the query's filter context or the need for lexical recall.
Elastic's kNN search is the loudest feature in the docs, so candidates reach for it first. They forget that pure vector search can miss exact identifiers and rare terms, and that filters inside a kNN query interact with num_candidates and the top-k budget in ways that change results.
What to do instead
For semantic-retrieval questions, explicitly decide between pure kNN, a filtered kNN, and a hybrid query. Practice the hybrid pattern: a lexical match or query_string branch plus a knn branch combined under a single rrf or linear retriever/score combiner, and be ready to explain why you would pick one. Know that in filtered kNN, num_candidates must be considered per shard and that the filter is applied during the ANN search, not after top-k.
The candidate describes RAG as 'index documents, embed them, ask the LLM' and stops there, omitting chunking strategy, the retrieval step's configuration, and how the retrieved passages are passed to the model.
RAG questions look conceptual, so candidates answer at the level of a blog post. The exam expects the Elastic-specific pieces: the inference endpoint used to generate embeddings, the ingest pipeline that calls it, the index mapping, and the search template that assembles context.
What to do instead
Structure every RAG answer as four concrete stages: (1) ingest with an inference processor in an ingest pipeline that writes the embedding field, (2) chunking decisions (size, overlap, whether to store parent text separately), (3) retrieval (kNN or hybrid plus metadata filters), (4) prompt assembly with retrieved passages and citation metadata. Be able to name the inference service/endpoint concept and explain where it sits in each stage.
When asked to improve result quality, the candidate proposes a reranking model but cannot say what it reranks, how many candidates it receives, or where it sits relative to the initial retrieval.
Reranking is often learned as a buzzword. Candidates conflate it with boosting or with the initial kNN, and they miss that a reranker takes a bounded candidate set from a first-stage retriever and reorders it, so the first-stage recall ceiling still applies.
What to do instead
Learn the two-stage pattern precisely: first stage retrieves N candidates (kNN, BM25, or hybrid), second stage reranks that window with a cross-encoder-style model exposed through an inference endpoint, then top-k is returned. Be able to explain that widening the first-stage window improves recall but costs latency, and that reranking cannot recover documents the first stage never returned.
The candidate answers an observability question by naming the right UI area (for example, 'use the APM app') but cannot describe the underlying documents, fields, or data flow that make the view work.
The Kibana apps are visually memorable and easy to describe; the index templates, data streams, and ECS field names behind them are not. Exam questions often probe the data model rather than the screen.
What to do instead
For each observability pillar, memorize the backing data stream or index pattern and the key ECS fields: logs (data_stream.dataset, log.level, message), metrics (metricset.name, system.cpu.total.pct style fields), traces (trace.id, transaction.id, span.id, transaction.duration.us), and APM service metadata (service.name, service.environment). Practice explaining how a trace view is reconstructed by correlating trace.id across documents.
The candidate treats logs, metrics, and traces as three separate silos and, when asked to troubleshoot an incident, jumps straight to log search without using service maps, trace latency breakdowns, or metric anomalies to localize the problem first.
Log search is the most familiar workflow, so candidates default to it. They miss questions that test whether they can move from a symptom (a latency SLO breach) to the responsible service and then to the specific span or log line.
What to do instead
Practice a fixed triage order: alert or SLO breach, then service map or APM service overview to find the degraded service, then trace analysis to find the slow span, then correlated logs for that trace.id or service. Be able to describe how you would pivot from a metric spike to the exact trace and back, and what field values you would filter on at each step.
On SIEM questions, the candidate writes a detection rule that works but never addresses alert deduplication, rule scheduling/lookback windows, or how the rule's findings are triaged and tracked.
Candidates focus on the query logic because that is the technical core. The operational wrapper (how often the rule runs, what window it looks back over, how duplicate alerts are suppressed, how exceptions are handled) is where real detection engineering lives and where exam questions concentrate.
What to do instead
For every detection rule you describe, state the rule type (query, threshold, indicator match, EQL sequence, or new terms), the schedule interval, the additional look-back window, and the deduplication or suppression strategy. Explain how exceptions reduce noise and how a case or alert workflow closes the loop. Know when a sequence rule (EQL) is required versus a simple query rule.
The candidate describes endpoint protection as 'install the agent' and cannot explain prevention versus detection policy layers, event collection, or how response actions are executed and audited.
Endpoint security is often studied at the marketing level. The exam expects the distinction between malware prevention, ransomware protection, memory protection, behavioral protections, and the event stream those produce, plus how response actions are authorized.
What to do instead
Break endpoint answers into layers: prevention policy settings, detection/behavioral rules, the event and alert data those generate, and response actions (isolate host, kill process, etc.) with their audit trail. Be able to explain how endpoint events flow into the SIEM and how an analyst moves from an alert to a host's timeline.
When asked to automate a security workflow, the candidate describes an external script calling the API instead of using native automation constructs such as detection rule actions, connectors, and case workflows inside the platform.
Engineers instinctively reach for code. The exam tests whether you know the built-in automation surface: rule actions with connectors, alert suppression, and case management hooks, and where those are preferred over custom glue.
What to do instead
Map each automation need to the native primitive first: connector types for notifications and ticketing, per-rule actions, alert-to-case promotion, and case templates. Only fall back to API scripting when the native primitive cannot express the logic, and be ready to justify that choice and describe how the automated action is logged.
The candidate answers deployment questions with generic cloud advice and cannot distinguish what is managed for them in Elastic Cloud Serverless versus Elastic Cloud Hosted versus self-managed, particularly around scaling, upgrades, and index lifecycle.
The three deployment models share a UI, so candidates assume the operational responsibilities are identical. Questions that hinge on who owns shard sizing, version upgrades, or tier configuration then get vague answers.
What to do instead
Build a comparison table you can reproduce from memory: in Serverless, capacity and scaling are abstracted and you work with projects and their data; in Hosted, you choose deployment topology, hardware profiles, and availability zones while Elastic manages the platform; self-managed puts orchestration, upgrades, and cluster design on you. For each model, state who owns version upgrades, scaling, snapshots, and ILM/retention decisions.
The candidate gives a deployment answer that ignores the security and networking prerequisites: authentication method, role-based access, private connectivity, and how the deployment is reached from the client.
Deployment questions feel like capacity and topology questions, so access control and network paths get skipped. In practice, most failed deployments fail on authentication, TLS, or connectivity, and the exam reflects that.
What to do instead
For every deployment scenario, add an access layer: which authentication mechanism (native realm, SSO/SAML, API keys for programmatic access), which roles or role mappings apply, and how traffic reaches the cluster (public endpoint, private link, or VPC peering). State how you would verify the path end to end before declaring the deployment complete.