Organization policies in GCP - Commands & Configuration

Introduction

Organization policies help control what users and projects can do in Google Cloud. They set rules to keep your cloud environment safe and organized.

When you want to prevent users from creating resources in certain regions to comply with data laws.

When you need to restrict the types of virtual machines that can be launched to control costs.

When you want to enforce encryption settings across all projects in your organization.

When you want to block the use of public IP addresses on virtual machines for security.

When you want to ensure all projects use a specific network configuration.

Config File - policy.yaml

policy.yaml

name: organizations/1234567890/policies/constraints/compute.vmExternalIpAccess
spec:
  rules:
  - denyAll: true
  etag: BwWWja0YfJA=
  version: 1

This file defines an organization policy that blocks all virtual machines from having external IP addresses.

name: identifies the policy and the constraint it applies to.

spec.rules.denyAll: means no VM can have an external IP.

etag: used to prevent conflicts when updating the policy.

version: policy schema version.

Commands

Check the current organization policy for blocking external IPs on VMs to see if it is set.

Terminal

gcloud org-policies describe compute.vmExternalIpAccess --organization=1234567890

Expected Output

name: organizations/1234567890/policies/constraints/compute.vmExternalIpAccess

spec:

  rules:

  - denyAll: true

etag: BwWWja0YfJA=

version: 1

→

--organization - Specify the organization ID to target the policy.

Apply the organization policy defined in policy.yaml to block external IPs on all VMs in the organization.

Terminal

gcloud org-policies set-policy policy.yaml --organization=1234567890

Expected Output

Updated policy [organizations/1234567890/policies/constraints/compute.vmExternalIpAccess].

→

--organization - Specify the organization ID to apply the policy.

Verify that the organization policy to block external IPs is now active.

Terminal

gcloud org-policies describe compute.vmExternalIpAccess --organization=1234567890

Expected Output

name: organizations/1234567890/policies/constraints/compute.vmExternalIpAccess

spec:

  rules:

  - denyAll: true

etag: BwWWja0YfJA=

version: 1

→

--organization - Specify the organization ID to check the policy.

Key Concept

If you remember nothing else from this pattern, remember: organization policies let you set rules that control what can or cannot be done across all projects in your Google Cloud organization.

Common Mistakes

Trying to set an organization policy without specifying the organization ID.

The command will fail because it doesn't know which organization to apply the policy to.

Always include the --organization flag with your organization ID when managing policies.

Editing the policy file but forgetting to update the etag value.

The policy update will be rejected to prevent conflicting changes.

Use the current etag from the existing policy or omit it to let the system handle it.

Not verifying the policy after applying it.

You might think the policy is active when it is not, leading to unexpected permissions.

Always describe the policy after setting it to confirm the changes took effect.

Summary

Use gcloud commands with the --organization flag to manage organization policies.

Create a YAML file defining the policy rules, including deny or allow settings.

Apply the policy with gcloud org-policies set-policy and verify with describe.

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