Google ACE Practice Question: Designing an environment where a CI/CD pipeline…

Answer analysis

Option-by-option breakdown

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

• ✗

  Create a service account key, base64-encode it, and store it as a GitHub Actions secret.

  Why it's wrong here

  Creating a service account key, base64-encoding it, and storing it as a GitHub Actions secret violates the organization's policy because it introduces a long-lived, static credential that never rotates. Anyone with access to the secret can impersonate the service account indefinitely until the key is manually revoked, and the key is effectively a standing backdoor. Workload Identity Federation avoids this by using short-lived, never-stored credentials, so this option both fails the policy and is architecturally insecure.

• ✓

  Use Workload Identity Federation to allow GitHub Actions to impersonate a service account using OIDC tokens.

  Why this is correct

  Workload Identity Federation is the correct approach because it lets GitHub Actions present an OIDC token minted for the GitHub workflow run, which Google Cloud then exchanges for a short-lived STS security token. This token is scoped to a service account via an IAM binding and optional attribute conditions, and it expires after a configurable duration (typically under 1 hour). No service account key is ever created or stored, satisfying the security policy while still granting the pipeline the exact permissions it needs via impersonation.

• ✗

  Grant the GitHub Actions runner VM's default service account the necessary roles.

  Why it's wrong here

  Granting the GitHub Actions runner VM's default service account is invalid because GitHub Actions runners are ephemeral VMs managed by GitHub, not by your GCP project. They have no access to the GCE metadata server and therefore cannot obtain a default service account token from the environment. Even if the runner ran on a GCE VM you controlled, the default service account would be a fixed machine identity, not a per-workflow identity, and it would not satisfy the least-privilege, zero-standing-credential policy.

• ✗

  Use Cloud Build triggers instead of GitHub Actions to avoid key management.

  Why it's wrong here

  Using Cloud Build triggers instead of GitHub Actions sidesteps the problem rather than solving it because Cloud Build is a different CI/CD service with its own authentication model. If the team must continue using GitHub Actions for orchestration, Cloud Build does not eliminate the need for a secure way to authenticate GitHub Actions calls to GCP; it would just move the integration point. Moreover, if GitHub Actions triggers Cloud Build, the GitHub side would still need credentials, so this approach fails to address the original requirement.

Go deeper

Related to this question