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.

• ✗

  Using long-lived API keys stored in Secret Manager instead of environment variables — the keys are the same but stored more securely

  Why it's wrong here

  Long-lived API keys remain a risk even in Secret Manager — they can be extracted and used outside the intended context. The Zero Trust approach requires eliminating long-lived credentials, not just storing them more securely.

• ✓

  Attaching a service account to the Compute Engine VM or GKE workload, allowing the workload to obtain short-lived access tokens from the metadata server automatically — no key files required

  Why this is correct

  This is the correct Zero Trust-aligned approach. A service account is attached to the VM or GKE pod. The workload calls the metadata server (169.254.169.254) to get a short-lived (1-hour) access token automatically. No key file is created, stored, or managed — eliminating the key compromise risk entirely. Workload Identity in GKE extends this to Kubernetes service accounts.

• ✗

  Rotating service account keys every 24 hours to minimize the exposure window

  Why it's wrong here

  Rotating service account keys every 24 hours shrinks the exposure window but does not eliminate the fundamental risk: a static JSON key file still has to be created, stored, and securely distributed to the workload. An attacker who exfiltrates a key file can use it independently of the workload's context until the key is rotated, and even a 24-hour window can be enough for lateral movement or data exfiltration. Zero Trust principles dictate removing long-lived credentials entirely, not merely reducing their lifetime; the keyless metadata-server approach achieves that by granting short-lived tokens directly to the attached service account.

• ✗

  Using OAuth 2.0 user accounts instead of service accounts for all automated workloads

  Why it's wrong here

  OAuth 2.0 user accounts are designed for interactive, user-driven flows (e.g., browser-based authorization) and cannot properly serve unattended automated workloads. A Compute Engine VM or GKE pod cannot complete a consent screen or refresh-token exchange without a human, so relying on user accounts would either fail entirely or require storing a refresh token that still acts like a long-lived secret. In contrast, service accounts provide machine identity and are the correct primitive for workload authentication; they do not depend on human interaction and can authenticate via the metadata server, yielding short-lived access tokens.

Go deeper

Related to this question