Articles

OpenSearch Interview Questions: Shards, Index Templates, and Search Failures

Prepare for OpenSearch interview questions on shards, index templates, mapping failures, partial results, and evidence-based cluster recovery decisions.

Your OpenSearch cluster is green. Yesterday’s dashboard worked. A new index appeared this morning, and the same aggregation now fails—or returns a plausible result covering only part of the data. Adding nodes is not yet a diagnosis.

The answer to build toward: Separate three questions: which configuration created the index, whether its shards are allocated, and whether the search completed successfully across its targets. OpenSearch interview questions become easier when you identify the evidence for each question before proposing a fix.

For broader search-engine background, the Elasticsearch interview overview covers inverted indexes and query performance; this article uses OpenSearch’s own documentation for its operational rules.

Evidence boundary: Official facts cite current OpenSearch documentation checked September 21, 2026. The exercises and recommended investigation order are our engineering inference, not employer-specific interview rules. We did not verify firsthand candidate reports establishing these exact prompts. REST examples describe expected behavior and were not executed against an OpenSearch cluster for this article; check your deployed version and service restrictions.

How many shards does a search actually use?

Official fact: An index partitions its data into primary shards; replicas provide additional copies. Search routing chooses a primary or replica copy for the required shard. OpenSearch introduction and search shard routing.

Consider one index with three primaries and one replica per primary. It has six configured shard copies, representing three logical partitions. A normal search across the whole index targets those three shard groups, not six independent partitions of documents. The illustration shows primary copies serving this request; eligible replicas could serve it instead.

Worked inference: Suppose each primary holds roughly 20 GB. The index contains approximately 60 GB of primary data and 120 GB across both copies, before other storage overhead. Increasing replicas does not divide that 60 GB into smaller primary partitions. It adds copies, with storage and replication work to budget.

Official fact: Replica count is a dynamic index setting. Primary count is configured differently; the Split Index API changes topology by creating a new target index, subject to its constraints. Do not propose changing primary count through an ordinary live replica-setting update. Index settings and Split Index API.

For an interview sizing answer, state the expected data, concurrent requests, node capacity, and recovery objective. Then explain what you would measure. “More shards makes search faster” skips the coordination and resource costs your design must account for.

Which index template wins when patterns overlap?

Official fact: With the composable _index_template API, the highest-priority matching index template wins. Other matching index templates are not merged into it. Overlapping patterns at the same priority are rejected. The version field supports external template management; it does not replace priority as the selection rule. Create or Update Index Template API.

Here is the first exercise. Use an isolated test cluster or namespace with no other matching templates. Create the broad template, then the first index:

PUT /_index_template/demo_roll_base
{
  "index_patterns": ["demo-roll-*"],
  "priority": 10,
  "template": {
    "settings": {"number_of_shards": 2, "number_of_replicas": 0},
    "mappings": {"properties": {
      "status": {"type": "keyword"},
      "tenant_id": {"type": "keyword"}
    }}
  }
}

PUT /demo-roll-orders-000001

Now introduce a higher-priority template containing a deliberate mapping mistake:

PUT /_index_template/demo_roll_orders
{
  "index_patterns": ["demo-roll-orders-*"],
  "priority": 100,
  "template": {
    "settings": {"number_of_shards": 2, "number_of_replicas": 0},
    "mappings": {"properties": {
      "status": {"type": "text"}
    }}
  }
}

Before creating the next index, predict two things: the type of status, and whether the broad template’s tenant_id mapping survives. The intended answer is text and no inherited tenant_id declaration. This exercise sets zero replicas to simplify a disposable single-node demonstration, not as a production recommendation.

Notice how little the index name alone proves. The more specific pattern wins here because its priority is higher. Naming specificity is not a substitute for inspecting the actual priority values.

How do component templates and simulation change that answer?

Official fact: Component templates provide explicitly shared configuration through composed_of. Components are applied in listed order, and the index template’s own values apply afterward. Explicit create-index settings and mappings can override template values. These are different operations from selecting among competing index templates. Index templates.

If every order index needs tenant_id, make that dependency explicit in the winning template or its referenced components. Do not depend on a lower-priority template quietly filling gaps. Review the resolved configuration, not just the file changed in the pull request.

POST /_index_template/_simulate_index/demo-roll-orders-000002

Official fact: Simulation previews the resolved settings, mappings, and aliases for an index name. Its overlapping array identifies other matching templates that were not applied. Simulate Index Templates API.

Preparation inference: Use the exact next index name in the test. A simulation for demo-roll-audit-000002 would miss our order-specific override. Assert the required field types, primary count, replica count, and aliases before rollout. A template’s successful save is evidence that it was accepted, not evidence that it expresses the intended schema.

Why does the new index fail while the old one still works?

Official fact: Index templates affect index creation. Editing a template does not retrofit indexes that already exist. Template lifecycle.

Continue the fixture by creating the second index and adding one document to each:

PUT /demo-roll-orders-000002

PUT /demo-roll-orders-000001/_doc/1?refresh=wait_for
{"status": "paid"}

PUT /demo-roll-orders-000002/_doc/1?refresh=wait_for
{"status": "paid"}

