Anyone studying for the Professional Cloud Architect exam will run into questions about CI/CD pipelines, and one specific area that comes up is which type of test belongs at which stage. The answer is not arbitrary. There is a logical progression from fast and cheap tests at the beginning of the pipeline to slow and expensive tests at the end, and the exam expects you to recognize that ordering.
I want to walk through the layering I use as a reference model. Real pipelines vary in how many environments they have and what tools run them, but this progression is what the Professional Cloud Architect exam draws from when it asks about test placement.
The whole layering decision is driven by a single tradeoff. Tests that are faster, cheaper, and higher volume should run earlier. Tests that are slower and more expensive should run later. That is the rule that explains every placement choice below.
This balances two needs. You want fast feedback so developers know within minutes whether their commit broke something obvious. And you want deployment confidence so you do not push code to production that fails under realistic conditions. Layering the tests across stages gets you both.
The first stage is the build itself. In a Google Cloud pipeline this is usually Cloud Build, but the same idea applies whatever your build tool is. At this stage you run unit tests.
Unit tests are fast and require no infrastructure. They exercise individual functions and components in isolation. The question they answer is essentially "does the code run?" There is no database, no message queue, no other service. Just the unit of code under test.
Because unit tests are quick, you run them on every commit. They give you immediate feedback before anything gets deployed anywhere. If unit tests fail, the pipeline stops here and never produces a container image.
Once unit tests pass and the image is built and pushed to Artifact Registry, Cloud Deploy or whatever delivery tool you use promotes the build to your development environment. This is where you run integration tests and load tests.
Integration tests verify that components work together correctly. Unit tests prove a function works in isolation, but integration tests confirm that the function actually talks to its database, queue, or downstream service the way it should. They require deployed infrastructure, which is why they cannot run in the build stage.
Load tests answer a different question. Can the system handle expected traffic? You generate volume against the deployed app and confirm latency, error rates, and throughput hold up. Load tests are expensive to run because they need real infrastructure and real time, so dev is the right place for them. You get the signal without risking a production-shaped environment.
The next promotion is to staging, which is meant to be production-like. Here you run smoke tests.
Smoke tests are quick checks that the core functionality of the application works after deployment. They are not exhaustive. They confirm the fundamentals: can users log in, can they complete a basic transaction, do the most important features respond at all. The goal is to catch deployment-level breakage before promoting to production.
You do not repeat full integration or load coverage in staging. That work was done in dev. Staging is about verifying the deployment itself succeeded against a production-like setup.
The last layer runs in production with real user traffic. These are acceptance tests.
Acceptance tests answer whether business requirements are being met. They use actual production configurations and real user patterns. The signal is more about behavior at scale, with real data shapes and real customer flows, than about whether a single function works. You cannot get this kind of feedback in any earlier environment because no earlier environment has real users.
So the layered progression is unit tests in Cloud Build, integration and load tests in development, smoke tests in staging, and acceptance tests in production. The order follows the cost and volume tradeoff. Cheap, high-volume tests early. Expensive, lower-volume validation later. When the Professional Cloud Architect exam asks where a particular test type belongs, this is the model it is checking.
My Professional Cloud Architect course covers test layering in CI/CD pipelines alongside the rest of the advanced architecture material.
