An ecommerce company uses an Amazon ElastiCache for Redis cluster for in-memory caching of popular product queries on a shopping website. A SysOps administrator views Amazon CloudWatch metrics data…

Question

Options

• AAdd another node to the ElastiCache cluster.
• BIncrease the ElastiCache TTL value.
• CDecrease the ElastiCache TTL value.
• DMigrate to a new ElastiCache cluster that has larger nodes.

• A
  71% (15)
• B
  5% (1)
• C
  19% (4)
• D
  5% (1)

Explanation

Adding a node directly addresses the root cause of evictions: insufficient memory. When ElastiCache runs out of memory, it evicts (removes) cached items to make room for new ones - adding a node expands total cluster memory, reducing evictions while keeping popular queries in cache, all without the disruption of a migration.

Why the distractors are wrong:

• B (Increase TTL): Longer TTL means items stay in cache longer, consuming more memory and actually worsening evictions - the opposite of what's needed.
• C (Decrease TTL): While this frees up memory sooner, items expire faster, meaning popular queries leave the cache prematurely - violating the requirement to keep them cached.
• D (Migrate to larger nodes): Larger nodes would also solve the memory problem, but migrating to an entirely new cluster involves significantly more operational overhead (provisioning, reconfiguring, warming the cache, updating app connections) versus simply adding a node to the existing cluster.

Memory tip: On the AWS exam, evictions = memory pressure. When you see eviction spikes, think "add capacity" - either scale out (more nodes) or scale up (larger nodes). The question's "least operational overhead" clause is the tiebreaker: adding a node to an existing cluster is simpler than a full migration.

No community discussion yet for this question.