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: Build-time: The build process must authenticate to a private package repository using an API token to fetch build dependencies without baking the token into the resulting container image. Runtime: The deployed application in GKE must securely access database credentials at startup while enforcing least privilege and avoiding static credential files. Which configuration strategy should you implement to satisfy both requirements?

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.: ### What this solution is 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. ### How it meets the requirements - **Build-time dependency retrieval:** By defining `availableSecrets` (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. - **Runtime access without static keys:** Using **GKE Workload Identity**, the Kubernetes Service Account used by the application Pod is mapped directly to a runtime Google Cloud Service Account (GSA). The application retrieves database credentials at runtime directly from Secret Manager via the API client library or Secrets Store CSI driver without needing exported service account keys. - **Proper IAM and Access Controls:** The Cloud Build service account is granted `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. ### Key advantages - **Zero credential persistence:** Prevents secrets from being committed to source control or baked into container images. - **Granular IAM bindings:** Limits blast radius by assigning `roles/secretmanager.secretAccessor` at the individual secret level rather than project-wide. - **Elimination of static keys:** Workload Identity eliminates long-lived service account private key management and rotation overhead. - **Full auditability:** All secret access requests from both Cloud Build and GKE workloads are captured in Cloud Audit Data Access logs.

Cloud Build Gke Secret Manager Injection Iam | Professional Cloud DevOps Engineer

Cloud Build Gke Secret Manager Injection Iam

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.

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:

Build-time: The build process must authenticate to a private package repository using an API token to fetch build dependencies without baking the token into the resulting container image.
Runtime: The deployed application in GKE must securely access database credentials at startup while enforcing least privilege and avoiding static credential files.

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 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 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 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.

Professional Cloud DevOps Engineer

Cloud Build Gke Secret Manager Injection Iam

Related questions