Elasticsearch Interview Questions for 2026

Answer: A distributed search and analytics engine built on Lucene. It stores documents as JSON, indexes their fields into inverted indexes plus column-oriented doc values, and spreads the work across a cluster so search and aggregation scale horizontally. It is not a primary database: no joins, no cross-document transactions, and visibility is near real time. Framing it as a Lucene-backed distributed document store rather than a NoSQL database is the precision most Elasticsearch interview questions at this level are checking for.

Answer: The unit of storage and sharding: a logical namespace holding a set of documents, physically split into primary shards, each a self-contained Lucene index with optional replica copies. You create it with a mapping and settings, read and write it over HTTP, and in production you usually reach it through an alias instead of its raw name. Name indices like code, lowercase and patterned, because renaming later means reindexing, a surprise that opens most follow-up Elasticsearch interview questions about index management.

Answer: A document is one JSON record, the unit Elasticsearch indexes, scores, and returns. It lives in exactly one primary shard, identified by a _id you supply or the system generates, plus metadata like _index and _version. Field types come from the mapping, so the same JSON can land as text, keyword, or date depending on configuration. Documents are immutable: an update is really a delete-mark plus a reindex with a bumped version.

Answer: The structure that makes search fast. Instead of scanning every document for a word, Elasticsearch analyzes each text field at index time and builds a dictionary mapping every unique term to the list of documents containing it, with positions for phrase queries. Lookup becomes a dictionary hit instead of a scan. Nearly every Elasticsearch interview question about relevance, analyzers, or performance bottoms out here, so be ready to sketch it.

Answer: One Lucene instance: the physical unit of storage, indexing, and search parallelism. An index is split into primary shards at creation time, and that count is fixed for the index’s life; each primary can carry replica copies. Searches fan out across shards and merge, which is why shard count decides both parallelism and overhead. Keep primaries in the 10 to 50 GB range instead of sprinkling thousands of tiny ones, because every shard carries fixed heap and file-handle cost. That sizing instinct anchors the later Elasticsearch interview questions, so get the vocabulary right here.

Answer: A full copy of a primary shard kept on a different node. It serves two jobs: high availability, since the cluster promotes a replica when the primary’s node dies, and read throughput, since searches can hit any copy. Replica count changes at any time with one settings call, unlike the primary count. Zero replicas means one node loss turns the index yellow or red, so production keeps at least one, and keeping primary versus replica roles straight is required in every tier of Elasticsearch interview questions.

Answer: Green means every primary and every replica shard is allocated. Yellow means all primaries are fine but some replicas are unassigned: data is safe, redundancy is reduced, the classic state of a single-node cluster asked for replicas. Red means at least one primary is unassigned, so part of an index is missing until that shard recovers. Stating that mapping precisely is what separates candidates on Elasticsearch interview questions about cluster health.

Answer: One Elasticsearch server process, identified by a name and one or more roles: master-eligible, data-holding, ingest-capable, coordinating-only. Small clusters run every role on every box; larger ones split roles so heavy searches cannot starve master elections. A node joins a cluster by sharing its cluster name and reaching the seed hosts, then discovery does the rest. Roles are the gateway into the topology half of Elasticsearch interview questions.

Answer: The schema for an index: it declares each field’s type and how it is indexed. text fields are analyzed into the inverted index, keyword fields stay exact for filters and aggregations, dates and numbers get range structures plus doc values. Define it explicitly, ideally through a template before the first write, because the mapping decides which queries are even possible. Adding new fields is fine; changing an existing field’s type requires reindexing, the constraint behind many practical Elasticsearch interview questions.

Answer: By default, indexing a document with an unknown field makes Elasticsearch guess a type and add the field: strings often become text plus keyword, numbers become numeric. Convenient, and dangerous with noisy data, because thousands of invented fields bloat the mapping and cluster state and lock in wrong guesses. Control it with dynamic strict to reject unknown fields, false to ignore them, or explicit templates. Uncontrolled inference is the root of the mapping-explosion stories that anchor the scenario tier.

Answer: The pipeline that turns raw text into index terms: character filters tidy the string, a tokenizer cuts it into tokens, and token filters normalize them, lowercasing, stripping stopwords, stemming to roots. Every text field uses one, the standard analyzer by default, with language and custom analyzers available. Know the _analyze API, since it shows exactly which terms a field produced. When a match query misses a document you expected, the analyzer is the first suspect, which is why analyzers surface in Elasticsearch interview questions at every tier.

Answer: text fields are analyzed and matched term by term, built for full-text relevance. keyword fields are stored whole as a single exact term, built for filters, term queries, sorting, and aggregations. A product description searched by words wants text; a status code filtered by equality wants keyword; common practice indexes one field both ways with multi-fields. Naming which side serves relevance and which serves exactness is the whole answer to this staple of beginner Elasticsearch interview questions.

Answer: It runs your input through the field’s analyzer and builds a boolean OR of the resulting terms, each scored for relevance, so quiet server room matches documents containing any of those words, ranked best first. operator and requires every term, fuzziness tolerates typos. It is the default tool for searched prose. Knowing that match analyzes its input explains most surprises about why it matched too much, and that insight is what the follow-up hunts.

Answer: It matches one exact term in the inverted index, with no analysis of your input and no scoring. The classic surprise: a term query for Quiet against a text field returns nothing, because the stored tokens were lowercased at index time, while quiet matches. Term-level queries belong on keyword fields, ids, statuses, enums. That trap is one of the most reliable openers in Elasticsearch interview questions at every level.

Answer: The workhorse combiner. must holds conditions that contribute to the score, should adds optional terms that raise scores, filter applies yes-or-no conditions with no scoring at all, must_not excludes. Because filters skip scoring they are cacheable and cheap, so the production pattern is score only the prose in must and put everything structural, status, date ranges, tenant, in filter. Reciting that split convincingly answers the unasked follow-up, and the filter-first habit is what Elasticsearch interview questions about query cost are really testing.

