Free Elastic Certified SIEM Analyst practice test: 30 questions with answers

Elastic Agent is a single agent that runs integrations and is enrolled and managed centrally through Fleet in Kibana, so policy changes need no file edits on each host. Kibana is the user interface and does not collect host data, Logstash is a server-side transformation pipeline rather than a per-host collector, and an extra Elasticsearch node adds storage without collecting anything.

Elasticsearch is the distributed store and search engine that holds indexed documents in shards and replicas and executes queries and aggregations. Kibana is the interface built on top of that data, Logstash transforms events in a pipeline, and Filebeat ships log files, so none of them stores or searches the indexed data.

An index lifecycle management policy moves backing indices through phases and deletes them when the policy says so, which matches all three requirements. A transform builds summary indices, a snapshot repository stores backups rather than aging data, and a date processor changes timestamp values at ingest time without moving or deleting anything.

Fleet Server is the component Elastic Agents communicate with for enrollment, check-ins and policy delivery, and it connects to Elasticsearch. The package registry only serves integration package definitions, a Logstash output is an optional forwarding path, and a snapshot repository stores backups, so none of them handles agent check-ins.

Elastic Agent and the Beats family, such as Filebeat, run on hosts and send data to Elasticsearch. Kibana saved objects hold dashboards and searches, snapshot repositories hold backups, and index lifecycle policies manage index age, so none of them collect data from sources.

Mapping to destination.ip gives every source the same field name and type, so one rule and one dashboard can cover them. A separate dashboard leaves the data inconsistent, changing to text breaks IP-aware range and CIDR queries, and tags are free-form labels rather than structured values.

@timestamp is the ECS field that records when the event occurred, and it is the usual time field for time-based views. event.module names the integration that produced the event, while host.name and user.name identify a machine or an account, so none of them can drive a time axis.

event.category gives the broad group of the event, such as authentication or network, and event.type gives its subtype, such as start or connection. Source port, process ID and file size are attributes or measurements of an event, not its classification.

event.outcome records the result of the event in a standard form such as success, failure or unknown. event.action names what happened, log.level holds the severity reported by the logger, and event.category gives the broad type of event, so none of them states success or failure.

ECS asks that fields it does not define sit under a namespace owned by your product or organization, so they cannot collide with fields added to ECS later. Reusing an ECS name with a different meaning causes conflicts, camelCase breaks ECS's lowercase snake_case convention, and event.original is meant for the raw unmodified record.

KQL uses field : value pairs, quotes for an exact phrase, an asterisk for wildcards and lowercase and for combining conditions, so this query returns the intended events. The first two use operators such as ==, = and LIKE that KQL does not accept, and the third joins the conditions with or where the scenario needs and.

A negated filter removes matching documents from the results and appears as a pill that can be switched off or deleted. A broader time range only changes the period, a sort changes the order, and an added column changes what is displayed, so none of them excludes documents.

Adding and removing columns changes only which fields are displayed, and the matching documents stay the same. Filter pills, time range changes and new KQL queries all change which documents match, so they are not correct here.

A saved search keeps the query, filters, selected columns and sort so the same raw-event view can be reopened or added to a dashboard. A Lens table shows aggregated values rather than individual events, an ingest pipeline changes documents as they arrive, and a mapping snapshot stores no search settings.

A data view points Discover at one or more indices or patterns and names the time field used by the time picker. An index template only supplies settings to newly created indices, a Kibana space groups saved objects for access, and a runtime field computes a value at query time without choosing indices.

A terms bucket groups documents by distinct source.ip values and sorts them by count, which gives the top sources. A date histogram groups by time rather than by address, cardinality counts unique values without ranking them, and an average of event.duration measures something unrelated to which addresses fail most.

Metric aggregations calculate numbers such as counts, sums, averages or unique counts, while bucket aggregations are the ones that split documents into groups. The time range comes from the time picker and shard routing is handled by Elasticsearch, so neither is a metric's job.

Lens is Kibana's drag-and-drop visualization editor and suggests suitable chart types from the fields chosen. Dev Tools sends raw API requests and returns JSON instead of a chart, Vega requires writing the specification by hand, and a Logstash pipeline transforms events rather than drawing charts.

Text fields are analyzed for full-text search and are not suited to aggregation, so aggregating on a keyword version of the value is the standard fix. Enabling fielddata loads terms into heap memory and is a costly workaround, a table with no buckets does not fix the aggregation, and more primary shards changes data distribution, not the field type.

A date histogram groups events into fixed time intervals, and a count metric per bucket gives the failures per hour for the line chart. A terms bucket groups by user name rather than by time, cardinality counts distinct hosts without a time axis, and a range bucket on duration groups events by how long they took.

An options list control on host.name gives a dropdown that filters every panel using that field, so viewers can switch hosts without editing anything. A markdown panel only displays text, copies per host multiply maintenance work, and fixed filters inside each panel cannot be changed by viewers.

The Inspect option on a panel opens the underlying data together with the request and response, which helps explain unexpected numbers. Cloning duplicates the panel, a drilldown navigates elsewhere on click, and maximizing only enlarges the display without exposing the query details.

Dashboards group saved visualizations and searches so one view answers several questions, and dashboard filters and the time range apply across the panels. Dashboards do not create detections or change alert status, and they store saved objects rather than a separate event store.

A panel only shows events inside the active time range and from the indices its data view covers, so those are the first things to check. Restarting Kibana, moving the dashboard to a different space or renaming a panel does not change which events the query can see.

Drilldowns let a panel navigate to another dashboard or a URL when it is clicked, which is what this scenario needs. Dashboard controls filter the panels on the current screen, exported images are static reports, and refreshing a data view only reloads its field list.

A threshold rule raises an alert when the number of matching events reaches a set count within a time window, grouped by a field such as the user name, which fits this case. Machine learning rules rely on anomaly jobs rather than fixed counts, new terms rules flag first-seen values, and indicator match rules check events against threat intelligence entries.

A timeline collects related events and alerts into one investigation workspace that can be saved and shared. Exception lists suppress matches for detection rules, an ingest pipeline transforms documents as they arrive, and an index lifecycle policy controls how indices age.

Cases gather alerts and saved timelines together with comments and status so a team can work an incident in one place. Ingest pipelines, index lifecycle policies and Fleet agent policies are stack configuration objects and are not attached to cases.

An exception keeps the rule active everywhere else while suppressing only the approved activity, which is the targeted fix. Disabling the rule removes coverage across the environment, lowering severity still produces alerts, and deleting alerts hides the noise without stopping new matches.

Elastic AI Assistant uses a configured generative AI connector to explain alerts and suggest next steps inside the Security app. Snapshot restore recovers index data rather than summarizing alerts, a Fleet policy configures agents, and index sorting changes how documents are ordered inside an index.