Professional Cloud DevOps Engineer
Prepare and test your skills
Prepare and test your skills
Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Last updated
Your team is building a secure CI/CD pipeline using Cloud Build that packages containerized applications and deploys them to Google Kubernetes Engine (GKE). The pipeline has two distinct secret management requirements:
Which configuration strategy should you implement to satisfy both requirements?
Store the package token in Secret Manager and pass it to Docker build arguments (--build-arg). For runtime, grant roles/secretmanager.admin to the GKE node pool default Compute Engine service account so all containers can read database credentials.
Store both secrets in Secret Manager. Grant roles/secretmanager.secretAccessor to the Cloud Build service account, fetch the database credentials during the build step, and write them to a configuration file inside the container image for runtime access.
Store both secrets in Secret Manager. Grant roles/secretmanager.secretAccessor on the package repository secret to the Cloud Build service account and expose it via availableSecrets in cloudbuild.yaml. For runtime, configure GKE Workload Identity with a dedicated runtime Google Service Account granted roles/secretmanager.secretAccessor on the database secret.
Store both secrets as Cloud Build standard substitution variables in cloudbuild.yaml. For runtime, generate a service account private key JSON file, store it in a standard Kubernetes Secret, and mount the key inside the Pod to authenticate to Secret Manager.
Store the package token in Secret Manager and pass it to Docker build arguments (--build-arg). For runtime, grant roles/secretmanager.admin to the GKE node pool default Compute Engine service account so all containers can read database credentials.
Store both secrets in Secret Manager. Grant roles/secretmanager.secretAccessor to the Cloud Build service account, fetch the database credentials during the build step, and write them to a configuration file inside the container image for runtime access.
Store both secrets in Secret Manager. Grant roles/secretmanager.secretAccessor on the package repository secret to the Cloud Build service account and expose it via availableSecrets in cloudbuild.yaml. For runtime, configure GKE Workload Identity with a dedicated runtime Google Service Account granted roles/secretmanager.secretAccessor on the database secret.
This approach uses Secret Manager as the centralized secrets store while strictly separating build-time and runtime execution phases and identities, applying the principle of least privilege through granular Identity and Access Management (IAM) role assignments.
StudyCerts
StudyCertsavailableSecrets (with secretManager) in cloudbuild.yaml, the secret is exposed only to designated ephemeral build steps via secretEnv. The API key is consumed dynamically during compilation without persisting in the intermediate image layers or final container image artifact.roles/secretmanager.secretAccessor only for the private repository secret, while the application runtime service account is granted roles/secretmanager.secretAccessor only for the database secret.roles/secretmanager.secretAccessor at the individual secret level rather than project-wide.Store both secrets as Cloud Build standard substitution variables in cloudbuild.yaml. For runtime, generate a service account private key JSON file, store it in a standard Kubernetes Secret, and mount the key inside the Pod to authenticate to Secret Manager.