Answer: match matches the analyzed terms independently, anywhere in the field; match_phrase requires them adjacent, in order, consulting the indexed positions, with slop allowing small rearrangements. It costs more because positions are read, but it is the tool for quoted-style searches, names, and error messages where word order carries meaning. Use match for recall, match_phrase for precision, or combine both under should so phrase hits rank higher.

Answer: _source is the original JSON stored with every document and returned on every hit. It powers reindexing, updates, and highlighting, so disabling it is rare and usually regretted. The everyday move is source filtering: request only the fields a page needs, which cuts payload and deserialization cost on wide documents. If someone proposes disabling _source to save disk, the counter is that reindexing and updates become impossible without re-feeding every document.

Answer: The relevance number each hit receives from the ranking function, BM25 by default, combining how rare the term is across the index, how often it appears in this document, and how long the field is. Higher is more relevant, and scores are only comparable within one query. Sorting by anything else drops them entirely. Naming BM25 and its three intuitions is the expected depth in current Elasticsearch interview questions, even at this tier.

Answer: from skips hits and size returns a page, and every shard must build from plus size hits so the coordinating node can merge and discard, so page 500 at size 100 makes each shard produce 60,000 results. The cluster caps from plus size at 10,000 by default for exactly that reason. From and size serves the first few pages humans read; deep iteration belongs to search_after, which the intermediate tier covers properly. Pagination cost is a favorite checkpoint in Elasticsearch interview questions because it exposes the distributed merge model.

Answer: The _bulk API takes many index, create, update, and delete actions in a single HTTP round trip, amortizing per-request overhead and letting clients tune throughput independently of the cluster. Real ingestion runs through bulk almost exclusively, sized by experiment, commonly in the single-digit megabytes. Results come back per action, because some succeed while others fail. Knowing that bulk bodies are NDJSON, one action per line, is the detail the next question drills.

Answer: The parser streams each line without holding the whole payload in memory, so no newline may appear inside a JSON object and the final line needs its terminating newline. It feels hostile until you connect it to streaming: Elasticsearch can parse incrementally and report per-action failures without buffering gigabytes. Most first bulk errors are a missing trailing newline or a pretty-printed document, which the format forbids by design.

Answer: A stable name pointing at one or more indices, so clients never hardcode physical index names. Aliases are the mechanism behind zero-downtime reindexing, daily index patterns, and ILM rollover, where the write alias moves to the new index atomically. They can also carry filters for per-tenant views. Decoupling the logical name from physical storage is the point, and it is why seniors create the alias before the data, a habit worth naming in Elasticsearch interview questions.

Answer: GET _cluster/health returns green, yellow, or red with node, shard, and unassigned counts; deploy scripts add wait_for_status=yellow and a timeout so the pipeline blocks until the cluster is ready. Follow immediately with GET _cat/shards?v to see which shards are unassigned and why, and GET _cat/nodes?v for heap and disk reality. Health plus shard listing resolves most status questions, and that pairing opens nearly every operational block of Elasticsearch interview questions.

Answer: A family of plain-text views over cluster internals: _cat/nodes for heap, CPU, and disk, _cat/indices for document counts and sizes, _cat/shards for every shard’s location and any unassigned reason, _cat/allocation for per-node balance, _cat/thread_pool for rejected search or write threads. Add ?v for headers and h= to pick columns. It is the fastest triage surface on any cluster and the working vocabulary of scenario rounds.

Answer: How often each shard flushes its in-memory buffer into a new searchable segment, one second by default, which is why Elasticsearch calls itself near real time. Set it to -1 during heavy bulk loads and restore it afterward, or raise it to 30s on write-heavy log indices to cut segment churn. It is per-index and dynamic, changed with one settings call, and it controls visibility, never durability, a distinction Elasticsearch interview questions love to probe.

Answer: PUT /index/_doc/1 with an explicit _id overwrites whatever existed and bumps the version. POST /index/_doc lets the system generate a unique _id, which avoids collisions for event-style data. To make a write fail rather than overwrite, use op_type=create or the _create endpoint. The operational point: explicit IDs make re-sent events idempotent, generated IDs make them append-only, and choosing between them is a data-model decision, not syntax trivia. ID semantics like this recur in Elasticsearch interview questions about event pipelines.

Answer: The old document is marked deleted, the new one indexed, and the version increments; there is no merge or patch, because updates are delete-and-reindex under the hood. With optimistic concurrency you send if_seq_no and if_primary_term from the version you read, and the write fails with a conflict if anything changed meanwhile. That compare-and-set loop is how safe read-modify-write flows get built against a search engine.

Answer: The value hashed to pick which primary shard holds a document, the _id by default, so everything with the same routing lands on the same shard. A search that carries the routing value hits only that shard, which is how multi-tenant systems slash query fan-out by routing on tenant ID. Routing is fixed at write time, so changing it later means reindexing, and searching with the wrong routing silently reads only part of the data.

Answer: It runs a query and marks every matching document deleted, version by version, across all shards. Space is not reclaimed until segment merges collect the tombstones, and the task competes with live traffic the whole time, so it is heavy maintenance, not routine cleanup. Right for GDPR purges and bad-batch removals; wrong for repeatedly deleting what you just wrote, which usually means retention belongs in ILM’s delete phase instead.

Answer: GET /index/_count runs a cheap count query, and GET _cat/indices?v shows docs.count beside size and health in one table, the faster glance during incidents. Expect small discrepancies during heavy writes, because _cat reads periodically updated stats while deleted-but-unmerged documents count differently across endpoints. For a filtered count, _count accepts the same query DSL as search, which makes it the verification tool after delete_by_query runs.

Answer: GET /index/_doc/id reads from the shard’s live storage engine, including documents not yet refreshed, so yes, single-document lookups are real time. Searches only see refreshed segments, which is the near-real-time gap. A write followed by an immediate GET succeeds while an immediate search may miss, and explaining that asymmetry, lookup reads live, search reads segments, is the entire point of this question.

