Your enterprise organization uses Google Cloud Deploy to manage progressive delivery across three environments: development, staging, and production. To satisfy strict regulatory compliance and risk-mitigation policies, the organization must enforce deployment blackout windows during end-of-quarter financial auditing periods. During these scheduled windows: Rollout promotions must not be approved or created on the production target. Deployments, testing, and rollouts targeting development and staging must continue uninterrupted. The restriction must be centrally managed and declaratively enforced at the deployment pipeline layer. Which solution should you implement to enforce these criteria?

Create a Cloud Deploy `DeployPolicy` configuration specifying a `selectors` stanza matching the production `target.id`, configure a `rolloutRestriction` rule restricting `APPROVE` and `CREATE` actions across the scheduled time windows, and apply it using `gcloud deploy apply`.: ### What Cloud Deploy Policies Are **Cloud Deploy Policies** (`DeployPolicy`) provide declarative governance and operational guardrails for delivery pipelines and deployment targets in Google Cloud Deploy. They allow DevOps administrators to enforce compliance rules—such as change freeze windows, rollout restrictions, and approval policies—without modifying core pipeline architectures or underlying infrastructure. ### How it meets the requirements * **Target-specific scoping:** By setting the `selectors` block to target the specific `target.id` (or target labels) representing the `production` environment, the policy applies strictly to production while leaving `development` and `staging` unaffected. * **Restricting specific lifecycle actions:** The `rolloutRestriction` rule supports granular action restrictions, specifically preventing `APPROVE` (approving rollout promotions) and `CREATE` (creating new rollouts) during designated windows. * **Declarative scheduling:** The policy allows operators to define `oneTimeWindows` or recurring `weeklyWindows` to cleanly define blackout and audit periods. * **Native deployment:** The policy is codified in YAML and applied natively to the project and region using `gcloud deploy apply --file=FILENAME`. ### Key advantages and capabilities * **Granular action controls:** Fine-grained restriction options include `APPROVE`, `CREATE`, `ADVANCE`, `ROLLBACK`, `RETRY_JOB`, and `CANCEL`. * **Selector flexibility:** Targets and pipelines can be selected explicitly by `id` or dynamically using resource `labels`. * **Centralized compliance:** Decouples change freeze management from application source code and pipeline templates. * **Clear auditability:** Changes to policies can be versioned in source control and audited through Cloud Audit Logs. ### Why this is optimal Using native `DeployPolicy` resources is the Google-recommended approach for enforcing temporal restrictions and risk gates on Cloud Deploy targets. It requires zero custom webhook development, prevents human error during change freezes, and natively intercepts API actions at the control plane level.

Cloud Deploy Policy Rollout Restriction Production Window | Professional Cloud DevOps Engineer

Cloud Deploy Policy Rollout Restriction Production Window

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 organization uses Google Cloud Deploy to manage progressive delivery across three environments: development, staging, and production.

To satisfy strict regulatory compliance and risk-mitigation policies, the organization must enforce deployment blackout windows during end-of-quarter financial auditing periods. During these scheduled windows:

Rollout promotions must not be approved or created on the production target.
Deployments, testing, and rollouts targeting development and staging must continue uninterrupted.
The restriction must be centrally managed and declaratively enforced at the deployment pipeline layer.

Which solution should you implement to enforce these criteria?

Create a Cloud Deploy DeployPolicy configuration specifying a selectors stanza matching the production target.id, configure a rolloutRestriction rule restricting APPROVE and CREATE actions across the scheduled time windows, and apply it using gcloud deploy apply.

Create an IAM Deny policy condition on roles/clouddeploy.operator that denies clouddeploy.rollouts.approve permissions using GKE cluster resource tags and temporal attributes.

Configure a Cloud Build trigger approval gate linked to a Cloud Scheduler job that toggles Cloud Deploy pipeline pauses via Pub/Sub topics during the audit periods.

Modify the Cloud Deploy DeliveryPipeline definition YAML to add a requireApproval: true parameter configured with a CEL time-window expression directly inside the production stage.

Professional Cloud DevOps Engineer

Cloud Deploy Policy Rollout Restriction Production Window

Related questions