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.
An enterprise development team is preparing to release major architectural updates to a mission-critical REST API deployed on Google Cloud. The update introduces backward-incompatible changes to several request and response schemas.
The operations and API governance teams have established the following requirements:
Which API lifecycle and versioning strategy should you recommend?
Implement the breaking changes under a new major version base path (e.g., /v2) alongside /v1 in a unified backend service, deploy separate OpenAPI configurations for both versions, and monitor per-version traffic in service analytics until /v1 can be safely retired
Provision a new Google Cloud project with separate load balancers and isolated gateway proxies for /v2, leaving /v1 in the original project to isolate telemetry until decommissioning
Increment the patch version number in the OpenAPI configuration while maintaining identical URIs, using custom HTTP request headers to route traffic conditionally between legacy and updated backend microservices
Increment the minor version number in the existing OpenAPI configuration file (e.g., 1.1), redeploy the API over the /v1 base path, and rely on API gateway request-transformation policies to adapt breaking payload structures dynamically
Major API versioning via path prefixes (such as /v1 and /v2) is the standard practice for introducing backward-incompatible (breaking) changes in RESTful architectures. By maintaining distinct OpenAPI specifications or API proxies for each major version while implementing them concurrently within a single backend service, organizations can serve multiple API generations simultaneously without duplicating hosting infrastructure.
/v1 endpoints without failing due to unexpected schema modifications. Consumers migrate to the /v2 base path on their own development timelines./v1 and verify when active requests reach zero./v1, /v2) provide explicit contracts for consumer integration.This architecture balances seamless developer transition with operational simplicity. It allows development teams to release breaking innovations without impacting existing clients while giving operations clear observability to govern the API lifecycle safely.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Still curious? Scout, our AI tutor, can explain this concept further and answer your follow-up questions.