Answer: The analytics half of Elasticsearch: a query that groups and computes over matching documents instead of listing them. Buckets group, metrics compute values per group, and pipeline aggregations compute over other aggregations, like average latency per service per hour. Aggregations read doc values, the column-oriented structures, so they stay fast without touching _source. They are the reason Elasticsearch doubles as a log analytics engine and not just a search box.

Answer: Bucket aggregations partition documents into groups: terms for categories, date_histogram for time, range for numeric windows. Metric aggregations compute a value per group: avg, sum, max, cardinality, percentiles. They nest, buckets defining the shape and metrics filling it in, and pipeline aggregations form the third kind, operating on other aggregations’ outputs for derivatives and cumulative sums. Naming all three kinds with one use each is a complete beginner answer.

Answer: Elasticsearch is the search and storage engine at the center. Beats ship logs and metrics from the edge, Logstash or Elasticsearch’s own ingest pipelines parse and enrich, and Kibana is the UI for searching, dashboards, and administration. Knowing which layer owns which job matters operationally: parsing at ingest, storage and scoring in Elasticsearch, visualization in Kibana. Interviewers use that split to tell people who operated the stack from people who installed it once.

Answer: Different engines for different questions. Elasticsearch shards horizontally, scores by relevance, and answers full-text and analytics queries in milliseconds, but offers no joins, no multi-document ACID transactions, and near-real-time visibility. Relational databases own transactions and referential integrity but scan indexes built for exactness, not tokenized text. Keep the system of record in a database, denormalize into documents in Elasticsearch, and treat the index as derived state you can rebuild. That division of labor is the expected shape of Elasticsearch interview questions on this comparison.

Answer: A definition that applies settings and mappings to new indices matching a pattern, so logs-2026.09.26 gets the right shard count, replicas, and field types automatically at creation. Modern clusters use composable index templates referencing component templates, with priority deciding which wins on overlap, and data streams plus ILM depend on templates for rollover. Write the template before the first write; after the fact, every wrong field is a reindex.

Answer: Exactly which terms a field or analyzer produces for given text: send the field name and sample text to GET /index/_analyze and every token comes back, exposing lowercasing, stemming, stopword removal, and splitting as they truly behave. It is the fastest way to settle why a match missed a document and to compare standard versus english analyzers before committing a mapping. Sixty seconds with _analyze ends most analysis debates on the spot.

Answer: The q= parameter stuffs a query into the URL in Lucene syntax, where a stray colon, space, or AND flips meaning and enables injection-style surprises, and it gives no access to the structured power of the DSL: filters, aggregations, scoring control. Fine for a quick check from Kibana Dev Tools, wrong for application code. Send JSON bodies instead, because the DSL is typed, reviewable, and version-controllable, which matters once queries live in services.

Answer: The coordinating node validates the request and routes each document to its primary shard by hashing the routing value. The primary checks it against the mapping, appends it to the in-memory buffer and the translog, then forwards the operation to every replica in the replication group, each doing the same locally. Once the required copies acknowledge, the coordinating node returns success. The document is durable but not searchable until the next refresh turns buffer into segment, a two-step design under nearly all Elasticsearch interview questions about visibility.

Answer: An append-only log every write hits before acknowledgment, so a crash can replay operations that were acknowledged but not yet flushed as a Lucene commit. durability=request fsyncs on every request: the default, maximally safe, slower. durability=async fsyncs on an interval: faster bulk loads with a window of acknowledged writes you could lose in a crash. Recovery replays the translog over existing segments, which is why the file exists at all and why truncation only happens on flush. Durability knobs like this are standard Elasticsearch interview questions at this level because nearly everyone gets burned by async once.

Answer: Refresh writes the in-memory buffer out as a new Lucene segment into the OS page cache and makes it searchable: no fsync, cheap, once per second by default. Flush is the Lucene commit: it fsyncs segments to disk, writes a new commit point, and truncates the translog, running automatically when the translog crosses its size threshold. Refresh buys visibility, flush buys durability. Swapping those two words sinks the follow-ups in mechanism-tier Elasticsearch interview questions immediately.

Answer: A segment, once written, is never edited: deletes are tombstone bits in a separate file, updates are a new document plus a delete mark, and dead data vanishes only when merges rewrite segments. Immutability means no locks on reads, highly compressible and cache-friendly files, and safe copying for replicas, snapshots, and recovery. The price is write amplification: every update physically rewrites, and deleted documents hold disk and heap until a merge reclaims them.

Answer: A background merge policy continuously rewrites groups of similarly sized segments into fewer larger ones, the tiered policy by default. Merging reads the source segments, drops every document carrying a delete tombstone, and writes one clean segment: the only moment deleted documents and their space actually disappear. Merges consume I/O and file handles, which is why bulk loads raise refresh_interval and why forcemerge is reserved for indices that stopped accepting writes. Watch merge pressure with _cat/thread_pool/force_merge during heavy ingestion.

Answer: Query context asks how well does this document match and computes _score per hit; filter context asks does it match and returns yes or no with no scoring. Because filters are score-free and idempotent, Elasticsearch caches their bitsets in the node query cache and reuses them across requests, so a status filter is effectively free after the first call. Put scoring terms in must and everything structural in filter; that arrangement is the performance half of most Elasticsearch interview questions about queries.

Answer: Per matched term it multiplies inverse document frequency, rarer terms matter more, by a saturating term-frequency curve governed by k1, so the tenth occurrence adds far less than the second, and a length-normalization factor governed by b, so a short field repeating the term outranks a long one. Scores sum across matched terms and accept per-clause boosts. The explain API prints every component for a specific document. Naming k1 and b, and what saturation means, is the complete answer. Score mechanics are the most predictable of all Elasticsearch interview questions, so rehearse this one exactly.

Answer: Column-oriented, on-disk structures built at index time for keyword, numeric, date, and ip fields: sorted per-document values that make sorting, aggregations, and script access sequential and heap-friendly. The trap is fielddata on a text field: it loads every term of every document into the JVM heap, which can OOM a data node, the reason it is disabled by default and almost always wrong. If an aggregation needs text-like behavior, add a keyword multi-field instead and aggregate on that.

