PCDE Design and implement database schemas Practice Question
This PCDE practice question tests your understanding of design and implement database schemas. 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.
A financial services company uses Cloud Spanner for a global transaction processing system. They notice that certain read queries on a table with frequent writes are returning stale data even though they use strong reads. The table has a primary key of (user_id, transaction_id) and a secondary index on (timestamp). What is the most likely cause of the stale reads?
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.
Clue: "primary"
Why it matters: Asks for the main purpose or function, not a secondary benefit. Eliminate answers that describe side-effects or partial functions.
Why wrong: Strong reads ignore the timestamp; they return the latest data.
B
The query is using a secondary index that has not yet been updated with the latest write.
Secondary indexes can lag behind the base table; a strong read on the index may return stale data if the write committed after the index was last updated.
C
The query is reading from a read-only replica.
Why wrong: Read-only replicas support strong reads with consistent data.
D
Cloud Spanner is using eventual consistency for this query.
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The query is using a secondary index that has not yet been updated with the latest write.
Option B is correct because in Cloud Spanner, secondary indexes are implemented as separate tables that are updated asynchronously relative to the base table. When a strong read uses a secondary index, the read may still see a stale version of the index if the write has not yet been fully replicated to the index table. This is a known behavior: strong reads guarantee consistency only when reading from the base table using the primary key, not when using a secondary index.
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 query is using a stale read timestamp.
Why it's wrong here
Strong reads ignore the timestamp; they return the latest data.
✓
The query is using a secondary index that has not yet been updated with the latest write.
Why this is correct
Secondary indexes can lag behind the base table; a strong read on the index may return stale data if the write committed after the index was last updated.
Clue confirmation
The clue words "most likely", "primary" in the question point toward this answer.
Related concept
Read the scenario before looking for a memorised answer.
✗
The query is reading from a read-only replica.
Why it's wrong here
Read-only replicas support strong reads with consistent data.
✗
Cloud Spanner is using eventual consistency for this query.
Why it's wrong here
Strong reads guarantee external consistency.
Common exam traps
Common exam trap: answer the scenario, not the keyword
The trap here is that candidates assume 'strong reads' guarantee consistency for all queries, but Cloud Spanner's strong consistency guarantee applies only to reads that use the primary key; secondary index reads may return stale data because the index is updated asynchronously.
Detailed technical explanation
How to think about this question
Under the hood, Cloud Spanner uses the TrueTime API to assign timestamps to writes and reads. When a write commits, the base table is updated immediately, but secondary indexes are updated asynchronously via a separate write operation that may have a later timestamp. A strong read that uses a secondary index will read from the index table at the current timestamp, but if the index write hasn't completed, the read may return data that is older than the base table. This is a subtle behavior that often surprises developers who assume strong reads are always consistent regardless of the access path.
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 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
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.
Design and implement database schemas — This question tests Design and implement database schemas — Read the scenario before looking for a memorised answer..
What is the correct answer to this question?
The correct answer is: The query is using a secondary index that has not yet been updated with the latest write. — Option B is correct because in Cloud Spanner, secondary indexes are implemented as separate tables that are updated asynchronously relative to the base table. When a strong read uses a secondary index, the read may still see a stale version of the index if the write has not yet been fully replicated to the index table. This is a known behavior: strong reads guarantee consistency only when reading from the base table using the primary key, not when using a secondary index.
What should I do if I get this PCDE 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", "primary". 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 →
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.
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.