Access Context Manager in GCP - Step-by-Step Execution

Process Flow - Access Context Manager

Define Access Levels

↓

Create Access Policy

↓

Assign Access Levels to Policy

↓

Apply Policy to Resources

↓

User Requests Access

↓

Check Access Context

Yes No↓

Grant Access

Access Context Manager lets you define rules (access levels) and group them into policies. When a user tries to access a resource, the system checks these rules to allow or deny access.

Execution Sample

GCP

1. Define access level: IP range 192.168.1.0/24
2. Create access policy: "Office Access"
3. Add access level to policy
4. Apply policy to Cloud Storage bucket
5. User tries to access bucket

This example shows creating an access level for a specific IP range, grouping it into a policy, applying it to a resource, and then a user attempting access.

Process Table

Step	Action	Input/Condition	Result/Output
1	Define Access Level	IP range 192.168.1.0/24	Access level created with IP restriction
2	Create Access Policy	Name: Office Access	Access policy created
3	Add Access Level to Policy	Access level: IP range 192.168.1.0/24	Access level linked to policy
4	Apply Policy to Resource	Resource: Cloud Storage bucket	Policy applied to bucket
5	User Access Request	User IP: 192.168.1.15	Check access context
6	Evaluate Access Context	User IP in allowed range?	Yes
7	Access Decision	Access context valid	Access granted
8	User Access Request	User IP: 10.0.0.5	Check access context
9	Evaluate Access Context	User IP in allowed range?	No
10	Access Decision	Access context invalid	Access denied

💡 Execution stops after access decision is made for each user request.

Status Tracker

Variable	Start	After Step 1	After Step 3	After Step 4	After Step 6	After Step 9	Final
Access Level	None	IP range 192.168.1.0/24	Linked to policy	Linked to policy	Checked for user IP	Checked for user IP	Used for access decision
Access Policy	None	None	Created: Office Access	Applied to bucket	Applied to bucket	Applied to bucket	Used for access decision
User IP	None	None	None	None	192.168.1.15	10.0.0.5	Evaluated for access

Key Moments - 2 Insights

Why does the user with IP 10.0.0.5 get denied access?

Because the access level only allows IPs in 192.168.1.0/24 range. Step 9 shows the IP is outside this range, so access is denied at step 10.

What happens if no access policy is applied to a resource?

Without a policy, Access Context Manager does not restrict access, so users are not checked against access levels. This means access is not controlled by context.

Visual Quiz - 3 Questions

Look at the execution table, what is the result at Step 7 when user IP is 192.168.1.15?

A Access denied

B Access granted

C Access level created

D Policy applied

💡 Hint

Check Step 7 in execution_table where user IP is in allowed range.

At which step does the system check if the user IP is within the allowed range?

A Step 6

B Step 5

C Step 8

D Step 10

💡 Hint

Look for 'Evaluate Access Context' in execution_table.

If the access level allowed all IPs, how would Step 9 change for user IP 10.0.0.5?

A Access policy would be deleted

B User IP would be outside allowed range

C User IP would be inside allowed range

D User access request would be denied immediately

💡 Hint

Consider how access level IP range affects evaluation in Step 9.

Concept Snapshot

Access Context Manager controls resource access by defining access levels (rules like IP ranges).
These levels are grouped into access policies.
Policies are applied to resources.
When a user requests access, their context (e.g., IP) is checked against policies.
Access is granted only if context matches policy rules.

Full Transcript

Access Context Manager in Google Cloud lets you set rules called access levels, such as allowing only certain IP addresses. You group these levels into access policies and apply them to resources like storage buckets. When a user tries to access a resource, the system checks if their context, like their IP address, matches the rules. If it matches, access is granted; if not, access is denied. This helps keep your cloud resources safe by controlling who can reach them based on conditions you set.

Practice

1. What is the main purpose of Access Context Manager in Google Cloud?

easy

A. To manage billing accounts and payments

B. To monitor network traffic in real-time

C. To deploy virtual machines automatically

D. To control access to resources based on user context like location and device security

Solution

1. Step 1: Understand Access Context Manager's role

   It controls access by considering user context such as location and device security, not just identity.

2. Step 2: Compare with other options

   Billing, VM deployment, and network monitoring are unrelated to Access Context Manager's function.

3. Final Answer:

   To control access to resources based on user context like location and device security -> Option D

4. Quick Check:

   Access Context Manager controls access context = B [OK]

Hint: Access Context Manager controls access by context, not billing or VMs [OK]

Common Mistakes:

• Confusing Access Context Manager with billing or VM services
• Thinking it manages network traffic monitoring
• Assuming it only uses usernames and passwords

2. Which of the following is the correct way to define an Access Level in Access Context Manager using YAML?

easy

A. accessLevels:
- name: 'accessPolicies/123/accessLevels/level1'
title: 'Office Access'
basic:
conditions:
- ipSubnetworks: ['192.168.1.0/24']
devicePolicy:
osConstraints:
- osType: 'DESKTOP_MAC'
minimumVersion: '10.15'

B. accessLevels:
- id: 'level1'
description: 'Office Access'
conditions:
ipRanges: ['192.168.1.0/24']
device: 'MAC'

C. accessLevel:
- name: 'level1'
title: 'Office Access'
conditions:
ipSubnet: ['192.168.1.0/24']
devicePolicy:
osType: 'MAC'

