hardMultiple Choice
CV0-004 Read Replica Practice Question
A company recently migrated its database to a cloud-managed database service. After the migration, the application team reports that some queries are returning stale data. The database is configured with read replicas. What is the most likely reason for the stale data?
⚠ Common exam trap
CompTIA Cloud+ often tests the concept of asynchronous replication lag in read replicas, and the trap here is that candidates may confuse stale data with network latency or misconfiguration, overlooking the fundamental behavior of read replicas returning data that is not yet fully synchronized.
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
✓
The application is reading from a read replica that has replication lag.
The most likely reason for stale data is that the application is reading from a read replica that has not yet applied all changes from the primary database. In cloud-managed database services like Amazon RDS or Azure SQL, read replicas use asynchronous replication, which introduces replication lag. If the application directs read queries to a replica that is behind, it will return data that is not current.
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 database parameter group is misconfigured.
Why it's wrong here
Parameter groups tune engine settings such as connection limits or timeouts; they do not govern replication lag. Stale reads arise because the application queries a read replica that has not yet received the primary's latest writes. Parameter groups would be the right focus when tuning engine behaviour, not replication consistency.
- ✓
The application is reading from a read replica that has replication lag.
Why this is correct
Read replicas replicate asynchronously from the primary database, so a replica can lag behind by seconds or more. When the application queries that replica, it reads data committed before the lag interval elapsed, returning stale results until replication catches up.
- ✗
The network latency between the application and database is high.
Why it's wrong here
High network latency delays packet delivery but does not cause replicas to serve older committed data; replication asynchrony does. Latency would be the correct diagnosis when response times degrade uniformly, not when reads return outdated values. The stem's read replicas point to replication lag.
- ✗
The database’s backup and restore process has corrupted the data.
Why it's wrong here
Backup and restore corruption would produce missing or malformed rows, not consistently stale reads on replicas. The symptom points to replication lag: writes reach the primary but replicas trail behind. Backup and restore is the correct concern when recovering from data loss or validating point-in-time restores.
Go deeper
Related to this question
About these practice questions
One of 834 original CV0-004 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CV0-004 practice question is part of Courseiva's free CompTIA 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 CV0-004 exam.