Separation of environments is one of those CI/CD concepts that sounds obvious until you have to map it onto Google Cloud and explain how it lines up with continuous integration and continuous delivery. The Professional Cloud Architect exam tests this directly, so it is worth being precise about what each environment does and how GCP isolates them.
The standard pipeline moves code through four stages: Development, Testing, Staging, and Production. Each stage has a specific job, and code only progresses once it has passed the requirements of the previous stage.
Development is where new code is written, tested, and refined. Developers focus on building features, fixing bugs, and running unit tests to catch immediate issues. It is rapid and iterative, aimed at getting code ready for further testing.
Testing is where integrated tests run to verify the new code works alongside other components. The point is to identify bugs and compatibility issues early. There is a feedback loop here: if Testing finds a bug, the code goes back to Development to be fixed before it can move on. That loop between Development and Testing is what keeps quality high before code is pushed further.
Staging is a production-like environment for final testing, including performance and security checks. Because it mirrors Production closely, Staging is the last line of defense for catching issues before code goes live.
Production is the live environment that end-users interact with. It requires high stability, consistent monitoring, and quick rollback options if something goes wrong.
Development and Testing correspond to the Continuous Integration part of CI/CD. These stages are about making changes and testing them frequently so new code integrates smoothly. Staging and Production correspond to the Continuous Delivery part. These stages are about getting code ready for deployment and safely delivering it to end-users.
This is a useful mental model for the Professional Cloud Architect exam. If a question asks where automated integration tests run, that is CI territory, which means Development and Testing. If it asks about safe deployment to end-users, that is CD territory, which means Staging and Production.
In Google Cloud, these environments are typically managed as distinct GCP projects. One project for Development, one for Testing, one for Staging, one for Production. Code is then deployed and promoted from one project to the next using Cloud Build to automate the process.
Setting up separate Google Cloud projects for development, staging, and production provides the highest level of isolation. Different environments cannot inadvertently affect each other, and access controls can be tightly managed across them. This separation is critical for security, particularly when production resources must remain protected from non-production activity.
The project boundary in GCP is the unit of isolation. IAM, billing, quotas, networking, and resources are all scoped to a project. Putting Production in its own project means a developer with broad access in the Development project has no access to Production resources unless explicitly granted. Quotas in Development cannot be exhausted by a runaway test job and starve Production. Billing for Production is cleanly separated for cost tracking. A misconfigured firewall rule in Staging cannot accidentally expose a Production database.
Cloud Build is the service that moves code through these projects. A pipeline triggers on a commit, runs unit tests in Development, deploys to Testing for integration tests, promotes a passing build to Staging for performance and security checks, and finally promotes to Production. Each promotion is automated, which is what makes it Continuous Delivery rather than manual handoffs between teams.
Because the projects are separate, Cloud Build needs the right service account permissions to deploy across them. A common pattern is to run Cloud Build in a dedicated CI/CD project and grant its service account deploy permissions into Development, Testing, Staging, and Production projects. That keeps the pipeline itself centralized while preserving the isolation of the runtime environments.
For the Professional Cloud Architect exam, the key facts are: four environments (Development, Testing, Staging, Production), Development and Testing align with CI, Staging and Production align with CD, the loop between Testing and Development exists to catch bugs before they progress, and the correct GCP implementation is separate projects per environment with Cloud Build promoting code between them. That combination gives you isolation, tight access control, and reliable deployments.
My Professional Cloud Architect course covers environment separation in CI/CD pipelines alongside the rest of the architecture and compliance material.
