Advanced
Prepare and test your skills
Advanced
Prepare and test your skills
Isolating Environments with Service Account Impersonation
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.
An enterprise data engineering team is designing a multi-environment architecture on Google Cloud for their data processing platform, which includes Dataflow pipelines and BigQuery analytical warehouses across Development, Staging, and Production environments.
The system must satisfy the following security and operational requirements:
- Sensitive personally identifiable information (PII) and confidential datasets must reside exclusively in Production and be isolated from lower environments.
- Long-lived downloaded service account keys must be prohibited across all environments to prevent credential leakage.
- CI/CD deployment pipelines and data engineers must adhere to the principle of least privilege, with complete non-repudiation and audit logging of privileged operations.
- Pipeline deployment runners must not have direct read access to production confidential data.
Which combination of environment isolation, service account management, and IAM posture should the team implement?
Explanations
Consolidate Development, Staging, and Production workloads into a single project using dataset-level ACLs, use Secret Manager to store rotated service account JSON keys for CI/CD pipelines, and assign the project-level Editor role to deployment service accounts.
Consolidate Development, Staging, and Production workloads into a single project using dataset-level ACLs, use Secret Manager to store rotated service account JSON keys for CI/CD pipelines, and assign the project-level Editor role to deployment service accounts.
What This Option Proposes
This option groups all environments within a single Google Cloud project, manages permissions at the BigQuery dataset level, stores long-lived service account JSON keys in Secret Manager, and grants deployment automation broad project-level Editor permissions.
Why It Doesn't Meet the Requirements
- Fails environment isolation: A single project provides only one IAM resource boundary. It significantly expands the blast radius and violates multi-environment segmentation standards.
- Violates key security policies: Storing JSON service account keys in Secret Manager still relies on long-lived cryptographic keys rather than eliminating them via organization policies and short-lived credentials.
- Violates least privilege: Granting
roles/editorto deployment pipelines provides broad read/write access to virtually all project resources, including sensitive data. - Increases data exfiltration risk: The CI/CD pipeline possesses full access to read and alter production tables.
Key Limitations
- Broad blast radius: Errors in development scripts can inadvertently delete or corrupt production resources.
- Overprivileged automation: The Editor role bypasses fine-grained resource control.
- Key sprawl risk: Storing JSON keys in Secret Manager still exposes private key material to potential leaks.
This Answer Would Be Correct If
You were designing a simple single-tenant prototype with minimal security compliance requirements and no regulatory boundaries.
Isolate environments via custom VPC subnets in a single project, attach the Compute Engine default service account to Dataflow jobs across all environments, and create authorized views pointing directly to production tables for development testing.
Isolate environments via custom VPC subnets in a single project, attach the Compute Engine default service account to Dataflow jobs across all environments, and create authorized views pointing directly to production tables for development testing.
What This Option Proposes
This option uses network-level segmentation (VPC subnets) inside a single shared project, runs data processing pipelines using the Compute Engine default service account, and allows development pipelines to query production tables directly through authorized views.
Why It Doesn't Meet the Requirements
- Fails data sensitivity isolation: Exposing production datasets directly to development environments—even through authorized views—exposes confidential data to lower environments.
- Over-privileged default identities: The default Compute Engine service account is granted the basic
Editorrole by default, violating least privilege principles. - Inadequate trust boundaries: Network subnets alone do not isolate IAM permissions, project quotas, or audit logs between development and production.
Key Limitations
- Over-privileged runtime identity: Using default service accounts exposes workloads to privilege escalation.
- Direct production data access: Exposes confidential production records to non-production environments.
- Single project failure domain: Administrative mistakes impact both production and development environments simultaneously.
This Answer Would Be Correct If
You had non-confidential data in an architecture where network-level traffic filtering was the sole security requirement.
Separate environments into distinct projects under environment folders, allow developers to download user-managed service account keys for the Development project, and grant development service accounts read access to production BigQuery policy tags for validation.
Separate environments into distinct projects under environment folders, allow developers to download user-managed service account keys for the Development project, and grant development service accounts read access to production BigQuery policy tags for validation.
What This Option Proposes
This option creates separate projects under environment folders, but permits downloading user-managed service account keys for development, while granting development service accounts access to BigQuery policy tags (Fine-Grained Reader) on production tables to validate pipeline logic against production data.
Why It Doesn't Meet the Requirements
- Violates key restriction requirements: Downloading user-managed keys creates an unmanageable credential leakage risk and non-repudiation challenges.
- Exposes confidential data: Granting development identities read access to production policy-tagged columns directly compromises production confidential data.
- Violates least privilege: Development services accounts should operate exclusively on de-identified or synthetic data within the development boundary.
Key Limitations
- Loss of non-repudiation: Downloaded service account keys can be shared or leaked, preventing audit logs from identifying the actual human actor.
- Compliance breach: Accessing sensitive production policy tags from non-production environments breaks regulatory data privacy baselines.
This Answer Would Be Correct If
Development environments required continuous interactive debugging against unmasked production columns and had no restrictions against static key downloads.
Isolate environments using separate project hierarchies under dedicated Development, Non-production, and Production folders; enforce an organization policy to disable service account key creation; require short-lived credential generation via service account impersonation; and restrict CI/CD deployment service accounts to resource management roles without data-read permissions on confidential datasets.
Isolate environments using separate project hierarchies under dedicated Development, Non-production, and Production folders; enforce an organization policy to disable service account key creation; require short-lived credential generation via service account impersonation; and restrict CI/CD deployment service accounts to resource management roles without data-read permissions on confidential datasets.
What This Solution Is
This architecture establishes a multi-environment security model that enforces environment boundaries through Google Cloud's resource hierarchy (dedicated folders and projects), implements least privilege IAM policies, eliminates static credential risks, and secures sensitive production data.
How It Meets the Requirements
- Environment isolation: Placing Development, Non-production (Staging), and Production workloads into dedicated folders and projects creates distinct administrative and trust boundaries, preventing accidental cross-environment data contamination.
- Preventing credential leakage: Applying the
constraints/iam.disableServiceAccountKeyCreationorganization policy constraint completely stops developers and automation tools from generating downloadable JSON keys. - Non-repudiation and least privilege: Requiring engineers and automated tools to obtain short-lived access tokens via service account impersonation (
roles/iam.serviceAccountTokenCreator) ensures that Cloud Audit Logs record the identity of the user or principal requesting the token (serviceAccountDelegationInfo). - Pipeline security: Granting CI/CD service accounts permissions only to deploy infrastructure and code (e.g., Dataflow job submission and template deployment) without assigning data reading roles (such as
roles/bigquery.dataViewer) prevents pipelines from serving as exfiltration vectors.
Key Advantages
- Minimizes the blast radius: Compromises in development or staging cannot reach production data assets.
- Enforces non-repudiation: Eliminates anonymous shared-key usage by logging all impersonations and short-lived token requests.
- Aligns with zero trust: Data processing systems only possess the exact IAM roles required for their operational scope.
- Automates compliance: Folder-level policies automatically govern newly provisioned projects within each environment branch.
Why This Is Optimal
Leveraging Google Cloud's native resource hierarchy and organization policy constraints provides systematic policy inheritance and prevents data leakage across environments without relying on error-prone manual safeguards.
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
Cloud Build Binary Authorization VPC Service Controls
Multi-environment use cases (development vs. production)
AdvancedProfessional Data Engineer
VPC Service Controls Analytics Hub Ingress Egress
Publishing datasets
AdvancedProfessional Data Engineer
CSEK vs CMEK vs Cloud EKM
Data encryption
AdvancedProfessional Data Engineer
BigQuery Partitioning and Clustering
Planning for storage costs and performance
AdvancedProfessional Cloud Security Engineer
Secret Manager Automated Rotation via Pub/Sub
Securing secrets with Secret Manager.
Last updated Validated