ElasticSearch Risk Assessment & Management 4 — Questions and Answers
Question 1: What is the risk of setting indices.recovery.max_bytes_per_sec to an extremely high value during a large shard recovery?
- Recovery saturates network bandwidth, degrading query performance for live traffic (Correct answer)
- Shards are marked as unassigned permanently after recovery speed limits are exceeded
- High recovery speed causes checksum mismatches in shard files
- Circuit breakers are permanently disabled during recovery
Correct answer: Recovery saturates network bandwidth, degrading query performance for live traffic
Unrestricted recovery bandwidth can crowd out search and indexing traffic, causing latency spikes and timeouts in production.
Question 2: Which risk is introduced by using a single Elasticsearch service account token for all application microservices?
- Compromise of one service exposes credentials used by all services, widening the blast radius (Correct answer)
- Token rotation requires coordinated downtime across all services simultaneously
- Kibana cannot differentiate between service identities in audit logs
- A single token cannot be scoped to multiple indices
Correct answer: Compromise of one service exposes credentials used by all services, widening the blast radius
Shared credentials mean a breach of one microservice grants an attacker access under the same identity to all resources that token can reach.
Question 3: An Elasticsearch ILM policy is misconfigured, preventing old indices from rolling over. What risk does this create over time?
- A single index grows indefinitely, increasing shard size beyond recommended limits and degrading search performance (Correct answer)
- ILM automatically deletes the index when it exceeds 50GB
- Replicas are dropped automatically when the primary shard is too large
- New documents are rejected once the shard count reaches the maximum
Correct answer: A single index grows indefinitely, increasing shard size beyond recommended limits and degrading search performance
Without rollover, indices accumulate unbounded data, leading to oversized shards that slow merges, queries, and recovery operations.
Question 4: Which attack vector is specifically mitigated by enabling Elasticsearch's document-level security (DLS)?
- Users accessing documents they are not authorized to see within a shared index (Correct answer)
- Network-level packet capture of Elasticsearch API responses
- Brute-force attacks against Elasticsearch user passwords
- Denial-of-service via large aggregation queries
Correct answer: Users accessing documents they are not authorized to see within a shared index
DLS applies per-query filters so users only see documents matching their security policy, preventing unauthorized cross-tenant data access.
Question 5: A cluster has no snapshot repository configured. Which risk category does this represent?
- Disaster recovery risk — no point-in-time restore is possible after data loss (Correct answer)
- Confidentiality risk — documents are stored without encryption
- Availability risk — nodes cannot join without a snapshot repository
- Integrity risk — documents may be silently corrupted without snapshot checksums
Correct answer: Disaster recovery risk — no point-in-time restore is possible after data loss
Without snapshots, there is no mechanism to restore data following accidental deletion, hardware failure, or ransomware.
Question 6: What risk does the Elasticsearch _cat/nodes API expose when accessible without authentication?
- Cluster topology, node roles, IP addresses, and resource utilization are visible to unauthenticated callers (Correct answer)
- Node private TLS keys can be downloaded via the _cat/nodes response
- Shard contents are streamed in the response body
- Index mappings are included in _cat/nodes output by default
Correct answer: Cluster topology, node roles, IP addresses, and resource utilization are visible to unauthenticated callers
The _cat/nodes API reveals internal cluster structure that attackers can use for reconnaissance before targeting specific nodes.
Question 7: Which Elasticsearch circuit breaker specifically protects against out-of-memory errors caused by large field data caches?
- Fielddata circuit breaker (Correct answer)
- Request circuit breaker
- In-flight request circuit breaker
- Parent circuit breaker
Correct answer: Fielddata circuit breaker
The fielddata circuit breaker limits the amount of heap that fielddata (used for sorting and aggregations) can consume before throwing an exception.
ElasticSearch Risk Assessment & Management 4
What is the risk of setting indices.recovery.max_bytes_per_sec to an extremely high value during a large shard recovery?