DVA-C02 ElastiCache Auto Scaling Practice Question
A developer is troubleshooting a slow-running application that uses ElastiCache for Redis as a caching layer. The application frequently reads and writes data to the cache. Which TWO actions should the developer take to improve cache performance?
⚠ Common exam trap
A common trap is to think that disabling persistence (appendonly) is the best way to improve write performance in Redis, but in a caching scenario, persistence may not be the main bottleneck.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use optimized data structures like hashes instead of strings for complex data.
Using optimized data structures like hashes instead of strings reduces memory and CPU overhead for complex data, improving cache performance. Option E is correct because enabling ElastiCache auto scaling allows the cluster to adjust the number of nodes based on demand, preventing performance degradation during traffic spikes. Option B is incorrect: LRU eviction policy helps manage memory when full but is not a performance optimization for read/write operations. Option C is incorrect: disabling persistence (appendonly no) improves write performance but is not the primary issue for a slow application and may affect data durability. Option D is incorrect: increasing shards distributes data but does not directly improve performance if the bottleneck is CPU or memory; auto scaling is a more targeted solution.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use optimized data structures like hashes instead of strings for complex data.
Why this is correct
Employing optimized data structures such as Redis hashes, instead of storing complex data as serialized strings, significantly enhances performance. Hashes allow for direct field access, reducing the need for costly serialization/deserialization operations and parsing overhead on the application side. This leads to more efficient memory usage and faster CPU processing for read and write operations, as data can be accessed and manipulated with O(1) average time complexity, directly improving application responsiveness.
- ✗
Configure the cache to use LRU eviction policy.
Why it's wrong here
Configuring an LRU (Least Recently Used) eviction policy primarily addresses memory management when the cache reaches its maximum capacity. It dictates which items are removed to make space for new ones, preventing the cache from running out of memory. However, an eviction policy does not inherently improve the read or write performance of the cache itself; it only manages the cache's contents under memory pressure. Therefore, it won't directly resolve a slow-running application's performance bottleneck.
- ✗
Disable persistence by setting appendonly to no.
Why it's wrong here
Disabling persistence, such as setting `appendonly no` for Redis's AOF (Append Only File), can indeed reduce disk I/O and slightly improve write performance by eliminating the overhead of writing every command to disk. However, this comes at the significant cost of data durability, as data loss can occur upon a cache restart or failure. For a generally "slow running application," the primary bottleneck is often read performance, CPU processing, or memory, rather than the minor overhead of persistence.
- ✗
Increase the number of shards to distribute data.
Why it's wrong here
While increasing the number of shards (or partitions) in a distributed cache like Redis can distribute data and potentially improve concurrent access, it does not inherently resolve all performance bottlenecks. If the "slow running" issue stems from inefficient data access patterns, high CPU utilization per node, or memory pressure on existing nodes, simply adding more shards without addressing the underlying resource or query inefficiency might not yield significant improvement. Auto scaling offers a more dynamic and comprehensive capacity solution.
- ✓
Enable ElastiCache auto scaling to adjust the number of nodes.
Why this is correct
Enabling ElastiCache auto scaling is a highly effective strategy for addressing a slow-running application, especially under variable load. Auto scaling dynamically adjusts the number of cache nodes (shards or replicas) based on predefined metrics like CPU utilization or network I/O. This ensures that the cache cluster always has adequate resources to handle demand, preventing performance degradation during traffic spikes due to resource exhaustion and maintaining optimal performance and availability.
Go deeper
Related to this question
About these practice questions
Courseiva writes every DVA-C02 question from scratch — 1,135 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DVA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DVA-C02 exam.