Advanced
Prepare and test your skills
Advanced
Prepare and test your skills
Secure Dataflow Promotion with Binary Authorization
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.
Your enterprise data engineering team is designing a CI/CD pipeline in Google Cloud to automate the promotion of Dataflow batch processing pipelines and Cloud Composer DAGs from a development project to a production project.
The deployment pipeline must satisfy several security and governance constraints:
- Container images for custom Dataflow flex templates must be validated for vulnerabilities prior to deployment.
- Production cloud services must be isolated within a VPC Service Controls perimeter.
- CI/CD execution identities must adhere to the principle of least privilege without granting internal Google-managed service agent roles to deployment service accounts.
Which CI/CD and Infrastructure as Code (IaC) promotion strategy should you implement?
Explanations
Execute continuous deployment scripts using the Compute Engine default service account, deploy Dataflow worker templates directly from public container registries, and apply OS config policies to inspect images after deployment.
Execute continuous deployment scripts using the Compute Engine default service account, deploy Dataflow worker templates directly from public container registries, and apply OS config policies to inspect images after deployment.
What This Option Proposes
This option relies on the default Compute Engine service account to deploy Dataflow templates sourced from public base image registries, relying on post-deployment OS configuration policies to scan for compliance issues.
Why It Doesn't Meet the Requirement
- Overprivileged Default Identities: The default Compute Engine service account traditionally carries broad Editor permissions, violating least-privilege principles.
- Public Image Risk: Pulling container templates directly from public registries introduces supply chain risks and bypasses pre-deployment vulnerability verification.
- Reactive Rather than Preventive Gates: Applying OS policies post-deployment does not block non-compliant code from entering production; security gates must be preventative in the CI/CD promotion phase.
Key Characteristics and Limitations
- Public repositories lack centralized vulnerability management and attestation tracking for production promotion.
- Default service accounts represent an anti-pattern for secure CI/CD promotion pipelines.
- OS policies inspect operating system state on running VMs but do not provide CI/CD promotion validation for containerized Dataflow jobs.
This Answer Would Be Correct If
The workload consisted purely of unmanaged standalone Compute Engine virtual machines where runtime OS drift remediation was the primary operational requirement.
Configure Cloud Build triggers in the CI/CD pipeline using a dedicated user-managed service account. Store custom container images in Artifact Registry with automatic vulnerability scanning enabled via Container Analysis, enforce deployment gates using Binary Authorization before pushing to production, and include the Container Security API and data services within the VPC Service Controls perimeter.
Configure Cloud Build triggers in the CI/CD pipeline using a dedicated user-managed service account. Store custom container images in Artifact Registry with automatic vulnerability scanning enabled via Container Analysis, enforce deployment gates using Binary Authorization before pushing to production, and include the Container Security API and data services within the VPC Service Controls perimeter.
What the Recommended Architecture Is
This architecture establishes an automated, secure CI/CD deployment and promotion pipeline using Cloud Build, Artifact Registry, Container Analysis, Binary Authorization, and VPC Service Controls. It manages the transition of containerized Dataflow jobs and Cloud Composer orchestration assets from development into a protected production boundary while strictly enforcing policy-as-code and vulnerability mitigation.
How It Meets the Security and Promotion Requirements
- Automated Vulnerability Scanning: Custom container images pushed to Artifact Registry are automatically evaluated by Container Analysis / Container Scanning Service Agent for known CVEs. Binary Authorization inspects these attestations before orchestrating image deployment into production.
- Network Boundary Protection: The production environment is wrapped inside a VPC Service Controls perimeter that includes services such as the Container Security API (
containersecurity.googleapis.com), Dataflow, and Cloud Storage, mitigating unauthorized external data exfiltration. - Least-Privilege Identity Management: The pipeline executes using a dedicated, user-managed Cloud Build service account tailored with granular IAM roles rather than abusing internal Google-managed service agent roles.
Key Advantages and Capabilities
- Automated Governance Gates: Enforces cryptographic provenance and security attestation checks automatically in the promotion path.
- Repeatable Infrastructure Promotion: Works seamlessly with Infrastructure as Code (IaC) tools such as Terraform across multi-project environments.
- Perimeter Integration: Fully compatible with VPC Service Controls perimeters across all supported analytics and container security APIs.
- Separation of Duties: Isolate development experimentation from production releases through automated gate enforcement.
Why This Is Optimal
This approach provides an end-to-end automated promotion pipeline that enforces automated vulnerability validation, strict network boundaries, and granular IAM permissions without creating administrative bypasses or misusing internal service agents.
Assign the predefined Cloud Build Service Agent role (roles/cloudbuild.serviceAgent) directly to a custom build worker service account, run security scans inside build scripts using local Docker CLI daemon scanners, and deploy directly into the production VPC perimeter without enabling Container Analysis.
Assign the predefined Cloud Build Service Agent role (roles/cloudbuild.serviceAgent) directly to a custom build worker service account, run security scans inside build scripts using local Docker CLI daemon scanners, and deploy directly into the production VPC perimeter without enabling Container Analysis.
What This Option Proposes
This option attempts to run the promotion pipeline by binding the internal Cloud Build Service Agent (roles/cloudbuild.serviceAgent) role to a user-managed service account and using local image scanning scripts within the container runtime rather than native cloud security services.
Why It Doesn't Meet the Requirement
- Misuse of Service Agent Roles: Google Cloud explicitly warns against granting service agent roles to any user-created service accounts or external principals. Service agent roles are strictly designed for internal Google-managed service identities.
- Unverified Scanning: Local shell-based Docker scanning scripts in a build pipeline do not generate structured attestations in Container Analysis, making automated attestation policy enforcement impossible.
- Governance Gaps: Manual image analysis scripts fail to provide enterprise auditability across multi-project promotions.
Key Characteristics and Limitations
- Service agent roles contain internal permissions that can cause unintended privilege escalation or unexpected authentication behaviors.
- Bypassing Container Analysis prevents integration with automated policy admission controllers like Binary Authorization.
- High operational maintenance required to support bespoke command-line vulnerability scanners across build agents.
This Answer Would Be Correct If
This pattern would only be considered in isolated on-premises sandbox environments lacking access to Google Cloud managed services, where managed IAM and Container Analysis APIs are unavailable.
Grant the Dataflow Service Agent role (roles/dataflow.serviceAgent) and Composer API Service Agent role (roles/composer.serviceAgent) to the CI/CD service account so it can deploy resources across projects, while skipping VPC Service Controls perimeters.
Grant the Dataflow Service Agent role (roles/dataflow.serviceAgent) and Composer API Service Agent role (roles/composer.serviceAgent) to the CI/CD service account so it can deploy resources across projects, while skipping VPC Service Controls perimeters.
What This Option Proposes
This option assigns broad service agent roles (Dataflow Service Agent and Composer API Service Agent) to the CI/CD pipeline identity to provide it cross-project provisioning access, avoiding network boundaries like VPC Service Controls.
Why It Doesn't Meet the Requirement
- Violation of Service Agent Guidelines: Assigning internal service agent roles such as
roles/dataflow.serviceAgentorroles/composer.serviceAgentto user-managed deployment identities directly violates Google Cloud IAM security best practices. - Failure to Secure Production: Omitting VPC Service Controls perimeters leaves the production environment susceptible to data exfiltration and external network threats.
- No Compliance Verification: Does not provide vulnerability scanning or automated deployment promotion gates.
Key Characteristics and Limitations
- Service agent roles grant internal platform mechanics meant solely for Google-managed system agents.
- Lacks network perimeter defense mechanisms to enforce multi-environment boundary isolation.
- Grants excessive cross-project execution privileges to build workers.
This Answer Would Be Correct If
You were diagnosing internal Google service agent delegation configurations rather than building a customer-managed continuous integration and deployment pipeline across development and production.
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
BigQuery Dynamic Data Masking with Policy Tags
Multi-environment use cases (development vs. production)
AdvancedProfessional Data Engineer
Google Cloud Environment Isolation and Service Account Impersonation
Multi-environment use cases (development vs. production)
AdvancedProfessional Data Engineer
BigQuery ML Remote Models with Vertex AI
AI data enrichment
AdvancedProfessional Data Engineer
Dataproc Autoscaling and Quota Monitoring
Monitoring planned usage
AdvancedProfessional Data Engineer
Ephemeral Dataproc with Cloud Storage and Dataproc Metastore
Deciding between persistent or job-based data clusters (e.g., Dataproc)
AdvancedProfessional Cloud Security Engineer
IAM Conditions CEL Time-Based Access
Managing IAM and access control list (ACL) permissions.
Last updated Validated