- A
The replica's automatic storage increase is disabled.
Why wrong: Storage increase settings do not affect replication lag.
- B
The replica has point-in-time recovery enabled.
Why wrong: PITR on replicas can add some overhead but is not a primary cause of high lag.
- C
The primary instance has a heavy write workload.
A heavy write load on the primary generates more changes than the replica can apply, causing lag.
- D
The replica is using a different storage type than the primary.
Why wrong: Storage type mismatch does not cause replication lag; it affects performance but not replication directly.
Question 49 of 1,000
PCDOE Manage Database Solutions Practice Question
This PCDOE practice question tests your understanding of manage database solutions. The scenario asks you to isolate a root cause — eliminate options that address a different problem before choosing. After answering, compare your reasoning against the explanation and wrong-answer breakdown below. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.
You are troubleshooting a Cloud SQL read replica that is experiencing high replication lag. You check the 'replication_lag' metric and see it is consistently above 60 seconds. What is the most likely cause of this lag?
Clue words in this question
Noticing these words before you look at the options changes how you read each choice.
Clue:
"most likely"Why it matters: Probability qualifier — the question wants the most probable cause or outcome, not a guaranteed one. Eliminate low-probability options.
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 primary instance has a heavy write workload.
Option C is correct because high replication lag in Cloud SQL is most commonly caused by a heavy write workload on the primary instance. When the primary processes a large volume of write operations (e.g., INSERT, UPDATE, DELETE), the replica must replay those changes from the binary log, and if the rate of writes exceeds the replica's ability to apply them, lag accumulates. This is a fundamental behavior of MySQL asynchronous replication, where the replica is always slightly behind the primary under load.
Key principle: Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
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 replica's automatic storage increase is disabled.
Why it's wrong here
Storage increase settings do not affect replication lag.
- ✗
The replica has point-in-time recovery enabled.
Why it's wrong here
PITR on replicas can add some overhead but is not a primary cause of high lag.
- ✓
The primary instance has a heavy write workload.
Why this is correct
A heavy write load on the primary generates more changes than the replica can apply, causing lag.
Clue confirmation
The clue word "most likely" in the question point toward this answer.
Related concept
Read the scenario before looking for a memorised answer.
- ✗
The replica is using a different storage type than the primary.
Why it's wrong here
Storage type mismatch does not cause replication lag; it affects performance but not replication directly.
Common exam traps
Common exam trap: answer the scenario, not the keyword
Cisco often tests the misconception that replication lag is caused by replica configuration issues (like storage or PITR) rather than the primary's workload, leading candidates to overlook the most direct and common cause.
Detailed technical explanation
How to think about this question
Under the hood, Cloud SQL replicas use MySQL's native asynchronous replication, where the primary writes changes to its binary log (binlog) and the replica's I/O thread fetches those logs and writes them to its relay log, while the SQL thread applies them. Lag occurs when the SQL thread cannot keep up with the I/O thread, often due to resource contention (CPU, memory, or disk I/O) on the replica, or because the primary's write rate exceeds the replica's apply rate. In real-world scenarios, a sudden spike in write traffic (e.g., bulk data loads or high-frequency transaction processing) is the most common trigger for lag exceeding 60 seconds.
KKey Concepts to Remember
- Read the scenario before looking for a memorised answer.
- Find the constraint that changes the correct option.
- Eliminate answers that are true in general but not in this case.
TExam Day Tips
- Watch for words such as best, first, most likely and least administrative effort.
- Review why wrong options are wrong, not only why the correct option is correct.
Key takeaway
Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Real-world example
How this comes up in practice
A media company stores terabytes of video archives that are accessed once a year for audit purposes. Moving these objects to a cold storage tier (Azure Archive, S3 Glacier, or Google Nearline) costs a fraction of hot storage. Questions like this test whether you understand storage tiers, access frequency tradeoffs, and retrieval latency requirements.
What to study next
Got this wrong? Here's your next step.
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
- →
Manage Database Solutions — study guide chapter
Learn the concepts, then practise the questions
- →
Manage Database Solutions practice questions
Targeted practice on this topic area only
- →
All PCDOE questions
1,000 questions across all exam domains
- →
Google Professional Cloud DevOps Engineer study guide
Full concept coverage aligned to exam objectives
- →
PCDOE practice test guide
How to use practice tests most effectively before exam day
Related practice questions
Related PCDOE practice-question pages
Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.
Design and Plan Database Solutions practice questions
Practise PCDOE questions linked to Design and Plan Database Solutions.
Manage Database Solutions practice questions
Practise PCDOE questions linked to Manage Database Solutions.
Migrate Database Solutions practice questions
Practise PCDOE questions linked to Migrate Database Solutions.
Design for Reliability, Scalability, and Disaster Recovery practice questions
Practise PCDOE questions linked to Design for Reliability, Scalability, and Disaster Recovery.
Bootstrapping a Google Cloud organization for DevOps practice questions
Practise PCDOE questions linked to Bootstrapping a Google Cloud organization for DevOps.
Managing service incidents practice questions
Practise PCDOE questions linked to Managing service incidents.
Managing Google Cloud costs practice questions
Practise PCDOE questions linked to Managing Google Cloud costs.
Building and implementing CI/CD pipelines practice questions
Practise PCDOE questions linked to Building and implementing CI/CD pipelines.
Implementing service monitoring strategies practice questions
Practise PCDOE questions linked to Implementing service monitoring strategies.
Optimizing service performance practice questions
Practise PCDOE questions linked to Optimizing service performance.
PCDOE fundamentals practice questions
Practise PCDOE questions linked to PCDOE fundamentals.
PCDOE scenario practice questions
Practise PCDOE questions linked to PCDOE scenario.
Practice this exam
Start a free PCDOE practice session
Short sessions build daily habit. Longer sessions build exam-day stamina. Try a timed session to simulate real conditions.
FAQ
Questions learners often ask
What does this PCDOE question test?
Manage Database Solutions — This question tests Manage Database Solutions — Read the scenario before looking for a memorised answer..
What is the correct answer to this question?
The correct answer is: The primary instance has a heavy write workload. — Option C is correct because high replication lag in Cloud SQL is most commonly caused by a heavy write workload on the primary instance. When the primary processes a large volume of write operations (e.g., INSERT, UPDATE, DELETE), the replica must replay those changes from the binary log, and if the rate of writes exceeds the replica's ability to apply them, lag accumulates. This is a fundamental behavior of MySQL asynchronous replication, where the replica is always slightly behind the primary under load.
What should I do if I get this PCDOE question wrong?
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
Are there clue words in this question I should notice?
Yes — watch for: "most likely". Probability qualifier — the question wants the most probable cause or outcome, not a guaranteed one. Eliminate low-probability options.
What is the key concept behind this question?
Read the scenario before looking for a memorised answer.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Last reviewed: Jul 4, 2026
This PCDOE practice question is part of Courseiva's free Google Cloud 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 PCDOE exam.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.