Container security on Google Kubernetes Engine has three layers that the Professional Cloud Architect exam expects you to know in order: scanning, attesting, and enforcing. Vulnerability scanning tells you what's wrong with an image. Attestations turn the results of your build pipeline into cryptographic proof. Binary Authorization is the gate that decides whether an image with that proof is allowed to run.
I want to walk through each one in the order they appear in a real CI/CD pipeline, because that's how the questions are framed.
When you push a container image to Artifact Registry or the older Container Registry, GCP automatically scans the image by comparing its contents against a database of known vulnerabilities. The database is built around CVEs, which is the standard catalog of Common Vulnerabilities and Exposures used across the industry.
The mechanics are straightforward. The scanner reads the layers of the image, identifies installed packages and libraries, looks each one up against the CVE database, and produces a findings report. The report tells you which vulnerabilities exist in the image, the severity of each one, and what's required to remediate them.
The point of doing this in the registry, before deployment, is that you catch issues while the image is still a candidate. You haven't promoted it. You haven't scaled it across a cluster. You can fix the underlying package, rebuild, and rescan, all without touching production.
For the exam, remember that the scanning happens in the registry layer, not at runtime, and that Artifact Registry is the modern home for it. Container Registry still works but is the legacy product.
A vulnerability scan tells you something about an image. An attestation is how you record that something happened, in a way another system can verify later.
An attestation is a cryptographic signature that proves a container image meets predefined security or compliance requirements. It's generated by a trusted process, signed by a key that process controls, and bound to a specific image digest. If the image changes, the attestation no longer applies.
Attestations are typically created as part of a CI/CD pipeline. The pipeline runs the build step, runs tests, runs a vulnerability scan, and if all of those pass, it produces an attestation. That attestation is the receipt. It says "this exact image, identified by this exact digest, passed the checks I'm authorized to certify."
The reason attestations matter for a Professional Cloud Architect is that they decouple the act of checking an image from the act of trusting it. The pipeline checks. The attestation records the check. The deployment system trusts the attestation. You don't need to rerun the scan at deployment time, and you don't need to trust the deployer to do the right thing. You only need to trust the signing key.
Binary Authorization is the GCP service that enforces the policy. It's the gate that sits between an image and a running cluster, and it decides whether the image is allowed to be deployed.
The word "binary" here is broader than just containers. The service is designed to apply to any binary executable, although in practice on GCP you'll see it paired with GKE and container images.
You use Binary Authorization by defining a policy. The policy specifies the criteria an image must meet before it's allowed to run. Common criteria include:
When a deployment is attempted, Binary Authorization evaluates the image against the policy. If the policy is satisfied, deployment proceeds. If not, the deployment is blocked. There's no override at the cluster level for an image that fails policy. That's the entire point.
The mental model I use for the three steps is: define the policy, run the policy check, get a decision. The policy is static and lives in your project configuration. The check happens at the moment a Pod is being scheduled. The decision is binary, allow or block.
The three pieces are designed to compose. A Professional Cloud Architect should be able to read a scenario and identify which layer is doing what.
Vulnerability scanning produces information. It runs in Artifact Registry and tells you what's in the image and what risks come with it.
Attestations produce proof. They run in your CI/CD pipeline after a check passes, and they bind the result of the check to a specific image digest using a cryptographic signature.
Binary Authorization produces enforcement. It runs at deployment time, evaluates whether the image satisfies a policy that may require attestations and clean scans, and either allows or blocks the deployment.
If a question asks how to make sure only images that have passed a security scan can run on a GKE cluster, the answer is the full chain: scan in Artifact Registry, generate an attestation in the pipeline once the scan passes, and configure Binary Authorization to require that attestation. No single piece does it on its own.
If a question asks specifically about blocking unverified images at deployment, the answer is Binary Authorization. If it asks about the cryptographic proof that an image passed a check, the answer is attestations. If it asks about identifying CVEs in an image stored in a registry, the answer is vulnerability scanning.
My Professional Cloud Architect course covers vulnerability scanning, attestations, and Binary Authorization alongside the rest of the containers and serverless material.
