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?

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.disableServiceAccountKeyCreation organization 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.

StudyCerts

Professional Cloud Data Engineer

professional-cloud-data-engineer

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Multi Environment Security Posture Access Controls

Section: Multi-environment use cases (development vs. production)

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?

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.

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.

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.

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.

Professional Cloud Data Engineer

professional-cloud-data-engineer

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Multi Environment Security Posture Access Controls

Section: Multi-environment use cases (development vs. production)

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

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.disableServiceAccountKeyCreation organization 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.

View source documentation

Professional Cloud Data Engineer

Multi Environment Security Posture Access Controls

Professional Cloud Data Engineer

Multi Environment Security Posture Access Controls

What This Solution Is

How It Meets the Requirements

Key Advantages

Why This Is Optimal

Related questions