Answer: Query phase: the coordinating node fans the request to one copy of every shard, each returns its local top-N lightweight hits plus counts, and the coordinator merges them into a global top-N. Fetch phase: for those winners only, it asks the owning shards for full _source, highlights, and named fields, then assembles the response. Cost therefore scales with from plus size times shard count, which is exactly why deep pagination hurts and why search_after restructures the problem. That two-phase shape is the model behind most Elasticsearch interview questions about distributed search.

Answer: BM25 statistics like document frequency are computed per shard, and a shard is a small independent index, so identical documents can score differently depending on placement, worst when shards are small or unevenly filled. search_type=dfs_query_then_fetch adds a preliminary round that gathers global term statistics before scoring, trading one extra round trip for comparable scores. In practice, sane routing and healthy shard sizes make the difference vanish, and saying when the extra round trip is worth it is the judgment layer interviewers want.

Answer: Roles are flags: master-eligible votes in elections, data holds shards with sub-roles like data_hot, data_warm, data_cold, and data_content, ingest runs pipelines before indexing, coordinating-only routes and reduces, and machine learning and transform roles exist separately. Dedicated masters earn their keep around six or more nodes or heavy shard counts, because elections and cluster-state publishing compete with search and indexing for heap and CPU. Small clusters co-locate everything and accept the tradeoff; the sizing reasoning, not the flag list, is what gets graded.

Answer: Master-eligible nodes vote, a majority quorum elects one, and without quorum the cluster refuses metadata changes rather than risk splitting. Bootstrapping, cluster.initial_master_nodes, is the one-time vote that forms a brand-new cluster; afterwards membership lives in cluster state and joining nodes only need seed hosts. Never leave initial_master_nodes set for restarts, it is first-boot only, and use voting exclusions for planned master maintenance. These details separate candidates who have operated clusters in interviews about Elasticsearch internals.

Answer: The historic failure where a network partition let two masters each command part of one cluster, producing divergent cluster state that could not be merged. Modern versions prevent it structurally: every state change commits only with a majority quorum of master-eligible nodes, so at most one side of any partition can win, and the minority side stops serving rather than serve stale metadata. The sizing rule that falls out: odd number of master-eligible nodes, three for most shops.

Answer: The primary sequences the operation and pushes it to every replica in its replication group, waiting for the required acknowledgments before reporting success. If a replica misses operations or goes quiet, the primary asks the master to remove it from the in-sync list and keeps serving writes with the survivors; the stale replica must catch up by sequence number before rejoining the group. Clients see success as long as primaries live, which surprises people who read the replica count as a write quorum.

Answer: They version the write log across a replication group: the primary term identifies which generation of primary issued an operation, the sequence number orders operations within that term. Together they let replicas and recovering shards compute exactly which operations they missed, power conflict detection through if_seq_no and if_primary_term, and underpin cross-cluster replication’s follower model. They replaced the older fuzzy version arithmetic, and saying that crisply signals you read current documentation rather than old blog posts.

Answer: You read a document, note its _seq_no and _primary_term, then send your update conditioned on those exact values. If anything else wrote first, the numbers no longer match and Elasticsearch rejects the write with a 409 instead of silently overwriting; the client re-reads and retries the loop. It is compare-and-swap for documents. Older external versioning still serves import pipelines, but seq-no-plus-term is the native answer for application-level concurrency, and sketching the retry loop is what earns the point.

Answer: A server-side task: it scrolls the source and bulk-writes into the destination, returning a task ID immediately for anything large. Control it with slices=auto to parallelize across shards, conflicts=proceed to skip version clashes, max_docs to bound a run, and requests_per_second with the _rethrottle API to slow it under live traffic. Snapshot first, verify document counts against the source, and cut over with an alias swap. That end-to-end pattern is the backbone of zero-downtime stories in Elasticsearch interview questions.

Answer: Scroll holds a search context open on every shard for the life of the cursor: cheap per batch, expensive cluster-wide, and never designed for user-facing paging, which is why it is deprecated for that use. search_after with a point in time takes a lightweight immutable view, sorts on a tie-broken _shard_doc, and keeps no per-request context, making it right for exports, iteration jobs, and deep paging alike. The 2026 default answer is PIT plus search_after, with scroll named only as the legacy tool.

Answer: Page forty at size fifty forces every shard to produce two thousand sorted hits so the coordinator can merge and discard all but fifty, work proportional to from times shard count with memory held on every involved node. index.max_result_window caps from plus size at 10,000 by default to keep that cost from killing nodes. The alternatives restructure instead of extend: search_after walks a sort cursor with work proportional to size, and PIT or scroll serve full exports safely.

Answer: Target 10 to 50 GB per shard, a few hundred million documents at most, and total shard counts the heap can carry, a common ceiling being roughly twenty shards per gigabyte of heap. Every shard is a Lucene instance with fixed metadata, heap, mmap, and file-handle overhead, so thousands of tiny shards burn heap on nothing and slow cluster-state operations, while giant shards drag recovery and rebalancing. Shard count is fixed at creation, so mistakes get fixed by shrink, split, or reindex. Sizing judgment is where Elasticsearch interview questions separate people who ran clusters from people who read about them.

Answer: The master-published metadata describing every index, mapping, alias, and shard placement, held in full on master-eligible nodes and shipped to all others on every change. Thousands of small indices with fat mappings mean megabyte-scale state, and every template hit or mapping update republishes and reallocates that memory cluster-wide, which is how mapping explosions and oversharding become cluster-wide GC pain rather than one index’s problem. Fewer, bigger indices; explicit fields; and expired time-series data keep the budget honest.

Answer: Dynamic mapping inventing thousands of fields from unstructured JSON, one per unique key, ballooning mappings, cluster state, and heap until indexing slows cluster-wide and the field limit starts rejecting writes. Guards: index.mapping.total_fields.limit, default 1000, plus depth and nesting limits; dynamic strict or false to refuse or ignore unknowns; and the flattened type, which indexes a whole object as keyword pairs with no per-field cost. Explicit templates and disciplined ingest are the durable fix, settings are the seatbelt, and explosion stories are staples of operations-tier Elasticsearch interview questions for exactly this reason.

