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: Database credentials and third-party API keys are injected at container build time, embedding sensitive secrets directly into container image layers. A single over-privileged service account is shared across all environments and CI/CD stages. Audit trails cannot correlate pipeline runs with secret access requests, and secret payload access is not logged. Which end-to-end architecture should the DevOps engineer implement to enforce least privilege, eliminate build-time secret exposure, and ensure comprehensive audit logging?

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.: ### What the Recommended Architecture Is 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. ### How It Meets the Requirements - **Principle of Least Privilege and Isolation**: Segmenting development, staging, and production into distinct **Google Cloud projects** enforces rigid IAM boundaries. Dedicated service accounts ensure build systems cannot access production secret payloads. - **Minimizing Secret Exposure Duration (Runtime Injection)**: By refactoring workloads to query **Secret Manager** directly at runtime using the SDK and **Workload Identity**, sensitive material is never embedded into build artifacts, Docker image layers, or intermediate CI/CD storage. - **Version Pinning and Rollback Safety**: Referencing specific secret **version numbers** instead of the `latest` alias ensures reproducible deployments and prevents breaking changes during automated secret rotation. - **Audit Logging and Pipeline Correlation**: Enabling **Data Access audit logs** (`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. ### Key Advantages - **Eliminates Static Credentials**: Workload Identity allows GKE service accounts to securely authenticate to Google Cloud APIs without storing static private key JSON files. - **Restricts Secret Scope**: Workloads only access the specific secrets they need during runtime execution rather than exposing credentials to CI/CD builders. - **Non-Repudiation**: Data Access audit logs provide forensic-ready visibility into every read event across all environments. - **Blast Radius Reduction**: Compromise of a development build cannot escalate into unauthorized access to production data. ### Why This Is Optimal 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.

Secure Secret Lifecycle Cicd Pipeline Design | Professional Cloud DevOps Engineer

Secure Secret Lifecycle Cicd Pipeline Design

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.

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:

Database credentials and third-party API keys are injected at container build time, embedding sensitive secrets directly into container image layers.
A single over-privileged service account is shared across all environments and CI/CD stages.
Audit trails cannot correlate pipeline runs with secret access requests, and secret payload access is not logged.

Which end-to-end architecture should the DevOps engineer implement to enforce least privilege, eliminate build-time secret exposure, and ensure comprehensive audit logging?

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.

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.

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.

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.

Professional Cloud DevOps Engineer

Secure Secret Lifecycle Cicd Pipeline Design

Related questions