Your enterprise uses automated CI/CD pipelines that dynamically provision ephemeral Google Cloud projects to run integration tests and validate containerized workloads. These temporary environments create Compute Engine instances, Cloud Storage buckets, and analytical clusters before being destroyed. Your security team mandates the following governance requirements for all ephemeral environments: Prevent the generation of persistent service account key files across all short-lived resources. Mitigate data exfiltration risks by enforcing context-based perimeter security around Google Cloud APIs and storage resources. Allow developers to request audited, just-in-time elevated permissions for troubleshooting failed test runs without distributing persistent administrative privileges. Which combination of Google Cloud security controls and configuration management policies should you implement?

Enforce the iam.disableServiceAccountKeyCreation organization policy constraint on the ephemeral folder, include new ephemeral projects in a VPC Service Controls perimeter, and use Privileged Access Manager (PAM) for just-in-time elevated developer access.: ### What this solution is This architecture combines **Organization Policies**, **VPC Service Controls (VPC SC)**, and **Privileged Access Manager (PAM)** to establish an automated, zero-trust security baseline for short-lived cloud environments. ### How it meets the requirements - **Preventing persistent credentials**: Applying the `iam.disableServiceAccountKeyCreation` constraint at the folder level ensures that any dynamically provisioned project inside that folder automatically inherits the restriction, blocking the generation of long-lived service account keys. - **Mitigating data exfiltration**: Adding the ephemeral projects into a **VPC Service Controls service perimeter** prevents Google Cloud APIs (such as Cloud Storage, BigQuery, and Compute Engine) from communicating outside defined network and project perimeters, preventing egress leaks to unauthorized public internet destinations. - **Audited temporary access**: **Privileged Access Manager (PAM)** enables developers to initiate time-bound, just-in-time privilege elevations with mandatory business justifications and approval workflows, eliminating the need for permanent standing administrative roles. ### Key advantages and capabilities - **Inherited policy enforcement**: Enforcing policies at the folder node guarantees that all newly provisioned ephemeral projects inherit identical compliance rules without manual intervention. - **Defense-in-depth**: Pairs resource-centric boundary enforcement (VPC SC) with identity-centric access management (PAM). - **Comprehensive audit logging**: PAM provides clear audit trails detailing who requested access, the approval timestamp, and the exact session duration. - **Minimization of lateral movement**: Disabling key creation prevents credential exfiltration if a test workload is compromised. ### Why this is optimal This approach aligns with Google Cloud security best practices by automating guardrails via the resource hierarchy and enforcing strict perimeter boundaries, ensuring temporary environments maintain the same security rigor as production systems.

Ephemeral Environments Security Governance Policies | Professional Cloud DevOps Engineer

Ephemeral Environments Security Governance Policies

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.

Your enterprise uses automated CI/CD pipelines that dynamically provision ephemeral Google Cloud projects to run integration tests and validate containerized workloads. These temporary environments create Compute Engine instances, Cloud Storage buckets, and analytical clusters before being destroyed.

Your security team mandates the following governance requirements for all ephemeral environments:

Prevent the generation of persistent service account key files across all short-lived resources.
Mitigate data exfiltration risks by enforcing context-based perimeter security around Google Cloud APIs and storage resources.
Allow developers to request audited, just-in-time elevated permissions for troubleshooting failed test runs without distributing persistent administrative privileges.

Which combination of Google Cloud security controls and configuration management policies should you implement?

Grant developers the roles/resourcemanager.organizationAdmin role permanently, deploy Cloud NAT gateways in each ephemeral project for network isolation, and store generated service account keys in Secret Manager.

Assign service accounts domain-wide delegation for ephemeral provisioning, export Cloud Audit Logs to BigQuery for hourly policy compliance scans, and block key creation using Compute Engine instance metadata.

Enforce the iam.disableServiceAccountKeyCreation organization policy constraint on the ephemeral folder, include new ephemeral projects in a VPC Service Controls perimeter, and use Privileged Access Manager (PAM) for just-in-time elevated developer access.

Configure OS Login with 2-step verification at the organization node, configure Cloud Identity Access Bindings with overlapping groups for temporary access, and rely on standard VPC firewall rules to prevent data exfiltration.

Professional Cloud DevOps Engineer

Ephemeral Environments Security Governance Policies

Related questions