Answer: Component templates hold reusable chunks, settings in one, mappings in another; an index template composes them with its own overrides and a priority, and when a name matches multiple templates the highest priority wins outright, no merging. The _simulate_index and _simulate_template APIs preview exactly what a future index would inherit, which settles template disputes before they create wrong indices. Priority collisions from overlapping patterns are the classic self-inflicted wound this question hunts.

Answer: Static settings, number_of_shards, codec, and the shard allocation routing filters, lock at creation and demand reindex to change; dynamic settings like number_of_replicas, refresh_interval, and the watermarks change anytime through _settings. So creation time is when you commit to shard count and tier routing, and everything operational afterwards happens through dynamic settings. Reviewing a new index’s static choices is the one review you cannot redo cheaply, which is why static-versus-dynamic shows up in Elasticsearch interview questions about sizing.

Answer: The master’s allocator balances shards by free disk and shard count, honors node roles and attributes, and refuses placements that would put a primary and its replica on the same node. Allocation filtering, index.routing.allocation include, require, and exclude plus tier preferences, pins indices to node groups, and it is the mechanism hot-warm-cold architectures run on. When a shard will not place, _cluster/allocation/explain states which rule blocked it verbatim, making it the single most useful command in operational Elasticsearch interview questions.

Answer: Index lifecycle management moves indices through a policy: hot takes the writes on your best storage, warm drops replicas or migrates to cheaper nodes, cold moves to slower tiers or searchable snapshots, frozen serves from a snapshot-backed cache, and delete removes on a min_age. Phase actions include rollover, shrink, forcemerge, and allocation moves, triggered by age or size. GET index/_ilm/explain reports where any index sits and why it is stuck, and ending your answer with that command is what makes it operational.

Answer: Rollover creates the next index in a series when a condition trips: max_age, max_primary_shard_size, or max_docs. The series needs an alias with is_write_index true pointing at the current index; rollover creates the successor, often from a template, and repoints the alias atomically, so writers never change endpoints. Clients pointed at raw physical names break silently or fork the series, which is the discipline this question tests: alias everywhere, physical names nowhere, verify with GET _alias after each rollout. Rollover discipline is among the most practical checkpoints in Elasticsearch interview questions, because broken series are everywhere in production.

Answer: POST index/_forcemerge?max_num_segments=1 rewrites each shard into a single segment, reclaiming deleted documents and shrinking heap and search overhead. Run it on indices that have stopped accepting writes, typically as a warm-phase ILM action after the final ingest lands. Never on indices still ingesting: merging against active indexing multiplies I/O, produces big segments that immediately merge again, and can stall the node. It is a one-way optimization for the past, not a tune-up for the present, and that framing is the senior answer.

Answer: A snapshot is a point-in-time, incremental backup of indices into a repository, shared filesystem or object storage via plugin; after the first full copy only new segments are stored, so dailies are cheap. Snapshots are the only recovery path for deleted indices and the vehicle for cluster-to-cluster migration. Snapshot lifecycle management schedules it: cadence, retention counts, repository, with failure reporting. Test restores on a schedule, because an unverified backup is a hope rather than a backup, and that sentence lands the answer.

Answer: POST _snapshot/repo/snapshot/_restore naming the indices, with rename_pattern and rename_replacement to land them under new names, essential when the originals still exist, since a restore refuses to clobber an open index with conflicting history. Feature states restore system data like ILM configuration separately. Restores land in the cluster that runs them, so cross-cluster DR means registering the same repository there and restoring. Practice the renamed restore into a staging cluster before you need it under pressure.

Answer: Three data-node classes: hot takes every write on fast storage, warm holds read-heavy recent history on cheaper disks, cold archives on slow storage or searchable snapshots. ILM does the moving: warm and cold phase allocation actions set the index’s tier preference or routing filters on arrival, alongside replica cuts and refresh changes. Nodes advertise membership through data roles, and _cat/allocation shows the balance per tier. The economics underneath, storage cost per tier per terabyte, is where senior Elasticsearch interview questions take this topic next.

Answer: A named chain of processors that transforms documents at index time inside Elasticsearch, on ingest nodes: grok and dissect for parsing, set and rename for shaping, date for timestamps, fingerprint, drop, and on_failure handlers per step. Clients target one with ?pipeline=, an index can pin a default_pipeline, and Beats or Logstash can call the same pipelines instead of doing local work. Moving parsing from Logstash into ingest pipelines is the standard consolidation move, which is why it recurs in current Elasticsearch interview questions.

Answer: A plain object field flattens, so user.first and user.last become independent leaves, and a bool query on first a AND last b matches even when those values came from different array elements. The nested type preserves each object as a hidden sub-document with its own index, so nested queries match within one element only, at the cost of one Lucene document per element and slower indexing. The cross-element false match is the canonical bug, and explaining it with a two-element example is the complete answer.

Answer: One source field indexed several ways: title as text for relevance plus title.keyword as keyword for sorting, terms aggregations, and exact filters, declared inline in the mapping and addressed as title.keyword in queries. It covers the everyday need to both search a field’s words and bucket its exact values. Changing a multi-field later means reindexing like any mapping change, and discovering mid-project that the keyword sub-field was never defined is the rite of passage this question checks for.

Answer: Circuit breakers are memory guards per operation class: fielddata, request, in-flight requests each estimate cost and refuse work that would push the JVM past its percentage, and the parent breaker sums children against total heap. Older breakers tracked only their own accounting and underestimated real usage; real-memory circuit breakers watch actual JVM consumption and trip early under load. A burst of circuit_breaking_exception errors means queries or aggregations need shaping, not that limits should be raised, and saying that is the maturity signal. Breaker literacy appears in Elasticsearch interview questions whenever heap pressure enters the story.