D. accessLevels:
- name: 'accessPolicies/123/accessLevels/level1'
title: 'Office Access'
conditions:
ipSubnetworks: ['192.168.1.0/24']
devicePolicy:
osConstraints:
- osType: 'DESKTOP_MAC'
minimumVersion: '10.15'

Solution

1. Step 1: Review correct YAML structure for Access Level

   The correct syntax uses 'accessLevels' list with 'name', 'title', and 'basic' containing 'conditions' with 'ipSubnetworks' and 'devicePolicy' including 'osConstraints'.

2. Step 2: Identify errors in other options

   accessLevels: - id: 'level1' description: 'Office Access' conditions: ipRanges: ['192.168.1.0/24'] device: 'MAC' uses wrong keys like 'ipRanges' and 'device'. accessLevel: - name: 'level1' title: 'Office Access' conditions: ipSubnet: ['192.168.1.0/24'] devicePolicy: osType: 'MAC' uses 'accessLevel' singular and wrong keys. accessLevels: - name: 'accessPolicies/123/accessLevels/level1' title: 'Office Access' conditions: ipSubnetworks: ['192.168.1.0/24'] devicePolicy: osConstraints: - osType: 'DESKTOP_MAC' minimumVersion: '10.15' misses 'basic' wrapper around 'conditions'.

3. Final Answer:

   accessLevels: - name: 'accessPolicies/123/accessLevels/level1' title: 'Office Access' basic: conditions: - ipSubnetworks: ['192.168.1.0/24'] devicePolicy: osConstraints: - osType: 'DESKTOP_MAC' minimumVersion: '10.15' -> Option A

4. Quick Check:

   Correct YAML keys and structure = A [OK]

Hint: Look for 'basic' and 'conditions' keys in YAML for Access Level [OK]

Common Mistakes:

• Using singular 'accessLevel' instead of 'accessLevels'
• Missing 'basic' wrapper for conditions
• Incorrect keys like 'ipRanges' or 'device' instead of 'ipSubnetworks' and 'devicePolicy'

3. Given this Access Context Manager policy snippet, what will happen if a user tries to access a resource from IP 203.0.113.5?

accessLevels:
- name: 'accessPolicies/456/accessLevels/levelA'
  basic:
    conditions:
    - ipSubnetworks: ['192.168.0.0/16']
      devicePolicy:
        osConstraints:
        - osType: 'DESKTOP_WINDOWS'
          minimumVersion: '10'

medium

A. Access will be denied because the IP is outside the allowed subnet

B. Access will be allowed because device OS matches

C. Access will be allowed because IP is public

D. Access will be denied because OS version is too low

Solution

1. Step 1: Check IP subnet condition

   The allowed IP subnet is '192.168.0.0/16', which covers private IPs only. The user's IP '203.0.113.5' is public and outside this range.

2. Step 2: Evaluate access decision

   Since IP does not match allowed subnet, access is denied regardless of device OS.

3. Final Answer:

   Access will be denied because the IP is outside the allowed subnet -> Option A

4. Quick Check:

   IP outside allowed subnet = Access denied [OK]

Hint: Check IP subnet first; outside means deny access [OK]

Common Mistakes:

• Ignoring IP subnet and trusting device OS alone
• Assuming public IPs are always allowed
• Confusing IP ranges with device policies

4. You created an Access Level but users report they cannot access resources even when meeting conditions. Which is the most likely error in your Access Context Manager configuration?

medium

A. The device OS version is set too low

B. The Access Level is not attached to any Access Policy

C. The IP subnet range is too broad

D. The Access Level name is missing

Solution

1. Step 1: Understand Access Level usage

   Access Levels must be part of an Access Policy to enforce rules on resources.

2. Step 2: Analyze impact of missing Access Policy attachment

   If Access Level is not attached to any Access Policy, it has no effect, so users cannot access resources despite meeting conditions.

3. Final Answer:

   The Access Level is not attached to any Access Policy -> Option B

4. Quick Check:

   Access Level without policy attachment = no access enforced [OK]

Hint: Access Levels must be linked to Access Policies to work [OK]

Common Mistakes:

• Assuming broad IP ranges cause denial
• Thinking device OS version too low blocks access
• Ignoring the need to attach Access Levels to Policies

5. You want to create a service perimeter that restricts access to a Google Cloud Storage bucket only to users accessing from your corporate network and using compliant devices. Which combination of Access Context Manager components should you configure?

hard

A. Use only IAM roles to restrict access based on user identity and device type

B. Create a firewall rule blocking all external IPs and enable device compliance in IAM roles

C. Create an Access Policy with an Access Level defining IP subnet and device compliance, then apply it in a Service Perimeter around the bucket

D. Configure VPC Service Controls without Access Context Manager components

Solution

1. Step 1: Understand components needed

   Access Context Manager uses Access Policies and Access Levels to define conditions like IP subnet and device compliance.

2. Step 2: Apply conditions with Service Perimeter

   Service Perimeters enforce these Access Levels around resources like Cloud Storage buckets to restrict access accordingly.

3. Final Answer:

   Create an Access Policy with an Access Level defining IP subnet and device compliance, then apply it in a Service Perimeter around the bucket -> Option C

4. Quick Check:

   Access Policy + Access Level + Service Perimeter = A [OK]

Hint: Combine Access Policy, Access Level, and Service Perimeter for resource protection [OK]

Common Mistakes:

• Relying only on firewall or IAM roles without Access Context Manager
• Using VPC Service Controls alone without Access Levels
• Not defining device compliance in Access Levels