Quick Answer
The answer is the Cloud SQL metric called "Lock waits." This metric directly measures the number of queries currently blocked because they are waiting for a lock held by another transaction, making it the precise indicator of query contention and lock-related bottlenecks. On the Google Professional Cloud Database Engineer exam, this question tests your ability to differentiate between metrics that measure throughput or connections versus those that measure blocking or contention; a common trap is confusing "Lock waits" with "Queries per second" or "Active connections," which do not capture the specific state of being locked. To remember this, think of the phrase "Lock waits = blocked queries," and note that a sudden spike in this metric often signals a deadlock or a long-running transaction hogging resources.
This PCDE practice question tests your understanding of monitor and optimize database performance. Read the scenario carefully and evaluate each option against the stated constraints before committing to an answer. 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.
Which Cloud Monitoring metric indicates the number of queries waiting for locks in Cloud SQL?
Lock waits
This metric measures the number of queries waiting for locks.
Active connections
Why wrong: This is the number of active connections, not lock waits.
CPU utilization
Why wrong: CPU utilization indicates processor usage, not lock contention.
Queries
Why wrong: This is the total query count, not lock waits.
Answer choices
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
Lock waits
The 'Lock waits' metric in Cloud SQL (for MySQL, PostgreSQL, or SQL Server) directly tracks the number of queries that are blocked because they are waiting for a lock held by another transaction. This is the correct indicator of query contention, as it measures the count of statements currently in a lock-wait state, not the total queries or connections.
Key principle: Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Answer analysis
For each option: why learners choose it and why it is or isn't the right answer here.
Lock waits
Why this is correct
This metric measures the number of queries waiting for locks.
Related concept
Read the scenario before looking for a memorised answer.
Active connections
Why it's wrong here
This is the number of active connections, not lock waits.
CPU utilization
Why it's wrong here
CPU utilization indicates processor usage, not lock contention.
Queries
Why it's wrong here
This is the total query count, not lock waits.
Common exam traps
The trap here is that candidates confuse 'Queries' (total throughput) with 'Lock waits' (blocked queries), assuming that a high query count implies lock contention, when in fact lock waits are a specific subset of queries that are actively waiting for locks.
Detailed technical explanation
In Cloud SQL, lock waits are tracked via the `Innodb_row_lock_current_waits` status variable for MySQL (InnoDB engine) or `pg_stat_activity` with `wait_event` for PostgreSQL. Under the hood, a lock wait occurs when a transaction tries to acquire a row-level or table-level lock that is already held by another transaction, causing the query to enter a waiting state until the lock is released or a timeout occurs. In real-world scenarios, a sudden spike in lock waits often indicates a poorly designed transaction that holds locks for too long, leading to cascading contention and degraded application performance.
Key takeaway
Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Real-world example
A cloud solutions architect for a retail company is evaluating services for a new workload. The correct answer here reflects best practice for the specific scenario described — not a general cloud recommendation. Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option. Cloud exam questions reward reading the constraint carefully: the same technology can be right or wrong depending on the use case.
What to study next
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
Monitor and optimize database performance — study guide chapter
Learn the concepts, then practise the questions
Monitor and optimize database performance practice questions
Targeted practice on this topic area only
All PCDE questions
503 questions across all exam domains
Google Professional Cloud Database Engineer study guide
Full concept coverage aligned to exam objectives
PCDE practice test guide
How to use practice tests most effectively before exam day
Related practice questions
Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.
Practise PCDE questions linked to Plan and manage database infrastructure.
Practise PCDE questions linked to Define data structures and implement SQL for Business Intelligence.
Practise PCDE questions linked to Design and implement database schemas.
Practise PCDE questions linked to Monitor and optimize database performance.
Practise PCDE questions linked to PCDE fundamentals.
Practise PCDE questions linked to PCDE scenario.
Practise PCDE questions linked to PCDE troubleshooting.
Practice this exam
Short sessions build daily habit. Longer sessions build exam-day stamina. Try a timed session to simulate real conditions.
FAQ
Monitor and optimize database performance — This question tests Monitor and optimize database performance — Read the scenario before looking for a memorised answer..
The correct answer is: Lock waits — The 'Lock waits' metric in Cloud SQL (for MySQL, PostgreSQL, or SQL Server) directly tracks the number of queries that are blocked because they are waiting for a lock held by another transaction. This is the correct indicator of query contention, as it measures the count of statements currently in a lock-wait state, not the total queries or connections.
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
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: Jun 25, 2026
This PCDE 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 PCDE 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.