Answer: The node query cache stores per-shard filter bitsets, so repeated filter clauses like status active become memory-cheap, sized as a share of heap. The shard request cache caches full per-shard results for size-zero requests, so dashboard headline counts repeat cheaply, invalidated whenever the shard refreshes. The OS page cache holds the segment files themselves and is the real read accelerator, which is why leaving roughly half of RAM unassigned to the JVM is standing advice. Three caches, three layers, one story, told in that order.

Answer: A cluster-wide ceiling on shards per data node, multiplied by the node count, added as a safety net after real incidents where runaway shard creation exhausted every node’s memory. When a create or open fails with the limit error, treat it as a signal: count shards per node with _cat/allocation, delete or ILM-expire stale indices, or raise the limit deliberately and temporarily, never as a permanent default. It guards the cluster from its own automation, which is the framing Elasticsearch interview questions on this setting want.

Answer: GET _tasks lists every in-flight operation with runtimes; add detailed=true and an actions filter like *search to surface the long ones, and their descriptions carry the original query source, so the guilty client identifies itself. POST _tasks/id/_cancel cancels cooperatively: searches stop at their next check, reindex winds down, nothing rolls back mid-write. Pair the API with slow logs to trace chronic offenders to their source, because cancelling today’s query without finding its owner guarantees a repeat tomorrow.

Answer: A search fans out to one copy of each shard, so replicas add parallelism for read-heavy loads and let reads localize near users, but every replica also indexes every document again, multiplying write I/O, storage, and heap pressure. Doubling replicas doubles storage while helping searches only until CPU or disk saturates. Under heavy bulk loads, dropping replicas to zero and restoring them afterwards is the classic speed trick, done knowingly, with the availability window in mind. That tradeoff math is the whole answer.

Answer: Bucket aggregations on keyword fields match terms through doc values backed by global ordinals, a shared dictionary mapping integer ordinals to terms, built lazily per shard on first use after each refresh and rebuilt whenever segments change, which is why high-cardinality terms aggregations on fast-refreshing indices pay the build cost repeatedly. date_histogram and numeric metrics stream through doc values without ordinals, and cardinality uses HyperLogLog++ sketches, approximate by design. The lazy-build detail explains most dashboard-slowdown reports, and volunteering it separates mechanical answers from experienced ones. Aggregation internals are the deep end of Elasticsearch interview questions for analytics-heavy roles.

Answer: Yellow means primaries are healthy and some replicas are unassigned, so data is safe and my job is finding why copies cannot place. Order: GET _cat/shards?v&h=index,shard,prirep,state,unassigned.reason and filter the unassigned replicas; GET _cat/nodes?v to check whether a node dropped out or crossed the disk high watermark, the most common cause, since nodes above 90 percent refuse new shard copies; then GET _cluster/allocation/explain for the exact blocking rule. Act by cause: restore the lost node, free disk, or right-size number_of_replicas for a cluster smaller than the replica count assumes. That order, scope, shards, explain, cause, is the full narration this scenario wants.

Answer: Red means a primary has no live copy, so I act in strict order. First, GET _cat/shards?v&h=index,shard,prirep,state,unassigned.reason to list which primaries and why: NODE_LEFT after a crash, ALLOCATION_FAILED after repeated attempts. Second, confirm node reality with _cat/nodes and the master log, because one flapped node explains most reds. Third, for repeat failures, POST _cluster/reroute?retry_failed=true and read allocation explain for the blocking rule. Last resort, if a primary is truly gone with no replica, I bring the decision to the index owner: partial data or an empty shard plus re-feed. Data-loss decisions belong to owners, and saying so out loud is part of the answer. Red-cluster drills open most senior Elasticsearch interview questions, so rehearse the order until it survives nerves.

Answer: Straight to GET _cluster/allocation/explain with the index and shard, which returns the decision in prose. The usual findings: delayed by index.unassigned.node_left.delayed_timeout, five minutes by default, which explains most reports of a cluster stuck that is simply backing off; blocked by a disk watermark; filtered by allocation rules someone changed; or repeatedly failed, which retry_failed clears. _cat/recovery?v shows active restores with their progress and transfer rates, so slow-but-moving and stuck look different. The habit being graded: never guess why a shard will not place when the explain API prints the reason verbatim.

Answer: That block is flood stage: a data node crossed the 95 percent watermark and every index with a shard on it gets index.blocks.read_only_allow_delete, so writes fail with cluster_block_exception while deletes stay allowed. Recovery order: free space first by expiring stale indices or pruning snapshots, because raising watermarks on a full disk only delays the incident; confirm every node back under the low watermark with _cat/allocation; then clear the block per index with PUT settings index.blocks.read_only_allow_delete null, since it never auto-clears. Finish with retention so it cannot recur, ILM delete phases or fewer replicas. This incident is a top-three scenario in Elasticsearch interview questions because it separates symptom-patchers from cause-finders.

Answer: Work from the biggest lever down. GET _cat/indices?v&s=store.size:desc names what owns the bytes, usually one stale log pattern or a replica-heavy index. Expire what is past retention, delete orphaned indices, and cut replicas on historical data, since one replica on a 2TB index costs another 2TB. Force-merge finished indices to reclaim tombstoned space. Check skew with _cat/allocation, because one node at flood stage hurts even when the average looks fine. Stretch watermarks only temporarily and only after cleanup. Then wire alerts at the low watermark, not flood stage, which is the prevention sentence this scenario is really fishing for.

Answer: A mapping explosion: dynamic mapping grew a field per unique JSON key until cluster state and mappings ballooned, and past index.mapping.total_fields.limit, default 1000, writes start failing with too many fields declared. Stop the bleeding first: fix the pipeline’s mapping or set dynamic to strict or false so production writes resume. Then do the hygiene pass: decide which keys deserve real fields, model the long tail with the flattened type, and encode the explicit mapping in the index template. The existing mapping cannot mutate in place, so the corrected index arrives by reindex behind an alias swap, throttled under traffic. Naming the two guardrails, the field limit and flattened, is what this scenario is listening for. Incident versions of mapping explosions are among the most common scenario Elasticsearch interview questions in logging-heavy shops.

