Prepare and test your skills
Prepare and test your skills
Orchestration of multi-step test pipelines in Cloud Build (opens in a new tab) is the practice of defining an ordered set of containerized tasks in a build configuration file. The configuration file declares the source code to test, the test suites to run, and the artifacts to produce. Each task runs in its own isolated container in a fixed order, so integration tests are reproducible and later steps run only when earlier tests pass.
A Cloud Build configuration file is a YAML or JSON file, typically named cloudbuild.yaml or cloudbuild.json, that contains a steps list. Each entry in the steps list is a build step with a name field that selects a container image, an args field that passes arguments to that image, and an optional entrypoint field that overrides the default command. Executing build steps is like executing commands in a script, so Cloud Build runs the steps in listed order and stops the build when a step fails.
The standard lifecycle submitted through the Cloud Build API (opens in a new tab) flows in a fixed order:
requirements.txt and a Dockerfile.docker run.This order creates a dependency chain where the test pipeline depends on the configuration file and the published artifact depends on successful completion of all prior steps. Build results and logs flow from each worker to the Build History page, the gcloud CLI, and the Cloud Build API for inspection.
Isolated execution in Cloud Build means each build step runs in its own Docker container on its own worker, attached to a local Docker network named cloudbuild. The cloudbuild network allows containers from different steps in the same build to communicate and share data from the shared workspace. Each build runs on an isolated worker in a secure hosted environment, and Cloud Build provisions a new virtual machine environment for every build and destroys it afterward, so no residual files affect the next run.
The container image selected by the name field controls the tools available in that isolated environment:
gcr.io/cloud-builders/docker for Docker commands.python, Ubuntu, and Gradle, including the public python image preinstalled with python and pip.Choose a supported builder such as gcr.io/cloud-builders/docker when running standard docker build and docker push operations, choose a language image such as python when installing dependencies and running test frameworks, and choose google/cloud-sdk when invoking gcloud commands. This separation keeps each test suite reproducible because its dependencies, entrypoint, and arguments travel with the step definition.
A multi-step integration test pipeline chains dependency installation, test execution, containerization, and publishing into one ordered flow. Data flows from the source checkout to the install step, then to the test step, then to the image build, and finally to Artifact Registry and Cloud Storage. A typical Python pipeline first runs pip install -r requirements.txt --user in a python image with entrypoint: pip, where the --user flag ensures modules installed in that step remain accessible to subsequent steps.
The test step then runs in the same python image with entrypoint: python and args such as -m pytest --junitxml=${SHORT_SHA}_test_log.xml. The ${SHORT_SHA}, ${PROJECT_ID}, and custom $_BUCKET_NAME or $_ARTIFACT_REGISTRY_REPO values are substitutions replaced at build time, so the same configuration tags images and log files with the commit that produced them. Only after the test step succeeds does the pipeline run docker build -t with the gcr.io/cloud-builders/docker image, push the tagged image to an Artifact Registry Docker repository, and optionally deploy with gcloud run deploy from the google/cloud-sdk image. Details for Python workflows are covered in build and test Python applications (opens in a new tab) and build, test, and containerize Python applications (opens in a new tab).
Test evidence flows from the test container to durable storage through the artifacts and images fields. The artifacts.objects field copies the JUnit XML log to a Cloud Storage location such as gs://${_BUCKET_NAME}/, while the images field pushes the built container to Artifact Registry and surfaces it in build results. Additional step fields such as env for region and zone, timeout such as 240s for long operations, and id for tracking phases further control how each isolated step behaves within the overall safeguard builds (opens in a new tab) orchestration.
Exam tip: Use the images field plus requestedVerifyOption: VERIFIED in options to generate SLSA build provenance, instead of using only a separate docker push step.
Management of ephemeral dependencies and service linking in Cloud Build (opens in a new tab) is the practice of starting backing services as temporary containers for one build and letting test steps reach them over a shared network. Cloud Build executes each build on a fresh virtual machine (VM) worker that is destroyed afterward, and it runs every build step as a Docker container attached to a local Docker network named cloudbuild. This combination gives integration tests a clean, production-like set of dependencies for every run without leaving state behind.
The ephemeral build environment in Cloud Build is a temporary VM that exists for one build invocation only. Cloud Build provisions a new, isolated worker for each build on its secure hosted environment, runs the build configuration on that worker, and then wipes or destroys the environment after the build completes. Because no files, installed packages, or environment settings carry over, builds start clean and cannot be affected by residue from a previous run. Ephemerality also improves security by removing the chance for an attacker to leave malicious files in a reused environment and reduces maintenance overhead from managing long-lived builders.
A Cloud Build build is defined in a build configuration file in YAML or JSON format, and Cloud Build executes that configuration as a series of build steps where each step runs as an instance of docker run. Cloud Build currently runs Docker engine version 20.10.24, and a step can use any publicly available image such as python, Ubuntu, or Gradle, plus specialized builders. Builders come from three peer sources:
A typical integration-test configuration uses these steps to fetch dependencies, run unit tests, run static analyses and integration tests, and then create artifacts such as Docker containers or Java archives with tools including docker, gradle, maven, bazel, and gulp. Guidance for Python projects is described in build and test Python applications (opens in a new tab) and build, test, and containerize Python applications (opens in a new tab).
Service linking in Cloud Build is provided by the local Docker network named cloudbuild to which every build-step container is attached. The cloudbuild network lets containers in different steps communicate with each other and share data during the build, so a test step can send requests to a backing-service container started in another step. The flow moves from the dependency container to the network to the test container, which simulates production-like interaction between microservices without requiring external infrastructure. Because the network exists only inside the ephemeral worker, all linked services disappear together when Cloud Build destroys the VM after the build.
Exam tip: Every build-step container attaches to a local Docker network literally named cloudbuild; use that network name for step-to-step communication.
Dependency management in Cloud Build follows an ordered lifecycle where later steps depend on work installed or started by earlier steps. The general lifecycle accessed through the Cloud Build API (opens in a new tab) runs in this order:
Within that order, a Python example installs shared libraries with pip install -r requirements.txt --user, where the --user flag ensures that subsequent build steps can access the installed modules. A later step then runs python -m pytest and saves results to a JUnit XML file named with ${SHORT_SHA}, and still-later steps build, push, and deploy only after those tests pass. If the build needs resources in a private network rather than the public internet available to the default pool, the build depends on a private pool, which is a dedicated, customer-specific set of workers with private-network access.
Security Integration and Outcome Analysis is the practice of running automated integration tests in Cloud Build (opens in a new tab) without exposing credentials and using the build result to decide whether code can move forward. Secret Manager (opens in a new tab) supplies passwords, API keys, and other sensitive values to test steps at runtime, while build exit status and execution logs act as automated quality gates in the CI/CD pipeline. Only builds where tests and checks succeed continue to image building and deployment.
Secret Manager is the Google Cloud service that securely stores API keys, passwords, and other sensitive data outside source code and build files. Integration tests that need a database password, third-party API key, or Docker credential store that value in Secret Manager and configure Cloud Build to read it during the build. Before use, the Cloud Build and Secret Manager APIs must be enabled, which requires the serviceusage.services.enable permission through the Owner role or Service Usage Admin role, and the secret name and version must be recorded.
Access to secrets in Cloud Build is controlled by granting the build service account the Secret Manager Secret Accessor role (roles/secretmanager.secretAccessor) on the specific secret. The service account that runs the build fetches the secret value, so developers do not need direct access to the secret to run tests. Access is granted in the Google Cloud console:
Granting this role to the legacy Cloud Build service account carries extra risk because any user who runs a build through a build trigger inherits the service account permissions at build time. A user without the Secret Accessor role can then run a trigger that reads the secret, and that action is recorded in the project build history.
Mapping secrets into integration test steps connects a secret version in Secret Manager to an environment variable inside a specific build step. After all build steps in cloudbuild.yaml or cloudbuild.json, an availableSecrets field with a secretManager entry defines each mapping through versionName, the path to the secret version, and env, the local variable name. The test step then declares which mapped variables it may use through its secretEnv field, and data flows from Secret Manager to that step only.
A step that uses a UTF-8 secret must set its entrypoint to bash and start its args with the -c flag, so any string after -c runs as a bash command that can reference the environment variable. This requirement prevents the secret from being hardcoded in the configuration, Dockerfile, or .env file. The secret value is fetched at runtime using the build service account identity, which keeps test credentials for databases, APIs, and registries out of logs and source control.
Enforcing quality gates from test results means the outcome of the integration test steps decides whether later pipeline work is allowed to run. A typical Cloud Build routine for integration testing follows an ordered sequence:
/workspace directory.$COMMIT_SHA.pipeline.json, are uploaded to Artifact Registry.A failed test command fails its build step and fails the build execution, and the associated commit shows a Failure commit status. To investigate, the repository page provides a Details link next to the failed status that opens the Cloud Build execution log with troubleshooting guidance (opens in a new tab). Additional integrity controls that support OWASP Top 10 mitigation (opens in a new tab) can run in the same gate, including static analysis of code and configuration, policy-as-code rule checks, and limits on the number of simultaneous changes.
Exam tip: A build step can only read a mapped secret when it sets secretEnv for that variable, uses the bash entrypoint, and starts args with -c.
steps list in cloudbuild.yaml or cloudbuild.json in order, and each step runs as an isolated Docker container selected by its name image with args and optional entrypoint.cloudbuild, and each build runs on a fresh virtual machine worker that Cloud Build destroys afterward.artifacts.objects field copies test logs such as JUnit XML files to Cloud Storage, while the images field pushes built containers to Artifact Registry.availableSecrets mapping with versionName and env, and the step must declare secretEnv, use the bash entrypoint, and start args with -c.$COMMIT_SHA are built and published only after tests pass.Cloud Build executes the steps list in cloudbuild.yaml or cloudbuild.json in listed order, with each step running as an isolated Docker container selected by its name image with args and optional entrypoint. Execution stops when a step fails, so later steps such as image building run only when earlier tests pass.
Every build-step container attaches to a local Docker network named cloudbuild, which lets containers in different steps communicate and share data during the build. Each build runs on a fresh virtual machine worker that Cloud Build provisions for one build and destroys afterward, so linked services disappear together without leaving residual files.
Secret Manager secrets reach a build step through an availableSecrets mapping with versionName and env defined after all build steps, and the step must declare secretEnv for that variable. A step that uses a UTF-8 secret must set its entrypoint to bash and start its args with -c so the following string runs as a bash command, and the secret value is fetched at runtime using the build service account identity.
Last updated