Task 4.1: Automating infrastructure and application security.

• AAn On-Demand Scanning step on the local image, with a check that fails on that severity

  Correct

  The On-Demand Scanning API scans an image in the build environment, and a later step can stop the build when vulnerabilities of a chosen severity are found, before the push.

• BAutomatic scanning in Artifact Registry, which scans every image as soon as it is pushed to a repository

  Incorrect

  Automatic scanning runs after the push, so a vulnerable image would already be in the registry when the result arrives.

• CWeb Security Scanner scans against the application after each build is deployed to a staging URL

  Incorrect

  Web Security Scanner probes running web applications for issues such as XSS, not the packages inside a container image.

• DContainer Threat Detection on the GKE clusters that later run the image in production

  Incorrect

  Container Threat Detection looks for runtime attacks in running containers; it does not gate builds.

Artifact Analysis offers two kinds of container scanning. Automatic scanning covers images in Artifact Registry after they are pushed. On-Demand Scanning scans an image on demand, including one that exists only in the build environment, so a Cloud Build step can check the severity of the findings and block the build before the image is pushed.

• AIAM on the production Artifact Registry repository so that only the pipeline's service account can push to it

  Incorrect

  Restricting pushes protects one repository, but the cluster would still accept images from any other registry.

• BA Binary Authorization policy that requires an attestation from the pipeline's attestor

  Correct

  Binary Authorization admits an image only if the required attestors have signed it, so images that skipped the pipeline are rejected at deploy time.

• CCleanup policies in Artifact Registry that delete images older than the latest release

  Incorrect

  Cleanup policies remove images from one registry by age or count; they do not stop a cluster from running images pulled from elsewhere.

• DKubernetes network policies that block Pods built outside the pipeline from receiving traffic

  Incorrect

  Network policies control traffic between Pods; they cannot tell where an image was built and do not stop it from running.

Binary Authorization is a deploy-time control for GKE and Cloud Run. A policy can require attestations, signatures that attestors create when an image passes a stage such as a build, test or scan, and the platform refuses images that lack them.

• AImage User on corp-images for every developer, with no other image permissions granted

  Incorrect

  Public images need no grant at all, so developers could still create VMs from them.

• BVM Manager OS policies that apply the hardening settings to every VM after it boots

  Incorrect

  OS policies configure VMs after creation; they do not control which image a VM is created from.

• CThe trusted image projects organization policy, allowing only corp-images

  Correct

  compute.trustedImageProjects lists the projects whose images may be used to create disks and VMs, so images from anywhere else are refused.

• DShielded VM with Secure Boot turned on for every VM that teams create

  Incorrect

  Secure Boot checks boot component signatures; Google's public images boot under it too, so it does not restrict the image source.

A trusted image policy uses the compute.trustedImageProjects constraint to list the projects whose images may be used in the organization, a folder or a project. Combined with an image pipeline that bakes hardening and patches into custom images and deprecates old ones, it ensures that every new VM starts from an approved image.

• ACloud Asset Inventory exports of all organization policies to Cloud Storage, compared by a script each night

  Incorrect

  Nightly exports and a homemade comparison are slow, cover only the policies, and still leave the team to build the rollout and alerts.

• BOrganization policy dry-run mode for each constraint in the baseline, reviewed weekly in the audit logs

  Incorrect

  Dry run tests the effect of a policy before enforcing it; it neither deploys detectors nor reports changes to enforced controls.

• CA Terraform module for the constraints, applied once by the team from a workstation at the start of each quarter

  Incorrect

  A one-off apply sets the controls but notices nothing when someone changes them afterwards.

• DA security posture, deployed to the organization

  Correct

  A posture groups organization policies and Security Health Analytics detectors, is deployed to the organization, a folder or a project, and reports drift when a deployed control is changed.

Security posture in Security Command Center lets a team define a posture from policy sets of organization policy constraints and Security Health Analytics detectors, often starting from a predefined template, and deploy it to the organization, folders or projects. Security Command Center then monitors the deployed posture and raises findings for drift.

