Prepare and test your skills
Prepare and test your skills
Automated CVE scanning in a CI/CD pipeline means container images and language packages are checked for known vulnerabilities before they can be deployed. In Google Cloud, On-Demand Scanning (opens in a new tab) scans images during the build before storage, Artifact Analysis (opens in a new tab) stores vulnerability occurrences for images in Artifact Registry, and Cloud Build orchestrates the build, scan, gate, and push. Together they enforce a severity gate, produce triage data, and keep results fresh across rebuilds.
A blocking scan pipeline allows Cloud Build to push an image to Artifact Registry only when On-Demand Scanning finds no vulnerabilities at or above a configured severity threshold. The pipeline builds the image from source, extracts operating system and language packages and versions, compares findings to the SEVERITY value, and pushes only on success. When SEVERITY is set to CRITICAL|HIGH, the check looks for HIGH findings and the more severe CRITICAL findings, so either level triggers remediation.
The build-to-registry flow runs in a fixed order with a hard stop on failure:
SEVERITY threshold.A successful build reports STATUS: SUCCESS with the Artifact Registry image reference, while a failed build reports Failed vulnerability check and step exited with non-zero status: 1. Because base images such as debian10:latest and vulnerability data change over time, the same source can pass on one run and fail later. Remediation means updating the base image or dependent package to a fixed version, rebuilding in Cloud Build, and letting the gate verify the fix.
Automatic scanning and On-Demand Scanning differ in when they run and where they block the release. Automatic scanning monitors images after they are stored, while On-Demand Scanning blocks promotion before storage. Cloud Build depends on Artifact Analysis for results and on Artifact Registry to hold the trusted artifact and its scan metadata.
| Scanning mode | When scan runs | Typical CI/CD use |
|---|---|---|
| Automatic scanning in Artifact Registry | After each new image push, when enabled for the repository | Continuously monitor stored images for new OS, Maven, and Go CVEs |
| On-Demand Scanning API | During the build on local or remote images, before registry storage | Block promotion when severity exceeds policy |
When the Artifact Analysis API is enabled, Artifact Analysis automatically scans each new image pushed to Artifact Registry repositories in the project. Scanning for language packages is disabled by default, so the repository owner must explicitly control scanning settings for each repository. Choose automatic scanning for continuous visibility on stored artifacts, and choose On-Demand Scanning for a pre-push quality gate.
Exam tip: On-Demand Scanning can prevent a vulnerable image from reaching Artifact Registry because a failed check stops later Cloud Build steps, while automatic scanning detects vulnerabilities only after the image is already stored.
Triage of scan findings is the sorting of each vulnerability occurrence by identity, severity, and fix availability so owners know what to patch first. Artifact Analysis reports CVE name, effective severity and Common Vulnerability Scoring System (CVSS) score, fix status, affected package name and version, package type such as MAVEN, and affected location. Findings with fixes point to a version upgrade and rebuild, while findings without fixes require risk acceptance, isolation, or other controls until upstream data changes.
Data flows from the scanner to Artifact Analysis occurrences, then from occurrences to the selected reporting surface. The Google Cloud console supports interactive triage for one repository, image digest, or package version, with filtering, sorting, and up to 1200 vulnerabilities displayed per page. The Google Cloud CLI supports pipeline checks with list-vulnerabilities for an On-Demand scan name and artifacts versions describe --show-package-vulnerability for a stored package version. The Container Analysis API supports automation with occurrence lists, project-wide vulnerabilitySummary totals, and single-occurrence lookup by OCCURRENCE_ID. All three paths require permission to read scan metadata, including Artifact Registry Reader with Container Analysis Occurrences Viewer and Container Analysis Notes Viewer.
Scan freshness management tracks whether Artifact Analysis metadata is still updated or has become stale or archived based on pull activity. Artifact Analysis continues to refresh metadata only while the image or package has been pulled within the last 30 days. After 30 days without a pull, results become stale and are no longer updated, and after more than 90 days stale they become archived and can be evaluated only by using the API. Pulling a stale image restarts analysis, but refresh can take up to 24 hours, while stale packages cannot be rescanned until republished.
Artifact Guard extends the pipeline gate into centralized policy enforced at build, registry, and runtime. A security administrator defines severity thresholds, package and CVE allow and deny lists, and temporary exception grace periods for specific CVEs. Build-time scanning fails the build in Cloud Build, GitHub Actions, or Jenkins before publication, registry admission control depends on Binary Authorization to deny deployment of non-compliant Artifact Registry images to Google Kubernetes Engine (GKE) clusters, and runtime monitoring continuously re-evaluates running GKE containers for newly disclosed CVEs in Security Command Center.
Binary Authorization (opens in a new tab) is a deploy-time admission control that decides whether a container image is allowed to run on GKE and Cloud Run. A Binary Authorization policy contains evaluation rules that allow an image, block an image, or require verified attestations from named attestors before deployment. At deploy time, traffic flows from the deployment request to the Binary Authorization enforcer, which checks the image digest against the matching rule and verifies required attestations before the platform starts the workload.
Deployment verification in Binary Authorization uses cryptographic proof that required checks already passed instead of re-running tests at deploy time. An attestation is a signed statement about a specific immutable image digest affirming that an activity such as vulnerability scanning, regression testing, or build verification was completed. The signature binds the statement to the sha256: digest of the image manifest, so the same attestation authorizes identical images in Artifact Registry (opens in a new tab), Container Registry, or an external registry without a new signature after moving the digest.
The verification sequence runs in a fixed order:
IMAGE_PATH@IMAGE_DIGEST with an attestor signing key to record that the required check passed.Deploy with IMAGE_PATH@IMAGE_DIGEST, not with mutable tags such as 1.0 or latest, because Binary Authorization looks up attestations only by digest at admission time.
An attestor is the Binary Authorization resource that represents a trusted authority, such as build-secure or prod-qa, that is allowed to vouch for images. Each attestor depends on an Artifact Analysis note that stores attestation metadata as occurrences, and each attestor depends on an asymmetric signing key that proves who created the attestation. Keys can be managed in Cloud Key Management Service (Cloud KMS), where Cloud KMS protects the private material and Binary Authorization verifies with the public key, or as a local PKIX key file. The identity that creates attestations needs roles/containeranalysis.notes.attacher on the note and roles/containeranalysis.occurrences.editor on the attestation project.
The default rule in a policy is the baseline that applies to every workload without a more specific rule. A new policy starts with the default rule set to allow all images, so deployments proceed without checks until hardened. The default rule supports Allow All Images, Disallow All Images, and Require Attestations from named attestors. For GKE, cluster-specific rules can require attestations for one production cluster while the default remains permissive, and for Cloud Service Mesh rules can scope to a mesh identity, Kubernetes service account, or namespace. For Cloud Run, enforcement is enabled per service in Security settings, and every new revision flows from the service configuration to the enforcer before serving traffic.
Enforcement mode in Binary Authorization controls what happens when an image violates the policy at deploy time. In blocking mode, pre-deployment checks deny the deployment so only images with required attestations run. In dry-run mode, enforcement is disabled for testing so the deployment is allowed but the violation is logged. The deployment depends on both the policy rules and the selected mode, so the same image can be denied in one cluster and allowed with a warning in another.
Exempt images are container image paths that bypass attestation checks, defining a trust boundary around already-trusted registries. An exemption applies to the image path, not the workload, so any Pod referencing that path inherits the bypass. The list must stay narrow and limited to registries under direct control, such as platform infrastructure or hardened base images. Break-glass is a per-workload annotation that bypasses an otherwise blocking policy for one emergency deployment, such as an urgent fix during an outage. The tradeoff is speed versus assurance, so access to the annotation must be restricted and every use reviewed.
Exam tip: Dry-run is a policy-level test mode that allows all violating images but logs them, while break-glass is a per-workload emergency bypass that allows one annotated deployment through an otherwise blocking policy.
The automated signing workflow creates a verifiable link between an immutable digest and the checks that passed in continuous integration. First the pipeline runs gcloud container binauthz create-signature-payload with IMAGE_PATH@IMAGE_DIGEST to create a JSON payload, then signs the payload with the private key, then creates the attestation bound to the digest and attestor with validation, then lists attestations to confirm the record before deployment. With Cloud KMS the pipeline uses attestations sign-and-create in one step, while with a local key it uses payload creation, openssl dgst -sha256 -sign, and attestations create separately.
Pre-deployment enforcement blocks any image that lacks required attestations, while gated promotion adds approval between environments through Cloud Deploy approvals for GKE targets. Continuous validation (CV) extends the same policy check through the Pod lifecycle by logging non-conformance in Cloud Logging when the policy changes after deployment and when Pods were started with dry-run or break-glass. Changing to blocking does not retroactively stop running Pods, but continuous validation surfaces them for remediation, and auditing in Cloud Logging and Cloud Audit Logs records which image was evaluated and whether dry-run or break-glass caused an allow.
Automated image creation keeps virtual machine (VM) and container images current, secure, and compliant without manual rebuilds. In Google Cloud, Cloud Build executes the image build, Artifact Registry stores the image with security metadata, and Cloud Scheduler starts rebuilds on schedule. Together they pull base-image fixes, operating system patches, and organizational policies into new images, then rotate old images out before they are used by mistake.
A scheduled rebuild pipeline is an automated chain where Cloud Scheduler sends an authenticated HTTP request to a manual Cloud Build trigger, and the trigger builds and publishes a fresh image. The workflow runs in a fixed order where each stage depends on the prior output, moving the image from built to stored to scanned to approved. Developers can change versioned definitions in GitHub, but only the Cloud Build service account can push to the protected Artifact Registry repository, which enforces the trust boundary between mutable source and immutable output.
The ordered pipeline operates as follows:
cloudbuild.yaml, imagebuilder.yaml, Dockerfiles, and build scripts in GitHub connected to Cloud Build.0 1 * * * for 01:00 daily.Two service-account dependencies must succeed for the scheduled call to work. The service account that Cloud Scheduler acts as needs roles/cloudbuild.builds.editor to run the trigger, while the Cloud Build service account needs roles/artifactregistry.admin to upload the finished image. An administrator setting up the system typically needs Cloud Build Editor, Cloud Scheduler Admin or Job Runner, and Service Account User.
Hardened base images implement immutable infrastructure with strictly defined operating system, packages, users, and privileges. The organization defines the baseline once in code, then redeploys new images instead of patching running systems. A VM baseline starts from a trusted source family such as ubuntu-2004-lts from ubuntu-os-cloud and adds only required software, while a container baseline starts from a pinned minimal base image and adds only required layers. When a new vulnerability or Center for Internet Security (CIS) benchmark update appears, the team updates the definition and rebuilds rather than logging into running systems.
Packer (opens in a new tab) with Cloud Build produces hardened Compute Engine VM images, while Cloud Build triggers with Dockerfiles produce container images stored in Artifact Registry where Container Scanning applies. The Packer template declares variables for project, image name, family, and zone, declares a googlecompute source with source family and machine type, and declares shell provisioners that apply hardening such as installing approved packages and disabling services. The build depends on a Packer builder container stored in Artifact Registry, and the project must enable Compute, Service Management, Storage, and Artifact Registry APIs. Image Builder further orchestrates OS customization, validation on a temporary test VM, and publication, depending on Virtual Private Cloud connectivity with Private Google Access, Cloud NAT for external packages, and firewall rules for debugging.
Automated patch management for long-running VMs is delivered by VM Manager Patch, which has patch deployment for scheduling updates and patch compliance reporting for fleet visibility. A call to the VM Manager API from the console, CLI, or API notifies the OS Config agent on target VMs to start patching. The agent installs updates with the native tool for each distribution, including yum upgrade for Red Hat and CentOS, apt upgrade for Debian and Ubuntu, zypper update for SUSE, and Windows Update Agent for Windows. The service does not host packages, so each VM must reach its distribution source directly or through Cloud NAT, a proxy, or a local repository.
Patch compliance reporting turns inventory into a severity-ranked state. The OS Config agent reports OS inventory about every 10 minutes, the backend cross-references it with Red Hat security data, Debian tracker, Ubuntu CVE tracker, SUSE data, Rocky errata, or Windows Update data, and the console maps vendor categories to Critical (RED), Important/Security (ORANGE), Other (YELLOW), and Up-to-date (GREEN). A patch job runs on demand across a maximum of 500 VMs, while a patch deployment creates one-time or recurring scheduled jobs with a maximum of 500 VMs per deployment. Instance filters are evaluated at run time, maintenance windows stop starting new work after expiry while in-flight downloads or reboots can finish, rollout options limit zone order and disruption budgets, and reboot control plus pre-patch and post-patch scripts safely quiesce and verify applications.
Exam tip: DEPRECATED images can still launch new instances with a warning, while OBSOLETE images block new launches; use OBSOLETE when automation must not use the image.
Image lifecycle rotation groups related images, points users to the current version, and blocks stale versions. Compute Engine image families let deployments roll forward to a new image and roll back without hard-coding an image name. Rotation depends on the build pipeline publishing the latest successful output and on administrators deprecating images the family no longer points to with gcloud compute images deprecate.
| State | Can launch new instances | Behavior and use |
|---|---|---|
| DEPRECATED | Yes, with warning | Image is no longer latest but remains launchable; users are warned they are not on the most recent image. |
| OBSOLETE | No | Launch attempts fail; disk data remains available as a non-boot disk for archiving. |
| DELETED | No | Image is deleted or marked for future deletion; remove with an explicit delete command. |
Administrators attach future deletion with --delete-in or --delete-on and future obsolescence with --obsolete-in or --obsolete-on. Deprecated and deleted images are hidden from API and console results by default but appear with --show-deprecated for audit. This pattern prevents stale-image sprawl while preserving a rollback path through the family.
Preventive and detective controls at scale block misconfigurations before creation and surface drift after deployment. The Organization Policy Service evaluates constraints at request time to prevent risky resources, while Security Command Center posture combines those constraints with Security Health Analytics detectors to define and monitor the known good state. Cloud Asset Inventory, Pub/Sub, and event-driven compute then carry change events to automation that remediates drift.
Custom organization policy constraints are user-defined rules that govern specific fields of supported Google Cloud resources with Common Expression Language (CEL) expressions. Managed constraints are predefined rules supplied by Google that enforce one fixed behavior. The request flows from the user or automation to the service API and then to the policy engine for an allow or deny decision, which prevents the misconfigured resource from existing rather than flagging it afterward.
| Option | Defined by | Choose when |
|---|---|---|
| Managed constraint | Google Cloud with fixed behavior | A predefined control applies, such as blocking public buckets, blocking default networks, or blocking service-account key creation |
| Custom constraint | Administrator with CEL on a resource field | Fine-grained control is needed, such as approved machine families, disk sizes, firewall tags, or health-check protocols |
Hierarchical inheritance flows from organization to folder to project to resource, so descendants inherit parent policy by default. Place broad baselines high for consistent posture and narrower constraints lower for single folders or projects. Conditional tag-based enforcement further scopes a policy attached at organization, folder, or project level to only resources matching tags such as environment:prod, separating placement from intent without creating extra folders.
The author-to-enforcement workflow rolls out a custom constraint safely through definition, attachment, simulation, and enforcement. The constraint definition, policy attachment, and enforcement mode are separate objects, which allows dry-run testing before blocking production changes. Dry-run depends on representative traffic and inventory, so it must run long enough to observe automation and manual workflows.
The ordered rollout operates as follows:
Common preventive patterns restrict VM machine families and disk sizes, mandate firewall tags and Network Service Tiers, require Cloud CDN on backend buckets, block long-lived keys and automatic Editor grants, and require trusted image projects without default networks.
A security posture in Security Command Center is one or more policy sets that enforce preventive and detective controls for a standard. A policy set groups policies for one regulation, a policy is a single constraint or detector, and a posture deployment applies the posture to an organization, folder, or project. Supported policies are Organization Policy constraints for prevention and Security Health Analytics detectors for detection. The posture service is enabled when Security Command Center is activated at organization level on Premium tier.
Real-time drift remediation connects inventory and findings to automation in an event-driven loop. After deployment, Security Command Center reports drift as findings, Cloud Asset Inventory feeds emit asset change events, and both flow through Pub/Sub to Cloud Functions or Cloud Run functions. The function evaluates the event against the Infrastructure-as-Code baseline, executes remediation such as reverting configuration or re-applying Terraform, and writes a new finding for audit. Security Command Center then rescans and clears the finding when the resource matches again. Postures deployed higher in the hierarchy flow down, and when organization and project postures conflict, the lower-level posture controls that project. Scale is bounded by 100 postures per organization, 400 policies per posture, and 1000 deployments per organization.
Exam tip: Only one posture can be deployed to each organization, folder, or project, and when an organization-level posture and a project-level posture define the same policy differently, the lower-level posture controls that project.
Security Health Analytics custom modules are custom detectors that continuously evaluate Cloud Asset Inventory metadata to generate findings for organization-specific misconfigurations. Custom modules run in Security Command Center Premium and Enterprise tiers and apply only to Google Cloud resources, not to Amazon Web Services or Microsoft Azure assets. Built-in detectors cover IAM, compute, network, storage, SQL, Pub/Sub, KMS, and logging, while custom modules complement them where no built-in detector exists.
Detection logic is a CEL expression that tests normalized asset metadata for a violation. Data flows from the Google Cloud resource to Cloud Asset Inventory and then to the evaluation engine. When the expression matches, the engine creates a finding bound to that asset with a category such as DEFAULT_NETWORK, a severity such as MEDIUM, and Detective or Audit mode; when it does not match, no finding is produced. Deployment as code follows authoring the YAML with CEL, targets, severity, and category, importing it to the parent organization, folder, or project with CLI or API, then enabling and validating that compliant resources stay clean and violating resources generate the expected finding. Remediation that makes the expression false allows the finding to move to inactive.
CRITICAL|HIGH exits with non-zero status 1 and prevents the image push to Artifact Registry.sha256: digest before GKE or Cloud Run starts a workload, with a default rule that allows all images until hardened.Automatic scanning in Artifact Registry runs after each new image push when enabled for the repository to continuously monitor stored images for new vulnerabilities, while On-Demand Scanning runs during the build before registry storage to block promotion when severity exceeds policy. A failed On-Demand check stops later Cloud Build steps so the vulnerable image never reaches Artifact Registry, whereas automatic scanning detects vulnerabilities only after the image is already stored.
Binary Authorization checks the deployment request against the policy rules and verifies required attestations from named attestors before the platform starts the workload. Each attestation is a signed statement bound to the immutable sha256 digest affirming that a required check such as vulnerability scanning or build verification already passed, so deployment proceeds only after all required attestations verify successfully and requests must use the digest rather than mutable tags such as 1.0 or latest.
Dry-run mode is a policy-level test mode that allows violating deployments but logs the violations, while break-glass is a per-workload annotation that bypasses an otherwise blocking policy for one emergency deployment. The same image can therefore be denied in a blocking cluster and allowed with a warning in dry-run in another cluster, and break-glass trades assurance for speed so access to it must be restricted and every use reviewed.
Last updated