I85PREP
⌘ K
ACE-Associate study materials
ACE-Associate study resources

Org Policy Blocks a Legitimate Deployment

ACE-Associate · Put your knowledge to work in context.

All case studies

Org Policy Blocks a Legitimate Deployment

A team is deploying a new service to project svc-payments-prod under folder prod-payments. The deployment fails with an org policy violation: constraints/compute.vmExternalIpAccess is enforced to deny all external IPs at the organization node. The service's VMs must reach a third-party payment API over the public internet, and the security team will not allow a NAT gateway for this project. The team asks you to "just remove the org policy" so they can ship. Separately, constraints/iam.allowedPolicyMemberDomains is enforced org-wide to your Workspace domain.

1. The team wants the org policy removed. Why is that the wrong fix, and what is the correct approach?

Read the worked answer

Removing an org-level constraint removes the guardrail for every project in the org, not just this one - a blast-radius change that the security team will (correctly) reject. Org policies are hierarchical: a child can only be more restrictive unless the parent allows an override.

Correct approach depends on intent:

  • If external IPs are genuinely required, the org admin can set the constraint at the org to allow with an exception for svc-payments-prod (or enforce deny at the folder and set an allow-list override at the project, if the constraint supports it). This is a deliberate, reviewed exception scoped to one project.
  • Better: keep the deny and give the VMs egress via a controlled path - e.g., a NAT with a fixed egress IP that the third party allow-lists, or Private Service Connect / egress firewall. The "no NAT" objection is usually about uncontrolled egress; a NAT with a static IP and firewall rules is more auditable than per-VM public IPs.

Document the exception with an owner and expiry.

2. The service needs to call the third-party API and also read a secret. How does the domain-restricted IAM policy affect the service account design?

Read the worked answer

constraints/iam.allowedPolicyMemberDomains restricts IAM policy members to identities in your Workspace domain. Implications:

  • The service account [email protected] is fine - service accounts in your org are allowed principals.
  • You cannot grant roles to [email protected] or any external domain identity while this constraint is enforced. If the third party needs to call into your service, use a service account with a key or Workload Identity Federation, not a human external identity.
  • Store the API credential in Secret Manager, grant roles/secretmanager.secretAccessor to the service account only, and have the VM use the attached service account - never bake the key into the image or metadata.

Verify: attempt the grant and confirm the constraint blocks it, then adjust design rather than weakening the org policy.