Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!
Prepare and test your skills
Prepare and test your skills
Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Last updated
An enterprise organization runs a central monitoring service that programmatically queries Google Cloud APIs across hundreds of projects using official Google Cloud Client Libraries.
During peak batch reconciliation periods, the service encounters frequent failures due to two main operational challenges:
StudyCerts
StudyCertsHTTP 429 Too Many Requests and transient HTTP 503 Service Unavailable exceptions, leading to cascading retry storms.You need to implement an API interaction and error management strategy that follows Google Cloud operational best practices.
Which approach should you implement?
Implement truncated exponential backoff with randomized jitter for transient errors (such as HTTP 429 and 5xx), and leverage token-based pagination using page tokens to process large resource lists in discrete batches.
Catch all HTTP 4xx client errors to immediately execute linear backoff retries, while buffering full dataset responses into local temporary disk storage before batch processing.
Configure fixed-interval retries with immediate reconnect loops for failed requests, and maximize the API request page size limit to retrieve all items in a single round trip.
Configure an aggressive circuit breaker to permanently drop failed requests upon receiving HTTP 429 codes, and use client-side multithreaded slicing across numeric offset parameters.
Implement truncated exponential backoff with randomized jitter for transient errors (such as HTTP 429 and 5xx), and leverage token-based pagination using page tokens to process large resource lists in discrete batches.
Exponential backoff with randomized jitter is an algorithmic error-handling strategy where the retry interval increases exponentially with each failed attempt (e.g., 1s, 2s, 4s, 8s, up to a maximum truncated threshold) while adding random variance (jitter). Token-based pagination utilizes API-provided continuation tokens (nextPageToken / pageToken) and page size limits (pageSize / maxResults) to stream and process large datasets incrementally rather than pulling entire record sets into memory at once.
HTTP 429 / 503), exponential backoff introduces progressively longer delays. Adding randomized jitter desynchronizes concurrent worker retries, completely preventing the "thundering herd" problem and retry storms.Combining randomized exponential backoff with iterative page traversal addresses both network resilience and memory management simultaneously, fulfilling enterprise robustness standards for high-throughput cloud automation.
Catch all HTTP 4xx client errors to immediately execute linear backoff retries, while buffering full dataset responses into local temporary disk storage before batch processing.
Configure fixed-interval retries with immediate reconnect loops for failed requests, and maximize the API request page size limit to retrieve all items in a single round trip.
Configure an aggressive circuit breaker to permanently drop failed requests upon receiving HTTP 429 codes, and use client-side multithreaded slicing across numeric offset parameters.