Cluster, node, and shard architecture in Elasticsearch - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this Elasticsearch cluster health API call?

Consider an Elasticsearch cluster with 3 nodes and 5 primary shards per index. You run the following API call:

GET /_cluster/health

What key value will the status field most likely show if all nodes and shards are functioning correctly?

Elasticsearch

GET /_cluster/health

A "status": "green"

B "status": "blue"

C "status": "red"

D "status": "yellow"

💡 Hint

Think about what the cluster health colors mean in Elasticsearch.

In Elasticsearch, green means all primary and replica shards are allocated and the cluster is fully functional. Yellow means all primary shards are allocated but some replicas are not. Red means some primary shards are unallocated. Blue is not a valid status.

🧠 Conceptual

intermediate

How many shards will an index have if it is created with 4 primary shards and 2 replicas?

You create an index in Elasticsearch with 4 primary shards and set the number of replicas to 2. How many total shards will this index have?

A 8

B 6

C 4

D 12

💡 Hint

Remember that replicas are copies of primary shards.

Total shards = primary shards + (primary shards × number of replicas). Here, 4 + (4 × 2) = 12 shards.

🔧 Debug

advanced

Identify the error in this node allocation setting

Given the following Elasticsearch node setting snippet, what error will occur when starting the node?

node.attr.zone: us-east-1a
node.attr.zone: us-east-1b

A RuntimeError: Invalid zone attribute value

B Node will start normally with zone set to 'us-east-1b'

C SyntaxError: Duplicate key 'node.attr.zone' in configuration

D Warning: Multiple zones assigned, node will be assigned to first zone

💡 Hint

Check if the same key is repeated in the configuration file.

YAML or properties files do not allow duplicate keys. Defining 'node.attr.zone' twice causes a syntax error during parsing.

❓ Predict Output

advanced

What is the output of this shard allocation filtering query?

Assume you have a cluster with nodes tagged by zone attribute. You run this allocation filtering query:

GET /_cluster/allocation/explain
{
  "index": "myindex",
  "shard": 0,
  "primary": true
}

The node has node.attr.zone: us-west-2a but the index has allocation filtering set to include.zone: us-east-1a. What will the explanation say about shard allocation?

A Shard cannot be allocated to node because node zone 'us-west-2a' is excluded by allocation filtering

B Shard allocation failed due to missing primary shard

C Shard allocation delayed due to node overload

D Shard allocated successfully to node in zone 'us-west-2a'

💡 Hint

Think about how allocation filtering works with node attributes.

Allocation filtering restricts shards to nodes with matching attributes. Since the node's zone does not match the include filter, the shard cannot be allocated there.

🧠 Conceptual

expert

How does Elasticsearch handle shard rebalancing when a new node joins the cluster?

When a new node joins an Elasticsearch cluster, how does the cluster decide to rebalance shards across nodes?

A Shards remain on original nodes until manually moved by the administrator

B Elasticsearch automatically moves shards to the new node to balance disk usage and shard count

C New shards are created on the new node but existing shards stay put

D The cluster shuts down and restarts to redistribute shards evenly

💡 Hint

Consider Elasticsearch's automatic cluster management features.

Elasticsearch automatically rebalances shards to spread load and disk usage evenly when nodes join or leave the cluster.