Answer: Evidence before theory. Turn on the index search slow log with a threshold around one second; it prints the full request body, so offenders identify themselves. GET _cat/thread_pool/search?v&h=node_name,active,rejected shows queue pressure and rejections cluster-wide, and GET _tasks?detailed=true&actions=*search lists the worst in-flight requests with their source. Profile one representative query with the profile API to see which phase burns the time, usually leading wildcards, script scoring, or huge from values. Fix at the client: filters before scoring, search_after for depth, cache-friendly filter shapes. Diagnosing this without the slow log is the exact mistake Elasticsearch interview questions like this one are built to catch.

Answer: Reproduce it with profile true, which breaks down query and fetch phases per shard. The usual suspects in order: leading-wildcard or prefix queries walking the whole term dictionary, everything scoring because nothing sits in filter context, terms aggregations over high-cardinality fields rebuilding global ordinals on every refresh, and deep pagination forcing every shard to materialize thousands of hits. Fixes follow the diagnosis: rewrite patterns into filters, add a keyword multi-field for exact matching, raise refresh_interval on the backing index, switch to search_after with a PIT. Then run the profile again, because measuring after the fix is how you prove the win instead of asserting it.

Answer: In order: _cat/thread_pool/write for rejections and 429s in the client, which mean backpressure, so slow the client rather than retuning a healthy cluster mid-load. _cat/segments for a segment count exploding, the signature of refresh being too aggressive: raise refresh_interval to -1 or 30s for the load’s duration. Force-merge and flush thread pools plus pending tasks for merge pressure, and _cat/nodes for heap and disk, because flood stage blocks writes outright. Verify replicas: loads often run replicas zero and something restored them early. Throughput problems live in backpressure, refresh, merges, replicas, and disk, usually in that order, and narrating the order is the answer.

Answer: The alias-swap pattern, rehearsed in order. Create index-v2 with the corrected mapping and sane shard sizing. Run _reindex with slices auto, conflicts proceed, and requests_per_second throttled so live traffic keeps headroom, then re-run it for documents written since the first pass, because reindexing is not a snapshot. Verify counts with _count on both sides and spot-check documents. Cutover: pause writes or rely on the dual-write the app should have, run the final delta pass, then move the alias atomically in one _aliases call that removes v1 and adds v2. Drop v1 after a soak period. End to end, this is the flagship migration scenario in Elasticsearch interview questions for senior roles.

Answer: Fifty tiny shards mean fifty Lucene instances of overhead, fifty-way query fan-out, and heap spent on nothing. The shrink API folds shards down when the target divides evenly: mark the source read-only with a metadata block, move each original shard onto one node with allocation filtering, ensure disk for a full copy, then shrink to one or two shards. Where shrink constraints cannot be met, reindex into a fresh index with correct sizing and swap the alias, throttled under traffic. Then fix the template, because the wrong shard count came from somewhere, and the template is the true root cause in nearly every oversharding story.

Answer: Heap pressure with a trigger, so narrow it in order. _cat/nodes?v&h=name,heap.percent,heap.max finds the hottest nodes; _nodes/hot_threads?threads=10 shows what those threads do during pauses, usually aggregation or query work. The exception text names its breaker: parent means total heap, fielddata means a text aggregation, request means a giant terms or script query. Correlate with recent deploys, because a new dashboard with a wildcard query is the classic cause. Then fix the query, cancel runaway tasks, confirm heap stays under 31GB for compressed oops, and keep half the RAM for page cache. Raising breaker limits is the anti-fix, and saying so explicitly is the senior marker. Heap autopsies like this one are fixtures of mid-level Elasticsearch interview questions.

Answer: Flapping is the master repeatedly losing and regaining a node, so separate node-side from path-side. Node side: JVM pauses over 30 seconds from heap pressure, which the master reads as a departure, check _nodes/stats jvm and system logs. Disk: merges or snapshots saturating I/O until heartbeats stall. Path: packet loss or MTU mistakes between racks, visible as timeout patterns in the master log. Fix by finding: heap and query hygiene for GC causes, IOPS headroom for disk, the network team for the path. Left alone, flapping churns shard allocation and turns yellow within hours, so treat it as an incident rather than a log line.

Answer: Symptom first: shards on that device log I/O failures and the node may drop from the cluster. Take the node out cleanly so its shards reallocate; with one replica per shard, survivors promote and the cluster heals to green on its own. Replace the disk, wipe stale data paths, rejoin the node, and let the allocator rebalance onto it, throttled by the recovery settings if IOPS matter. Watch _cat/recovery for progress and _cat/allocation for balance. The availability question underneath decides everything: zero replicas means that disk’s data is gone and recovery is a snapshot restore, which is why the replica discussion precedes the hardware in any competent answer.

Answer: Two honest mechanisms, not a bug hunt. Visibility: searches only see refreshed segments, so a document indexed two hundred milliseconds ago appears for one user and not another until the next refresh, near real time by design; fix expectations with refresh intervals or an explicit refresh after critical writes. Scoring: BM25 statistics are per shard, so scores can differ by which replica answers, most visible on small or unevenly filled shards; dfs_query_then_fetch equalizes statistics at the cost of a round trip when score comparability matters. Explaining both mechanisms calmly is the graded skill here, and it is a quietly common entry in Elasticsearch interview questions for search-heavy teams.

Answer: delete_by_query is a server-side task: run it with conflicts proceed, slices auto, and requests_per_second throttled under live traffic, watching _tasks and the write thread pool. Expect the disk to grow before it shrinks, because deletes are tombstones until merges reclaim them, so schedule off-peak and stay above the low watermark. Check the shape first: if the documents live in date-partitioned indices, dropping whole indices is instant and free, and delete_by_query is reserved for surgical removals like erasure requests. Verify with a filtered _count before and after, because trusting the task’s reported total without a recount is how over-deletions hide until someone asks where the data went.

