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
An enterprise organization deploys containerized microservices to Google Kubernetes Engine (GKE) clusters across development, staging, and production environments using Cloud Build and Cloud Deploy. A recent security assessment identified critical vulnerabilities in their pipeline secret management:
Which end-to-end architecture should the DevOps engineer implement to enforce least privilege, eliminate build-time secret exposure, and ensure comprehensive audit logging?
Grant a shared deployment service account the Secret Manager Secret Accessor role, synchronize secrets into unencrypted Kubernetes Secrets using the 'latest' version alias during Cloud Deploy releases, and monitor access through standard Admin Activity audit logs.
Export user-managed service account keys for each target environment, commit the key files to a protected repository branch, and configure Cloud Build to inject secrets as environment variables into GKE deployment manifests.
Decrypt secrets during the Cloud Build execution using Cloud KMS symmetric keys, bake the decrypted credentials into configuration files in the container image, and export Cloud Build build logs to BigQuery for periodic querying.
Isolate environments into dedicated Google Cloud projects with environment-specific service accounts, retrieve secrets at runtime via Workload Identity using the Secret Manager client library pinned to version numbers, enable Secret Manager Data Access audit logs at the organization or folder level, and attach an X-Goog-Request-Reason header containing the pipeline run ID to API requests.
Grant a shared deployment service account the Secret Manager Secret Accessor role, synchronize secrets into unencrypted Kubernetes Secrets using the 'latest' version alias during Cloud Deploy releases, and monitor access through standard Admin Activity audit logs.
Export user-managed service account keys for each target environment, commit the key files to a protected repository branch, and configure Cloud Build to inject secrets as environment variables into GKE deployment manifests.
Decrypt secrets during the Cloud Build execution using Cloud KMS symmetric keys, bake the decrypted credentials into configuration files in the container image, and export Cloud Build build logs to BigQuery for periodic querying.
Isolate environments into dedicated Google Cloud projects with environment-specific service accounts, retrieve secrets at runtime via Workload Identity using the Secret Manager client library pinned to version numbers, enable Secret Manager Data Access audit logs at the organization or folder level, and attach an X-Goog-Request-Reason header containing the pipeline run ID to API requests.
This architecture establishes a secure-by-design secret lifecycle by combining project-level environmental segmentation, runtime secret injection, metadata-based identity federation, and end-to-end audit log enrichment across Google Cloud services.
StudyCerts
StudyCertslatest alias ensures reproducible deployments and prevents breaking changes during automated secret rotation.AccessSecretVersion) captures all secret read operations, while passing the pipeline execution ID via the X-Goog-Request-Reason HTTP header enriches logs for direct correlation between CI/CD pipeline runs and infrastructure operations.Runtime injection directly from Secret Manager via Workload Identity removes secrets completely from CI/CD pipeline definitions and container registries, while organization-level Data Access logs and custom request reason headers deliver complete, unbroken auditability.