GET /demo-roll-orders-*/_field_caps?fields=status,tenant_id&include_unmapped=true

Official fact: Field capabilities reports field types and whether fields are searchable or aggregatable across the requested indexes. It helps expose incompatible mappings behind a shared search target. Field capabilities API.

In our expected result, the first index retains status: keyword; the second receives status: text. The second index also lacks the base template’s explicit tenant mapping. Inspect each concrete index’s _mapping when the combined response reveals a difference.

Now run this aggregation against each index separately, then against the wildcard:

GET /demo-roll-orders-*/_search?allow_partial_search_results=false
{
  "size": 0,
  "aggs": {"by_status": {"terms": {"field": "status"}}}
}

Official fact: A text field does not support sorting or aggregations by default. Enabling fielddata consumes heap and aggregates analyzed tokens; a keyword field is the appropriate choice for exact values. Field data mapping parameter.

Worked inference: The old index supports the requested aggregation; the new mapping does not. Healthy shard allocation cannot make that field contract valid. The strict wildcard request should expose the failure instead of being accepted as a complete aggregate. Capture the actual error body in your environment rather than memorizing one universal error string.

Does an HTTP success response mean the results are complete?

Official fact: The Search API permits partial results by default through allow_partial_search_results. Search responses include timed_out and _shards outcomes. A timeout can leave partial or empty results. Search API.

Use the following as an application-policy exercise, not a captured server trace. Assume the product requires a complete aggregate over the intended indexes:

Observation	Interpretation for that product
HTTP success; `_shards.failed > 0`	Do not label the aggregate complete. Inspect failed-shard reasons.
HTTP success; `timed_out: true`	Completion has not been established, even if hits are present.
No shard failures or timeout; zero matching hits	Could be a legitimate empty result. Check query and target coverage.
Request-level error	Preserve the error type and cause before choosing a retry or correction.

The third row matters. A query can run correctly against the wrong alias, date range, or routing value. Success across the selected shards cannot prove that you selected the intended data.

Design inference: For a completeness-sensitive endpoint, request strict partial-result behavior and still validate the returned body. Decide whether to fail the user operation or display an explicit degraded result. Do not silently turn missing shard contributions into a smaller business total.

Also check intentional early termination when your request uses it; do not mistake a deliberately truncated search for an exhaustive aggregate.

Test that policy with synthetic responses: a complete empty result, one failed shard, timeout without a shard failure, and a request-level error. Add a case where the query is deliberately scoped to the wrong index; response flags alone cannot detect that semantic mistake.

What do green, yellow, and red actually tell you?

Official fact: Green means all primary and replica shards are allocated. Yellow means primaries are allocated but some replicas are not. Red means at least one primary is unassigned. Overall cluster health reflects the worst shard status. Cluster Health API.

A yellow single-node test cluster can still answer a search because the unavailable copies are replicas. A red cluster does not imply every index is unavailable. Determine whether the missing primary belongs to the request’s target before connecting the health alert to this particular failure.

These observations also explain why our mapping exercise can remain green. Allocation health and query compatibility answer different questions. Keep both on your investigation notes rather than trying to make one replace the other.

How would you investigate an unassigned primary?

Start with read-only evidence for the affected indexes:

GET /_cluster/health/demo-roll-orders-*?level=shards
GET /_cat/shards/demo-roll-orders-*?v

Choose the actual unassigned shard from that output. If it is primary shard 0 of the second index, ask:

POST /_cluster/allocation/explain
{
  "index": "demo-roll-orders-000002",
  "shard": 0,
  "primary": true
}

Official fact: Allocation Explain reports the allocation decision and supporting explanations. Outcomes include no, throttled, allocation_delayed, and no_valid_shard_copy; node-level decisions help explain why placement is blocked. Cluster Allocation Explain API.

Operational inference: Read the decider’s reason before changing anything. A placement restriction, temporary recovery throttle, and lack of a valid copy require different remedies. Record the affected index, shard, candidate nodes, last allocation information, and the evidence supporting your next action.

When the failure began after a rollout, compare one old index with one new index using the same minimal request. Preserve the target names and request parameters with both responses. That comparison narrows the explanation: a failure tied to the new mapping needs different work from a failure that follows one unavailable shard across otherwise valid queries.

If no valid copy is available, establish whether a node can return or a recoverable backup exists. Do not offer a forced empty primary as an ordinary availability fix: losing data changes the business outcome. Recovery should be judged by restored data and representative queries, not only a greener health indicator.

How would you repair the rollout and prove it worked?

First correct the template for future indexes. Then address the already-created index separately.

Official fact: Changing an existing indexed field’s type requires a new index with the desired mapping and reindexing; aliases can support the transition. A template edit alone cannot perform that migration. Create or Update Index Mappings API.

Engineering inference: Simulate the next name, create a controlled target, inspect its actual mapping, and test the exact aggregation. For a migration, verify counts and representative records, reconcile writes arriving during the copy, and validate the read target after cutover. Keep a rollback route that accounts for newly written data.

Close the interview answer with the evidence you would retain: resolved template, actual mapping, shard state, error cause, and a representative complete response. Retrying the original mapping error without changing its cause is not a repair.