Advanced
Prepare and test your skills
Advanced
Prepare and test your skills
Immutable Container Deployments with Secret Manager
Free sample question, answered and explained below. The Professional Data Engineer practice bank has 1,353 more like it. Try 10 free: instant score, no account.
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?
Explanations
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 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.
What the Option Is
This configuration relies on mutable image tagging, broad project-level IAM privileges, and plaintext environment variables defined in the build configuration manifest.
Why It Doesn't Meet the Requirement
- Immutable Versioning: Using the mutable
latesttag causes previous container versions to be overwritten in Artifact Registry, breaking build reproducibility and rollbacks. - Least Privilege: The Project Editor (
roles/editor) role violates least privilege by granting wide modification permissions across virtually all cloud resources in the project. - Secure Credentials: Passing credentials as plaintext environment variables in build files exposes sensitive API keys in source control history and build logs.
Key Limitations
- Overwriting images creates non-deterministic runtime behaviors across different pipeline runs.
- Broad IAM roles significantly increase the risk of accidental resource deletion or lateral movement upon credential compromise.
- Plaintext secrets stored in build definitions are visible to any user or system with repository access.
This Answer Would Be Correct If
A developer were running a disposable, single-user local prototype where security governance, auditing, and multi-environment reproducibility were not required.
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.
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.
What the Option Is
This approach uses semantic versions for container artifacts, assigns administrative permissions to the build service account, and checks unencrypted configuration files with embedded secrets directly into source control.
Why It Doesn't Meet the Requirement
- Least Privilege: The Artifact Registry Administrator (
roles/artifactregistry.admin) role gives full control over repository settings, permissions, and lifecycle policies, far exceeding the write-only permissions required by a CI/CD build runner. - Secure Credentials: Storing unencrypted configuration files containing credentials in the source code repository violates core security practices and permanently logs secrets into Git history.
Key Limitations
- Administrative privileges permit accidental repository deletion or modification of retention policies.
- Secrets stored in Git repositories remain permanently accessible across commit history unless specialized scrubbing tools are used.
- Compromise of developer or CI/CD read access exposes all third-party API credentials.
This Answer Would Be Correct If
The task required a repository administrator to manage repository settings and policies, and the configuration file contained public non-sensitive parameters.
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 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.
What the Option Is
This strategy attempts to combine proper versioning and least-privilege build IAM roles with embedding hardcoded secrets directly into the container filesystem layers via Dockerfile build commands.
Why It Doesn't Meet the Requirement
- Secure Credentials: Baking plaintext keys into a container image layer persists the secret inside the image metadata. Anyone with read access to the image in Artifact Registry can inspect the layers and extract the secret.
- Credential Lifecycle Management: If the API key needs rotation or revocation, the entire container image must be rebuilt and redeployed, preventing dynamic secret updates.
Key Limitations
- Intermediate container layers retain cached data even if files are deleted in subsequent build steps.
- Distributing container images inadvertently exposes sensitive third-party API credentials across environments.
- It circumvents enterprise secret auditing, access policies, and centralized management tools.
This Answer Would Be Correct If
The injected values represented non-sensitive, static application metadata (such as build timestamps or public application identifiers) rather than confidential API keys.
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 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
latesttags) 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.yamlor 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.
Try 10 interactive questions like this one, free
Answer them yourself and get your score the moment you finish. No account needed.
Full access includes
- 1,353 practice questions across all 5 exam domains
- Every answer explained: why it is right, and why the others are not
- Scout, an AI tutor that answers your follow-up questions
- Readiness tracking by domain, so you know when to book the exam
Related questions
Keep the momentum going with these hand-picked practice scenarios
AdvancedProfessional Data Engineer
Cloud Build Multi-Step Pipeline
CI/CD (Continuous Integration and Continuous Deployment)
AdvancedProfessional Data Engineer
Terraform Cloud Build GitOps Pipeline
CI/CD (Continuous Integration and Continuous Deployment)
AdvancedProfessional Data Engineer
GKE Cost Allocation and Budget Pub/Sub Notifications
Troubleshooting error messages, billing issues, and quotas
AdvancedProfessional Data Engineer
CAP Theorem AP vs CP
Making decisions related to ACID (atomicity, consistency, isolation, and durability) compliance and availability
AdvancedProfessional Data Engineer
BigQuery Capacity and Physical Storage Billing
Mapping business requirements
IntermediateProfessional Cloud Architect
Global External Application Load Balancer with Hierarchical Firewall Policies
Cloud-native networking (e.g., virtual private cloud [VPC], peering, firewalls, load balancers, routing, container networking, shared VPC, and Private Service Connect)
Last updated Validated