A data engineering team is designing an automated CI/CD pipeline in Google Cloud to build and deploy custom containerized data processing applications. The solution must adhere to enterprise security and deployment standards: Container images must be stored immutably and uniquely identifiable in Artifact Registry to ensure reproducible deployments. The build service account used in the CI/CD pipeline must adhere strictly to the principle of least privilege. Sensitive third-party API keys needed by the workload must be securely retrieved without hardcoding or exposing them in plaintext within build configuration files or container image layers. Which combination of actions should the team implement?

Tag container images using specific Git commit SHAs and push them to Artifact Registry, grant the build service account the Artifact Registry Writer role, and store API keys in Secret Manager or encrypt them with Cloud KMS to be retrieved and decrypted programmatically at runtime.: ### What the Solution Is This architecture establishes a secure, repeatable, and least-privilege **CI/CD pipeline** for containerized data pipelines by integrating **Artifact Registry**, **Cloud IAM**, and dedicated secret management systems such as **Secret Manager** or **Cloud KMS**. ### How It Meets the Requirements - **Immutable and Unique Versioning:** Tagging container images with **Git commit SHAs** or specific release digests prevents unintentional overrides (unlike mutable `latest` tags) and ensures full auditability and traceability back to source code commits. - **Least-Privilege IAM Permissions:** Granting the build service account the **Artifact Registry Writer** (`roles/artifactregistry.writer`) role provides exact permissions to write and upload build artifacts without giving broader project-level administrative rights. - **Secure Credential Handling:** Storing API keys in **Secret Manager** or encrypting them using **Cloud KMS** eliminates plaintext secrets in `cloudbuild.yaml` or application images, enabling the application to securely fetch and decrypt secrets at runtime. ### Key Advantages - **Reproducibility:** Version-pinned container tags ensure identical artifacts across testing, staging, and production environments. - **Access Control:** Separation of build duties limits the blast radius if CI/CD credentials or service accounts are compromised. - **Zero Secret Sprawl:** Sensitive API keys are never cached in intermediate container image layers or Git repositories. - **Auditing and Rotation:** Secret versions and KMS keys can be rotated independently without requiring container image rebuilds. ### Why This Is Optimal Decoupling secrets from container images while applying targeted IAM roles ensures adherence to defense-in-depth security principles. Fetching credentials programmatically at startup guarantees that sensitive tokens are kept strictly in memory during execution.

Secure Cicd Artifact Registry Credential Management | professional-cloud-data-engineer

Secure Cicd Artifact Registry Credential Management

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.

A data engineering team is designing an automated CI/CD pipeline in Google Cloud to build and deploy custom containerized data processing applications. The solution must adhere to enterprise security and deployment standards:

Container images must be stored immutably and uniquely identifiable in Artifact Registry to ensure reproducible deployments.
The build service account used in the CI/CD pipeline must adhere strictly to the principle of least privilege.
Sensitive third-party API keys needed by the workload must be securely retrieved without hardcoding or exposing them in plaintext within build configuration files or container image layers.

Which combination of actions should the team implement?

Tag container images using specific Git commit SHAs and push them to Artifact Registry, grant the build service account the Artifact Registry Writer role, and bake the plaintext API keys directly into a Dockerfile layer during the container build step.

Tag container images using the latest tag and push them to Artifact Registry, grant the build service account the Project Editor role, and pass the API keys as plaintext environment variables in the build configuration file.

Tag container images using specific Git commit SHAs and push them to Artifact Registry, grant the build service account the Artifact Registry Writer role, and store API keys in Secret Manager or encrypt them with Cloud KMS to be retrieved and decrypted programmatically at runtime.

Tag container images using semantic version tags and push them to Artifact Registry, grant the build service account the Artifact Registry Administrator role, and commit the third-party API keys to the source repository inside an unencrypted properties file.

Professional Cloud Data Engineer

Secure Cicd Artifact Registry Credential Management

Related questions