Organization policies in GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding the effect of Organization Policy constraints

You have set the constraint constraints/compute.disableSerialPortAccess to ENFORCED at the organization level in Google Cloud. What is the expected behavior for all VM instances in projects under this organization?

A All VM instances will have serial port access disabled, regardless of project or instance-level settings.

B VM instances can override this setting at the project level to enable serial port access.

C Only new VM instances created after the policy is set will have serial port access disabled.

D The policy only applies to VM instances in projects with billing enabled.

💡 Hint

Think about how organization policies enforce constraints across all projects and resources.

Organization policies with constraints set to ENFORCED apply to all resources under the organization and cannot be overridden at lower levels. Therefore, serial port access is disabled for all VM instances regardless of project or instance settings.

❓ Architecture

intermediate

Applying Organization Policies to restrict resource locations

You want to restrict all projects in your organization to create resources only in the us-central1 and us-east1 regions. Which organization policy constraint should you apply, and where should it be set?

A Set the <code>constraints/compute.allowedRegions</code> constraint with allowed values <code>us-central1</code> and <code>us-east1</code> at the folder level.

B Set the <code>constraints/gcp.resourceLocations</code> constraint with allowed values <code>us-central1</code> and <code>us-east1</code> at the project level.

C Set the <code>constraints/gcp.resourceLocations</code> constraint with allowed values <code>us-central1</code> and <code>us-east1</code> at the organization level.

D Set the <code>constraints/compute.allowedRegions</code> constraint with allowed values <code>us-central1</code> and <code>us-east1</code> at the organization level.

💡 Hint

Consider which constraint controls resource location restrictions and the scope of enforcement.

The constraints/gcp.resourceLocations constraint controls where resources can be created. Setting it at the organization level restricts all projects under it. The constraints/compute.allowedRegions constraint does not exist.

❓ security

advanced

Impact of Organization Policy on Service Account Key creation

An organization policy is set to constraints/iam.disableServiceAccountKeyCreation with ENFORCED at the folder level. What will happen if a user tries to create a new service account key in a project under that folder?

A Service account key creation is allowed but keys will be automatically rotated.

B Users can create service account keys if they have the <code>iam.serviceAccountKeyAdmin</code> role.

C The policy only blocks key creation if set at the project level, not folder level.

D The creation of new service account keys will be blocked for all projects under the folder.

💡 Hint

Think about how organization policies propagate and enforce security constraints.

The constraints/iam.disableServiceAccountKeyCreation constraint set to ENFORCED at the folder level blocks all service account key creation in projects under that folder, regardless of user roles.

❓ service_behavior

advanced

Behavior of conflicting Organization Policies at different levels

An organization policy constraints/compute.vmExternalIpAccess is set to ENFORCED at the organization level to deny external IPs on VMs. However, at a specific project, the same constraint is set to NOT_ENFORCED. What is the effective behavior for VM instances in that project?

A Both policies are merged, causing an error and blocking VM creation.

B The organization-level policy overrides the project-level setting, so external IPs are denied on VMs.

C The VM instances will have external IPs allowed only if explicitly set during creation.

D The project-level policy overrides the organization-level, allowing external IPs on VMs.

💡 Hint

Consider the hierarchy and precedence of organization policies.

Organization policies set at higher levels (organization) override conflicting policies at lower levels (project). Therefore, the ENFORCED deny on external IPs at the organization level takes precedence.

✅ Best Practice

expert

Designing Organization Policies for multi-team environment

Your company has multiple teams managing projects under a single organization. You want to enforce a policy that restricts VM instance machine types to a predefined list but allow teams to add more machine types if needed. What is the best way to implement this using organization policies?

A Set <code>constraints/compute.allowedMachineTypes</code> at the organization level with the predefined list, and require teams to request changes through a central admin to update the policy.

B Set <code>constraints/compute.allowedMachineTypes</code> at the organization level with the predefined list, and allow projects to add exceptions using policy inheritance and overrides.

C Do not set any organization policy and rely on IAM roles to restrict machine types per team.

D Set the constraint only at the project level for each team with their allowed machine types.

💡 Hint

Think about how organization policies enforce constraints and how exceptions can be managed.

Organization policies do not support additive overrides for allowed values. To maintain control and security, set the allowed machine types at the organization level and require teams to request changes through a central admin who updates the policy. This ensures consistent enforcement and auditability.

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