Answer: Almost always refresh_interval was set to -1 or 30s for load speed and never restored: the documents are durable but unsearched. Confirm with GET index/_settings, force visibility with POST index/_refresh, and restore the interval. Second suspect: the client wrote to index-v2 while the application reads the alias still pinned to v1, a cutover mistake from the alias pattern, check with GET _alias. Third: a timestamp field mapped wrong so the range query excludes the new docs, check with a bare _count ignoring filters. The first cause dominates in practice, which is why the answer starts with a settings call rather than theory.

Answer: Full-cluster recovery replays shard copies and translogs, and default recovery throttling is deliberately gentle, so confirm master quorum first, then read _cat/recovery?v to see whether work is progressing or queued. Tune temporarily: indices.recovery.max_bytes_per_sec up to suit fast storage, node_initial_primaries_recoveries and cluster.routing.allocation.node_concurrent_recoveries raised, replicas restored only after primaries settle. Watch rates so the throttle helps rather than saturates the disks you are trying to protect, and set the dials back when done so routine node restarts stay gentle. Knowing recovery is throttled on purpose, and the five knobs that control it, is the entire content of this scenario.

Answer: Now: let circuit breakers and the node restart stabilize, rejoin and confirm green, and restart a second node only after the first recovers, since simultaneous restarts cascade. Catch the culprit while it lives: GET _tasks?detailed=true&actions=*search shows running searches with their source, and master plus node logs carry the OOM signature. Guardrails immediately: confirm real-memory breakers are active and cancel any surviving giant task. Next week: find the client owning the deep aggregation or unbounded terms field, fix or bound it there, add slow-log thresholds so it fails in test, and alert on breaker events instead of waiting for restarts. OOM autopsies that end in client fixes are what Elasticsearch interview questions at this level listen for.

Answer: Diagnose in order. GET _snapshot/repo/_status on the failing snapshot shows where it stalled: repository connectivity or credentials, a full backend, or one stuck shard, and SLM’s stats plus cluster logs name it. The structural cause is usually retention not pruning, so every nightly adds to a growing chain until the quota dies; check repo size trend against the policy’s retention settings. Fix: prune expired snapshots, shorten retention to what the recovery policy actually requires, snapshot only the indices that changed, and monitor the repository itself rather than the snapshot tasks. Finish with a restore test, because a repo that fills silently is an outage you discover during the disaster, which is the sentence that closes this answer well.

Answer: A document arrived whose value contradicts the mapping, a string landing in a date field or an object where a number was, and Elasticsearch refuses the write rather than corrupt the index. Read the error for the exact field, then choose deliberately: fix the producer, or transform in an ingest pipeline with a convert or coerce processor, or, when the mapping itself is wrong for the new data, accept that mappings do not mutate in place and reindex into a corrected mapping behind an alias. For noisy third-party feeds, ignore_malformed per field trades silent data loss for ingest continuity, a decision to make consciously with the data owner. Root cause over ignore flags is what this scenario grades.

Answer: Contain first: repoint the write alias to the correct index in one atomic _aliases call with is_write_index set, so good data resumes within seconds. Then assess pollution: count the bad documents with the same filter the bug implies, and remove them with a bounded, throttled delete_by_query, or drop the wrongly created indices outright if the bug minted new ones. Verify with counts and a sample read. Afterwards, make the class of bug impossible: aliases owned by infrastructure as code, idempotent writers keyed on document ID so replays are safe, and a canary in the pipeline comparing sent versus indexed counts. Containment before cleanup is the ordering senior interviewers score here, and wrong-target writes are a quiet favorite in operational Elasticsearch interview questions because automation makes them routine.

Answer: Snapshot and restore wins on almost every axis: register the same repository backend on both clusters, snapshot, restore with rename where names collide, and the data moves as segment files, the fastest path with the least CPU, preserving mappings, analyzers, and metadata intact. Reindex from remote re-parses and re-analyzes every document through the target, slower and version-sensitive, but it is the right tool when mappings must change in flight or the source runs a version that cannot be upgraded in place. Real migrations often stage: restore the bulk from snapshots, then reindex the delta accumulated during the copy. Stating the decision rule, file copy versus re-analysis, is the core of this answer.

Answer: Order: drain and upgrade data nodes one at a time, letting each rejoin and recover before the next; upgrade master-eligible nodes one at a time with the quorum intact throughout; finish with Kibana and coordinating-only nodes. Gates between steps: cluster green, no pending tasks, recovery rates sane on _cat/recovery, and the deprecation log clean, because APIs removed in the target version fail at runtime, not at planning time. Disable shard allocation during each node’s restart to stop pointless rebalancing, and re-enable only when the node is ready. The version-skew rules between master and data nodes are the detail that separates planned upgrades from incident reports in this classic of operational Elasticsearch interview questions.

Answer: Inventory first: which indices can hold the identifier, via field capabilities and known index patterns, including aliases and data streams. Then delete_by_query per index with the exact term filter, conflicts proceed, throttled, each task ID recorded for the audit trail. Deleted means unrecoverable only after merges reclaim the tombstones, so for hard deadlines force-merge affected finished indices afterwards, or lean on ILM delete phases for soon-expiring data, documenting which path each index took. Verify with the same filter returning zero everywhere, and state the snapshot caveat plainly: backups retain deleted documents until pruned, so legal sign-off needs the retention statement too. The audit trail is half the deliverable in this scenario.

Answer: Periodic pain matching a scheduler is structural, so read GET index/_ilm/explain and line up phase transitions against the spikes. The usual collision: rollover, forcemerge, and allocation moves landing together while traffic peaks, each doing heavy I/O on nodes that are simultaneously serving searches. Confirm with _cat/thread_pool during a spike and _cat/recovery for moves in flight. Then stagger policies so rollover windows do not align across indices, push forcemerge into warm phases with min_age, throttle allocation moves, and raise refresh_interval on indices mid-transition. Structural fixes beat capacity band-aids, and showing that reasoning is the skill strong Elasticsearch interview questions close with.