Design innovative, scalable, and highly available cloud database solutions →mediumMultiple ChoiceObjective-mapped
PCDE Practice Question: Design innovative, scalable, and highly available cloud database solutions
A company uses Bigtable for time-series data with a row key format: 'deviceID#timestamp'. They notice write hotspotting on a few devices that generate high volumes of data. How should they redesign the row key to distribute writes evenly?
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
✓
Add a random salt prefix to the row key: 'random_number#deviceID#timestamp'
Hotspotting occurs because rows for a single high-volume device all share the same deviceID prefix, causing writes to be directed to a single tablet. To distribute writes evenly, the row key must include a non-deterministic or varying component. Option A adds a random salt per write, which scatters the keys for the same device across many tablets, effectively distributing the load. Option B still uses deviceID as the first part, so it doesn't spread writes. Option C creates monotonically increasing keys, leading to sequential writes and hotspotting. Option D does not change the row key, so it fails to address the prefix issue.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Add a random salt prefix to the row key: 'random_number#deviceID#timestamp'
Why this is correct
This uses a hash of deviceID, which is deterministic per device. All writes from a single device will have the same prefix and land on the same tablet, failing to distribute the load from that device.
- ✗
Reverse the timestamp: 'deviceID#reverse_timestamp'
Why it's wrong here
Reversing the timestamp does not change the leading deviceID; the row key still starts with deviceID, so all writes from the same device remain on the same tablet.
- ✗
Use a monotonically increasing integer for the row key.
Why it's wrong here
A monotonically increasing integer as row key causes all writes to go to the last tablet, creating even worse hotspotting.
- ✗
Store all data in a single column family and use column qualifiers for timestamps.
Why it's wrong here
Storing data in a single column family and using column qualifiers for timestamps does not alter the row key structure, so it does not help distribute writes.
Go deeper
Related to this question
About these practice questions
Courseiva writes every PCDE question from scratch — 1,446 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.