DOP-C02 Incident and Event Response Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  The cache is under memory pressure and evicting keys to make room.

  Why this is correct

  When an ElastiCache cluster reaches its maxmemory limit, the eviction policy (e.g., allkeys-lru or volatile-lru) kicks in to free space by deleting keys. Evicted keys disappear before they can serve valid reads, so subsequent lookups for those keys become cache misses, directly reducing the CacheHitRate metric. This is the most consistent explanation for a sustained drop in hit ratio: the cache is actively discarding data to accommodate new writes, and the eviction is a continuous symptom of memory pressure, not a one-time event.

• ✗

  The cluster was resized from a single node to a cluster mode.

  Why it's wrong here

  ElastiCache does not support an in-place resize from a single node to cluster mode; that operation requires creating a new cluster with cluster mode enabled and migrating data. Even if it were possible, it would cause a full cache flush and a complete rehydration period where hit ratio starts near zero and recovers, rather than a steady degradation. The question's symptom is an ongoing reduction in hit ratio, not a one-time reset, so this change does not explain the observed behavior.

• ✗

  The encryption in transit was enabled, adding latency.

  Why it's wrong here

  Enabling encryption in transit (TLS) adds CPU and network overhead on each request, which can increase latency and reduce throughput, but it does not alter how keys are stored, aged, or evicted. The hit ratio depends on whether requested keys are present in the cache, not on the transport encryption overhead. A latency increase would manifest as slower responses, not as a higher proportion of cache misses, so this option is not a plausible cause of a drop in the hit ratio.

• ✗

  There is a network partition between the application and the cache.

  Why it's wrong here

  A network partition between the application and the cache would make every cache request fail: the application would either receive errors or fall back to the database, effectively causing the cache hit ratio to crash to near zero or for requests to stop being counted entirely. That symptom is dramatically different from a gradual or noticed drop in the hit ratio, which implies the cache is still reachable and serving some hits. The partition also would not persist in a way that selectively evicts a subset of keys; it is an availability failure, not a memory management issue.

Go deeper

Related to this question