Cloud Digital Leader Trust and security with Google Cloud Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Use Binary Authorization to ensure only trusted container images are deployed

  Why this is correct

  Binary Authorization is a supply-chain security control that requires all container images to be signed by an approved authority before admission to the cluster. It integrates with Artifact Analysis and your CI/CD pipeline, using attestors to verify signatures and enforce policies like 'only images signed for production' at deployment time. This blocks unverified or tampered images from running, directly closing a key attack vector.

• ✗

  Enable node auto-repair to automatically fix security vulnerabilities in nodes

  Why it's wrong here

  Node auto-repair is a GKE feature that monitors node health and recreates nodes that fail repeated health checks, such as those with disk problems, memory pressure, or unreachable kubelet. It does not patch OS kernels or apply security updates; instead, node auto-upgrade is the mechanism that brings nodes to the current security patched version. Relying on auto-repair for vulnerability fixes is a misconception that leaves known CVEs unpatched.

• ✓

  Enable GKE Sandbox for untrusted workloads to provide an additional layer of isolation

  Why this is correct

  GKE Sandbox uses gVisor, a user-space kernel written in Go, to intercept system calls from untrusted containers and mediate them in a sandbox layer before they reach the host OS kernel. This dramatically reduces the blast radius of a kernel exploit because the container cannot directly access the host's kernel. It is ideal for running code of unknown provenance or multi-tenant workloads, but the syscall interception adds performance overhead, so it should be used selectively.

• ✗

  Expose the cluster control plane via a public endpoint to allow monitoring

  Why it's wrong here

  Making the Kubernetes control plane publicly reachable exposes several attack surfaces, including the API server kubelet authorization and the webhook admission chain, to arbitrary internet traffic. Even with RBAC enabled, anonymous port scan and potential zero-day exploitation become far more likely, and you lose the ability to strictly limit who can attempt to reach the management plane. A private control plane endpoint, coupled with VPC peering or Cloud VPN, allows the same monitoring access while staying off the public internet.

• ✓

  Enable Workload Identity to manage access to Google Cloud APIs

  Why this is correct

  Workload Identity maps a Kubernetes service account (KSA) to an IAM service account (GSA) so that each pod can automatically obtain short-lived OAuth2 tokens to call Google Cloud APIs. This eliminates the need to hardcode service account keys or mount GCP credentials in pods, preventing credential leakage. You grant fine-grained permissions by binding the GSA only to the required roles, and each workload gets its own identity, so a compromised pod cannot steal another workload's credentials.

Go deeper

Related to this question