Restrict Google Cloud Project Access via IP Ranges | PCSE

PCSE By islever Editorial Last updated Sep 9, 2026

Short answer

C Create an access level with IP subnetwork conditions for the specified ranges and apply it to the service perimeter enclosing the sensitive project.

Question

Your organization is adopting Google Cloud and wants to ensure sensitive resources are only accessible from devices within the internal on-premises corporate network. You must configure Access Context Manager to enforce this requirement. These considerations apply: • The internal network uses IP ranges 10.100.0.0/16 and 192.168.0.0/16. • Some employees work remotely but connect securely through a company-managed virtual private network (VPN). The VPN dynamically allocates IP addresses from the pool 172.16.0.0/20. • Access should be restricted to a specific Google Cloud project that is contained within an existing service perimeter. What should you do?

Create an access level named "Authorized Devices." Utilize the Device Policy attribute to require corporate-managed devices. Apply the access level to the Google Cloud project and instruct all employees to enroll their devices in the organization's management system.
Create an access level titled "Internal Network Only." Add a condition with these attributes:
Create an access level titled "Corporate Access." Add a condition with the IP Subnetworks attribute, including the ranges: 10.100.0.0/16, 192.168.0.0/16, 172.16.0.0/20. Assign this access level to a service perimeter encompassing the sensitive project. Correct Answer
Create a new IAM role called "InternalAccess. Add the IP ranges 10.100.0.0/16, 192.16.0.0/16, and 172.16.0.0/20 to the role as an IAM condition. Assign this role to IAM groups corresponding to on-premises and VPN users. Grant this role the necessary permissions on the resource within this sensitive Google Cloud project.

Key Takeaways

Tests proper use of Access Context Manager IP subnetwork conditions to enforce network-based restrictions across a service perimeter without misusing IAM or device policies.

Learn how to configure Access Context Manager IP subnetwork conditions to restrict Google Cloud project access to specific corporate and VPN ranges within a service perimeter. This page confirms why option C is the correct implementation.

Common mistake: Candidates often select IAM conditions or device management policies, confusing resource-level access controls with perimeter-level network enforcement.

Expert Analysis

Why the Answer Is Correct

Access Context Manager (ACM) serves as Google Cloud’s centralized policy engine for controlling resource access within VPC Service Perimeters. By defining an Access Level that specifies exact IP subnetworks, administrators can restrict traffic exclusively to known corporate and VPN address pools. Applying this Access Level to the existing service perimeter ensures that only requests originating from the three specified CIDR blocks reach the sensitive project. This configuration directly satisfies the exam requirement using native perimeter security controls.

Why the Other Options Are Wrong

Option A relies on Device Policy, which evaluates endpoint compliance rather than source IP addresses, failing to meet the stated network restriction. Option B is incomplete and lacks the necessary condition syntax to function. Option D attempts to filter traffic using IAM conditions, which are evaluated at the API call level after perimeter checks and cannot enforce infrastructure-level network boundaries like a service perimeter does.

Community Comment Notes

Test-takers consistently validate this configuration by referencing official Google Cloud documentation on Access Context Manager IP address handling. Several learners emphasize that applying the IP condition directly to the service perimeter is the most efficient way to block unauthorized external traffic. As nah99 noted, the official docs confirm the IP address attribute behavior. BondleB added that leveraging built-in security features effectively enforces network-based controls.

Official Reference

https://cloud.google.com/access-context-manager/docs/overview#ip-address

This link opens the official vendor documentation in a new tab.

Exam Strategy

When a question specifies restricting access to a service perimeter based on source networks, always prioritize Access Context Manager over IAM roles or conditions. Map the required IP CIDR blocks directly to an Access Level condition, then attach that level to the perimeter policy to ensure infrastructure-level enforcement.

Frequently Asked Questions

Why can't I use IAM conditions instead of Access Context Manager?

IAM conditions evaluate permissions after perimeter checks and lack native support for enforcing infrastructure-level network boundaries like service perimeters require.

How does applying an Access Level to a service perimeter differ from IAM binding?

Service perimeter policies operate at the VPC network boundary, blocking traffic before it reaches IAM evaluation, making them ideal for strict IP-based restrictions.

More PCSE FAQ →

Community Votes

100%

100% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 3 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 3

BondleB 👍 2 Answered C

The recommended approach is to configure Access Context Manager to create access levels incorporating the specified IP ranges (10.100.0.0/16, 192.168.0.0/16, and 172.16.0.0/20) and apply this access level to the existing service perimeter containing the sensitive resources. This method leverages Google Cloud’s built-in security features to enforce network-based access controls effectively and provides better security and compliance for the sensitive resources.
nah99 👍 2 Answered C

https://cloud.google.com/access-context-manager/docs/overview#ip-address
yokoyan 👍 1 Answered C

I think it's C.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

← Back to PCSE Study Guide