• ADeploy the hotfix with the breakglass annotation in the Pod specification

  Correct

  Breakglass lets a blocked image be deployed in an emergency while recording the event in Cloud Audit Logs for later review.

• BSwitch the cluster's Binary Authorization policy to allow all images until the outage ends

  Incorrect

  Opening the policy for everyone removes the control for every deployment during that window.

• CTurn off Binary Authorization enforcement on the cluster, then turn it back on after the deployment

  Incorrect

  Disabling enforcement removes protection for the whole cluster and is easy to forget to restore.

• DPush the image to a different registry that the policy does not cover

  Incorrect

  Hunting for a loophole bypasses the control without the clear audit signal that breakglass provides.

Binary Authorization breakglass is an emergency escape hatch for GKE: a Pod with the breakglass annotation is admitted even if the policy would block its image, and the deployment is written to Cloud Audit Logs so that security teams can be alerted and review it.

• AA startup script on every VM that runs the package manager's upgrade command at each boot

  Incorrect

  Updates would happen only on reboot, at random times, with no central report of results.

• BA monthly rebuild of every VM from the latest public image, scheduled by Cloud Scheduler

  Incorrect

  Recreating 800 VMs monthly is disruptive and is not a patch management process with per-VM results.

• CVM Manager vulnerability reports for the fleet, with each team patching the listed packages when it has time

  Incorrect

  Vulnerability reports show which VMs have vulnerable packages, but they apply nothing, and leaving fixes to each team's spare time is what keeps patching skipped.

• DA VM Manager patch deployment with a monthly recurring schedule and a four-hour duration

  Correct

  Patch deployments run patch jobs on a schedule with a set duration, across chosen VMs, and report each VM's patch status.

VM Manager Patch applies operating system patches across fleets of VMs. A patch deployment schedules patch jobs, once or recurring, with a duration, an instance filter and the update classes to apply, and the jobs report their status per VM.

• AA GKE Standard cluster, with a written checklist for disabling privileged containers

  Incorrect

  Standard mode leaves node and Pod hardening to the team, the opposite of what is wanted.

• BA GKE Autopilot cluster, in which Google manages the nodes and applies hardening by default

  Correct

  Autopilot applies many hardening recommendations by default, including blocking privileged containers, and Google manages the nodes.

• CA GKE Standard cluster with Container Threat Detection turned on in Security Command Center

  Incorrect

  Threat detection reports attacks at runtime; it does not block privileged containers or harden nodes.

• DCompute Engine VMs with Docker, so that the team controls every container setting

  Incorrect

  Running containers on self-managed VMs puts all hardening on the team.

GKE Autopilot is a mode of operation in which Google manages the nodes and applies a hardened configuration by default, including many of the GKE hardening recommendations. Its default admission policy blocks privileged containers and follows most of the Restricted level of the Kubernetes Pod Security Standards.

• AA daily export of all assets to BigQuery, with a scheduled query that compares firewall rules

  Incorrect

  A daily export misses the requirement to react within moments.

• BFirewall rules logging on every rule, with a log-based metric for allowed connections

  Incorrect

  Firewall rules logging records connections that rules allow or deny, not changes to the rules themselves.

• CAn organization policy custom constraint that rejects any new firewall rule

  Incorrect

  Rejecting all rules stops legitimate changes; the team wants to check and revert non-compliant ones.

• DAn organization-level Cloud Asset Inventory feed for firewall rules, to Pub/Sub

  Correct

  Asset feeds publish changes to the chosen asset types to Pub/Sub as they happen, so a subscriber can evaluate and revert them.

Cloud Asset Inventory feeds watch asset types, names or conditions at the project, folder or organization level and publish each change to a Pub/Sub topic. A function or service subscribed to the topic can check the change and remediate it, which suits near-real-time drift handling.