DVA-C02 Development with AWS Services Practice Question
A company runs a web application on Amazon EC2 instances behind an Application Load Balancer (ALB). The application stores user session data in an Amazon ElastiCache for Redis cluster. Recently, users have been experiencing intermittent session timeouts and data loss. The developer examines the application logs and finds errors indicating that the Redis cluster is returning 'READONLY You can't write against a read-only replica.' The ElastiCache cluster is configured as a Redis replication group with one primary and two replicas. The application's connection code uses the primary endpoint. What is the most likely cause of this issue?
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
✓
A failover event occurred, and the application is still trying to write to the old primary node, which is now a replica.
The READONLY error occurs when attempting to write to a Redis replica node. In a replication group with one primary and two replicas, a failover event can promote a replica to become the new primary while the old primary becomes a replica. If the application's connection code uses the primary endpoint (which is a DNS name), DNS caching or a long TTL may cause the application to continue resolving to the old primary's IP address, now a replica. Subsequent write requests to this replica will fail with the READONLY error, causing intermittent session timeouts and data loss. Option B correctly identifies this scenario. Option A is incorrect because scaling down to a single node would not produce this specific error. Option C is incorrect because security groups would block all traffic, not just writes. Option D is incorrect because cluster mode (sharding) is unrelated to the primary-replica configuration causing the error.
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 ElastiCache cluster has been scaled down to a single node, causing the primary to become unavailable.
Why it's wrong here
Scaling an ElastiCache for Redis cluster down to a single node means that node becomes the sole primary. If this node were available, it would accept write operations, not return a READONLY error. A READONLY error indicates the node is operational but configured as a replica, which is not the state of a standalone primary node. If the single node became unavailable, the error would be a connection failure or timeout, not a Redis-specific READONLY response.
- ✓
A failover event occurred, and the application is still trying to write to the old primary node, which is now a replica.
Why this is correct
During a failover event in an ElastiCache for Redis replication group, one of the replicas is promoted to become the new primary, and the original primary node is demoted to a replica role. Redis replicas are configured by default to reject write operations, returning a READONLY error. If the application's client-side connection or cached endpoint still points to the old primary node, it will attempt to write to what is now a replica, resulting in the observed READONLY error.
- ✗
The ElastiCache security group is blocking write traffic to the primary endpoint.
Why it's wrong here
ElastiCache security groups operate at the network layer, controlling inbound and outbound traffic based on IP addresses and port numbers. They do not have the capability to inspect or differentiate between read and write commands at the application layer (Redis protocol). If a security group were blocking traffic, the application would experience connection timeouts or refused connections, not a specific `READONLY` error message returned by the Redis server itself, which indicates a successful connection but an operation rejection.
- ✗
The Redis cluster mode is enabled, and the application is not using the correct cluster endpoint.
Why it's wrong here
Redis Cluster Mode is designed for sharding data across multiple primary nodes, each managing a subset of hash slots. If an application connects to a node that does not own the hash slot for a specific key in cluster mode, it typically receives a `MOVED` or `ASK` redirection error, prompting the client to connect to the correct node. A `READONLY` error specifically indicates that the connected node is a replica and not permitted to accept writes, which is distinct from a cluster mode routing issue.
Visual reference
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.