mediumMultiple Choice
PDE Practice Question: Deploying a large-scale streaming application on…
A company is deploying a large-scale streaming application on Google Kubernetes Engine. They need to ensure the application can handle sudden traffic spikes without dropping data. Which architectural pattern is most appropriate?
⚠ Common exam trap
Candidates often confuse buffering with retry logic or database storage, failing to recognize that Pub/Sub is the Google Cloud-native service specifically designed for decoupling and buffering in event-driven architectures.
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
✓
Use a Pub/Sub topic as a buffer and autoscale consumer pods based on Pub/Sub subscription backlog.
Pub/Sub provides a durable, scalable, and asynchronous message buffer that decouples the producer from the consumer. By autoscaling consumer pods based on the Pub/Sub subscription backlog (e.g., using the 'pubsub.googleapis.com/subscription/num_undelivered_messages' custom metric with Horizontal Pod Autoscaler), the application can elastically handle traffic spikes without data loss, as messages are persisted until acknowledged.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Implement custom retry logic with exponential backoff in the application.
Why it's wrong here
Retry logic only re-sends failed messages after the fact; it does not absorb the spike, so the consumer still falls behind and data is dropped. It tempts because backoff genuinely helps with transient downstream errors, and would be right for handling intermittent API failures rather than burst buffering.
- ✗
Use Cloud SQL as a temporary buffer and process from there.
Why it's wrong here
Cloud SQL is a relational database, not a durable high-throughput queue; writes throttle under burst load and become the bottleneck. It tempts because a table can look like a work queue, and would suit low-volume job state or transactional records rather than streaming ingestion buffering.
- ✗
Pre-provision 3x the expected peak capacity to handle spikes.
Why it's wrong here
Static over-provisioning cannot track unpredictable spikes and wastes cost while still having a ceiling; the buffer, not the compute headroom, prevents drops. It tempts because capacity planning does help steady growth, and would suit predictable seasonal peaks rather than sudden, unpredictable traffic bursts.
- ✓
Use a Pub/Sub topic as a buffer and autoscale consumer pods based on Pub/Sub subscription backlog.
Why this is correct
Pub/Sub decouples ingestion from processing, absorbing traffic spikes as a durable buffer so no data is dropped. Autoscaling consumer pods on subscription backlog matches capacity to demand, directly satisfying the stem's requirement to handle sudden spikes without loss.
Visual reference
Go deeper
Related to this question
About these practice questions
Courseiva writes every PDE question from scratch — 747 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 PDE 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 PDE exam.