CV0-004 Troubleshooting Practice Question
A cloud administrator is troubleshooting a database failover issue. The database is a managed service with a primary and standby replica in different availability zones. The application uses a read-write endpoint. During a recent maintenance event, the primary database failed over automatically, but the application experienced a 10-minute outage. The administrator checks the failover logs and sees that it completed within 2 minutes. What is the most likely cause of the extended outage?
⚠ Common exam trap
The trap is blaming the failover mechanism or replication; candidates overlook application-side DNS caching in connection pools as the cause of extended downtime.
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's database connection pool does not retry DNS resolution
The most likely cause is that the application's connection pool caches the DNS resolution of the read-write endpoint. After failover, the DNS record points to the new primary, but the pool continues to use the old IP until the TTL expires or the connection is refreshed. This causes a prolonged outage beyond the actual failover time.
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 application's database connection pool does not retry DNS resolution
Why this is correct
After failover the read-write endpoint's DNS record points to the new primary, but a connection pool caching the old address keeps reconnecting to the failed node until its entries expire. This explains the outage far exceeding the two-minute failover time.
- ✗
The application was not configured to use multiple availability zones
Why it's wrong here
Multi-AZ deployment is already stated in the stem, so application-side AZ configuration cannot explain the gap; the read-write endpoint should have re-pointed automatically. It is tempting because AZ-aware clients reduce failover impact, but here the delay lies in DNS caching or connection-pool refresh after the endpoint moved.
- ✗
The standby replica was not in sync
Why it's wrong here
Replication lag would have delayed the failover itself, yet the logs show it completed in two minutes; the remaining eight minutes occurred after promotion. It is tempting because stale replicas genuinely cause data loss and slow promotion, but the stem's timing points to application reconnection rather than synchronisation.
- ✗
The failover triggered a change in the endpoint DNS record
Why it's wrong here
DNS record change happens quickly, but the application may not re-resolve.
Visual reference
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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CompTIA exam blueprint
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.