Organization policies in GCP - Step-by-Step Execution

Process Flow - Organization policies

Define Organization Policy

↓

Attach Policy to Resource

↓

Policy Evaluated on Requests

↓

Allow or Deny Action Based on Policy

↓

Enforce Compliance Across Resources

Organization policies are rules set at the organization level that control what actions are allowed or denied on resources. They are attached to resources and evaluated on each request to enforce compliance.

Execution Sample

GCP

resource "google_org_policy_policy" "restrict_compute_regions" {
  org_id = "123456789"
  constraint = "constraints/compute.allowedRegions"
  list_policy {
    allowed_values = ["us-central1", "us-east1"]
  }
}

This code creates an organization policy that restricts Compute Engine resources to only use specified regions.

Process Table

Step	Action	Resource	Policy Evaluated	Result
1	Define policy restrict_compute_regions	Organization 123456789	constraints/compute.allowedRegions	Policy created with allowed regions us-central1, us-east1
2	Attach policy to organization	Organization 123456789	constraints/compute.allowedRegions	Policy active on organization and all child resources
3	Request to create VM in us-central1	Project under org 123456789	constraints/compute.allowedRegions	Allowed (region in allowed list)
4	Request to create VM in europe-west1	Project under org 123456789	constraints/compute.allowedRegions	Denied (region not in allowed list)
5	Request to create VM in us-east1	Project under org 123456789	constraints/compute.allowedRegions	Allowed (region in allowed list)
6	Request to create VM in asia-east1	Project under org 123456789	constraints/compute.allowedRegions	Denied (region not in allowed list)

💡 Requests outside allowed regions are denied, enforcing the organization policy.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
Policy allowed_regions	empty	[us-central1, us-east1]	[us-central1, us-east1]	[us-central1, us-east1]	[us-central1, us-east1]	[us-central1, us-east1]
Request region	none	none	none	us-central1	europe-west1	asia-east1
Request result	none	none	none	Allowed	Denied	Denied

Key Moments - 2 Insights

Why is a VM creation request denied even though the project is under the organization?

Because the requested region is not in the allowed regions list defined by the organization policy, as shown in execution_table rows 4 and 6.

Does the organization policy apply only to the organization or also to projects under it?

The policy applies to the organization and all its child resources, including projects, as shown in execution_table row 2.

Visual Quiz - 3 Questions

Look at the execution_table, what is the result of a VM creation request in us-east1?

A Denied

B Allowed

C Pending

D Error

💡 Hint

Check execution_table row 5 where the request region is us-east1.

At which step does the policy become active on the organization and its projects?

A Step 2

B Step 3

C Step 1

D Step 4

💡 Hint

Look at execution_table row 2 describing policy attachment.

If the allowed regions list included 'europe-west1', what would be the result at step 4?

A Error

B Denied

C Allowed

D Pending

💡 Hint

Refer to variable_tracker for request region and result changes.

Concept Snapshot

Organization policies in GCP control resource behavior across the organization.
They are defined with constraints and attached to organization or folders.
Policies are evaluated on each request to allow or deny actions.
Example: Restrict Compute Engine regions to a whitelist.
Policies enforce compliance centrally and cascade down resource hierarchy.

Full Transcript

Organization policies in Google Cloud let you set rules that control what actions can happen on resources within your organization. You define a policy with a constraint, like allowed regions for Compute Engine. Then you attach this policy to your organization or folders. When someone tries to create or modify a resource, Google Cloud checks the policy. If the action matches the allowed rules, it proceeds; if not, it is denied. For example, if you restrict Compute Engine regions to us-central1 and us-east1, any VM creation request outside these regions will be denied. This helps keep your cloud environment compliant with your company rules.

Practice

1. What is the main purpose of an Organization Policy in Google Cloud?

easy

A. To set rules that apply to all projects in a company

B. To create virtual machines automatically

C. To monitor network traffic in real-time

D. To manage billing accounts for users

Solution

1. Step 1: Understand the role of organization policies

   Organization policies define rules that apply across all projects and resources in a company to keep them safe and compliant.

2. Step 2: Compare options with the purpose

   Only To set rules that apply to all projects in a company describes setting rules across all projects, which matches the purpose of organization policies.

3. Final Answer:

   To set rules that apply to all projects in a company -> Option A

4. Quick Check:

   Organization policies control rules = A [OK]

Hint: Organization policies set company-wide rules, not individual tasks [OK]

Common Mistakes:

• Confusing organization policies with billing or monitoring
• Thinking policies create resources automatically
• Assuming policies manage user accounts directly

2. Which of the following is the correct way to specify a constraint in an organization policy YAML file?

