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

A horizontal process flow showing source code built by Cloud Build, which generates signed provenance and an attestation stored with the image in Artifact Registry, then verified by Binary Authorization before deployment to GKE or Cloud Run.
Remote repositories cache packages from external sources to improve availability and reduce download times, while virtual repositories combine multiple repositories behind a single endpoint to prevent an attack called dependency confusion.
Binary Authorization checks for attestations, which are digital signatures that prove an image passed specific security checks, and attestors use public keys to verify the signer’s identity during deployment, relying on Public Key Infrastructure (PKI) to manage trust.
Ephemeral build environments are temporary, isolated workers that Cloud Build creates for a single task and destroys immediately, preventing attackers from persisting on a build server and ensuring every build starts from a clean, known state.
Cloud Build is Google Cloud's managed service for automating the creation of software artifacts. It helps teams achieve higher security levels, known as Supply-chain Levels for Software Artifacts (SLSA), by providing a secure and consistent build process. A key part of this is generating build provenance, which is a verifiable record of exactly how an artifact was created, including its source code and the tools used. This data allows you to confirm that your software is authentic and hasn't been tampered with before it is deployed.
To reach higher SLSA levels, the build service must record detailed information and sign it digitally. For example, SLSA Level 3 requires tracking all user-controlled settings and the exact build entry point. This makes the entire path from source code to final artifact transparent and very difficult to forge. A critical practice for securing this process is using ephemeral build environments. These are temporary, isolated workers that Cloud Build creates for a single task and destroys immediately after. This prevents attackers from persisting on a build server and ensures every build starts from a clean, known state.
Security is further strengthened by applying the principle of least privilege through dedicated service accounts that have only the minimum permissions needed. You can also use VPC Service Controls to create a security perimeter around the build process, preventing data theft. Finally, the verified build provenance created by Cloud Build can be used by Binary Authorization to enforce that only properly built and signed software is allowed to run in production.
Artifact Registry is the central place to store and manage your build artifacts, like container images and language packages. It acts as a single point of control for your software supply chain. To improve security and reliability, it offers features like remote repositories, which cache packages from external sources. This reduces download times and ensures availability even if the external site is down. It also provides virtual repositories, which combine multiple repositories behind one endpoint to prevent a specific attack called dependency confusion.
Artifact Analysis is a service that automatically scans your stored container images and packages for known security flaws. By comparing your artifacts against vulnerability databases, it helps you find and fix risks early. You can also use it to generate a Software Bill of Materials (SBOM), which is a complete list of every component inside your software. This is essential for understanding your dependencies and managing security updates.
To protect these stored artifacts, you must set up granular Identity and Access Management (IAM) policies. These policies control exactly which users or services can read, write, or modify items in the registry, following the principle of least privilege. Using VPC Service Controls adds another layer by creating a security boundary that stops data from being moved to unauthorized locations. Tracking build provenance—the verifiable metadata about how an artifact was built—is also a key part of maintaining integrity and establishing a trusted chain from code to deployment.
Binary Authorization is the final security gatekeeper for deploying container images on Google Cloud. It enforces policies that decide which images are allowed to run in environments like Google Kubernetes Engine (GKE) and Cloud Run. Its main job is to stop unauthorized or untrusted code from being deployed, which secures the last step of the software supply chain.
The service works by checking for attestations, which are digital signatures that prove an image has passed specific security checks (like a vulnerability scan). Attestors are the entities that verify these signatures during deployment, using public keys to confirm the signer's identity. This whole system relies on Public Key Infrastructure (PKI) to manage trust. For example, a policy could require that any image deployed to a production cluster must have a valid attestation from your security team's scanner.
These policies are configured by administrators and can set default rules or specific rules for different clusters. A policy might allow, deny, or simply log a deployment attempt. The build provenance data generated by services like Cloud Build, which follows the SLSA framework, provides the verified history needed to make these trust decisions. By automating this enforcement, Binary Authorization reduces human error and ensures consistent security standards are applied across your organization before any software executes.
An enterprise runs containerized workloads across Google Kubernetes Engine (GKE) and Cloud Run. The security compliance team establishes a mandatory software supply chain policy:
Which solution should you implement to enforce this deployment control?