PROFESSIONAL-CLOUD-DATABASE-ENGINEER · Question #125
You are designing an augmented reality game for iOS and Android devices. You plan to use Cloud Spanner as the primary backend database for game state storage and player authentication. You want to…
The correct answer is D. Use granular instance sizing in Cloud Spanner and Autoscaler. The scenario states costs are high but query response times are within SLA, meaning the database is over-provisioned. Option D is correct because Cloud Spanner's granular instance sizing allows you to provision in smaller units called processing units (100 PU increments) rather…
Question
You are designing an augmented reality game for iOS and Android devices. You plan to use Cloud Spanner as the primary backend database for game state storage and player authentication. You want to track in-game rewards that players unlock at every stage of the game. During the testing phase, you discovered that costs are much higher than anticipated, but the query response times are within the SLA. You want to follow Google-recommended practices. You need the database to be performant and highly available while you keep costs low. What should you do?
Options
- AManually scale down the number of nodes after the peak period has passed.
- BUse interleaving to co-locate parent and child rows.
- CUse the Cloud Spanner query optimizer to determine the most efficient way to execute the SQL
- DUse granular instance sizing in Cloud Spanner and Autoscaler.
How the community answered
(26 responses)- A4% (1)
- B19% (5)
- C8% (2)
- D69% (18)
Explanation
The scenario states costs are high but query response times are within SLA, meaning the database is over-provisioned. Option D is correct because Cloud Spanner's granular instance sizing allows you to provision in smaller units called processing units (100 PU increments) rather than full nodes (1000 PU each), which reduces baseline cost. Paired with the Autoscaler tool, Cloud Spanner automatically scales capacity up during peak load and down during off-peak periods, following Google-recommended best practices for cost optimization without sacrificing availability or performance. Option A (manual scaling) is reactive and error-prone, not a Google-recommended practice. Option B (interleaving) improves read/write performance for parent-child relationships but does not reduce costs. Option C (query optimizer) is enabled by default and addresses query efficiency, not infrastructure cost.
Topics
Community Discussion
No community discussion yet for this question.