easy

A. constraint -> gcp.resourceLocations

B. constraint = gcp.resourceLocations

C. constraint: gcp.resourceLocations

D. constraint() gcp.resourceLocations

Solution

1. Step 1: Recall YAML syntax for key-value pairs

   YAML uses colon (:) to assign values to keys, like key: value.

2. Step 2: Identify correct constraint syntax

   constraint: gcp.resourceLocations uses constraint: gcp.resourceLocations, which is valid YAML syntax for specifying a constraint.

3. Final Answer:

   constraint: gcp.resourceLocations -> Option C

4. Quick Check:

   YAML key-value uses colon = C [OK]

Hint: YAML uses colon for key-value pairs, not equals or arrows [OK]

Common Mistakes:

• Using equals sign (=) instead of colon (:)
• Using arrows (->) or parentheses incorrectly
• Confusing YAML with programming language syntax

3. Given this organization policy snippet:

constraint: constraints/compute.disableSerialPortAccess
listPolicy:
  deniedValues:
  - "true"

What is the effect of this policy?

medium

A. It enables serial port access on all projects

B. It allows serial port access on compute instances

C. It disables all compute instances

D. It denies serial port access on compute instances

Solution

1. Step 1: Understand the constraint meaning

   The constraint constraints/compute.disableSerialPortAccess controls serial port access on compute instances ("true" disables access, "false" allows it).

2. Step 2: Interpret the deniedValues list

   Setting deniedValues: ["true"] denies the value "true", which disables serial port access on compute instances.

3. Final Answer:

   It denies serial port access on compute instances -> Option D

4. Quick Check:

   deny "true" disables access = A [OK]

Hint: Denying 'true' disables serial port access [OK]

Common Mistakes:

• Thinking deniedValues means allowed values
• Confusing serial port access with instance shutdown
• Assuming the policy enables the feature

4. You wrote this organization policy YAML:

constraint: constraints/compute.disableSerialPortAccess
listPolicy:
  deniedValues:
    - true

But it does not work as expected. What is the likely error?

medium

A. The constraint name is incorrect

B. The denied value should be a string "true", not boolean true

C. The listPolicy block is missing required fields

D. YAML does not support lists under deniedValues

Solution

1. Step 1: Check the deniedValues data type

   Organization policies expect deniedValues as strings, so "true" must be quoted.

2. Step 2: Identify the error cause

   Using unquoted true is boolean in YAML, causing the policy to fail or behave unexpectedly.

3. Final Answer:

   The denied value should be a string "true", not boolean true -> Option B

4. Quick Check:

   Denied values must be strings in YAML [OK]

Hint: Always quote boolean values as strings in organization policies [OK]

Common Mistakes:

• Not quoting boolean values in YAML
• Assuming constraint names are wrong without checking
• Thinking lists are not allowed under deniedValues

5. Your company wants to restrict all projects to only create resources in these regions: us-central1 and europe-west1. Which organization policy configuration achieves this?

hard

A. constraint: constraints/gcp.resourceLocations
listPolicy:
allowedValues:
- "us-central1"
- "europe-west1"

B. constraint: constraints/gcp.resourceLocations
listPolicy:
deniedValues:
- "notin:us-central1"
- "notin:europe-west1"

C. constraint: constraints/gcp.resourceLocations
listPolicy:
deniedValues:
- "us-central1"
- "europe-west1"

D. constraint: constraints/gcp.resourceLocations
listPolicy:
allowedValues:
- "in:us-central1"
- "in:europe-west1"

Solution

1. Step 1: Understand the constraint for resource locations

   The constraints/gcp.resourceLocations controls allowed regions for resource creation.

2. Step 2: Identify correct allowedValues format

   Allowed values should list region names as strings without prefixes like "in:"; constraint: constraints/gcp.resourceLocations listPolicy: allowedValues: - "us-central1" - "europe-west1" correctly lists "us-central1" and "europe-west1".

3. Step 3: Eliminate incorrect options

   The configuration with "in:us-central1" uses invalid prefixes. Configurations using deniedValues do not restrict to only those regions: one attempts to deny outside the regions (wrong syntax and logic), the other denies the desired regions (allowing others).

4. Final Answer:

   constraint: constraints/gcp.resourceLocations listPolicy: allowedValues: - "us-central1" - "europe-west1" -> Option A

5. Quick Check:

   AllowedValues list regions as strings without prefixes = D [OK]

Hint: AllowedValues list regions as plain strings, no prefixes [OK]

Common Mistakes:

• Using prefixes like 'in:' in allowedValues
• Using deniedValues instead of allowedValues
• Misunderstanding constraint syntax for regions