Cloud Digital Leader How Google Cloud Resources Are Managed Practice Question
An organization wants to ensure that all projects in their GCP organization have consistent IAM policies. They also need to restrict the use of external IP addresses on Compute Engine instances for security. Which TWO tools should they use? (Choose TWO.)
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use an organization policy constraint 'compute.vmExternalIpAccess' at the organization level
Organization policies can enforce restrictions like disabling external IP addresses across the entire organization. IAM policies at the organization level can set baseline access controls inherited by all projects.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use an organization policy constraint 'compute.vmExternalIpAccess' at the organization level
Why this is correct
The organization policy constraint 'compute.vmExternalIpAccess' is a list constraint that can be applied at the organization, folder, or project level. When set at the organization level, it is inherited by all child resources, allowing you to centrally deny or restrict the assignment of external IP addresses to VM instances across every project. This is the correct approach because it is a hard enforcement mechanism that cannot be bypassed by project-level IAM or quota changes, and it provides a consistent, organization-wide security guardrail.
- ✗
Apply a deny IAM policy to each project individually
Why it's wrong here
Applying a deny IAM policy to each project individually is not effective because deny policies are evaluated per resource and are not inherited across projects; you would need to configure and maintain each project separately, leading to inconsistent coverage if a new project is created or a policy is missed. Moreover, IAM policies, including deny policies, are designed to control who can perform actions, not to restrict resource configurations such as whether a VM is allowed to have an external IP. This approach is operationally fragile and does not provide the centralized, inherited enforcement that an organization policy constraint offers.
- ✗
Set a quota for external IP addresses per project
Why it's wrong here
Setting a quota for external IP addresses per project is an incorrect solution because quotas only limit the maximum number of a resource that can be created, not whether the resource is allowed at all. Users can still assign a single external IP to a VM, and they might request quota increases, which defeats the intended blanket restriction. A quota also does not prevent a VM from being created with an external IP; it only caps the count, so it is not a suitable substitute for an organization policy constraint that explicitly denies external IP assignment.
- ✗
Use network tags to block external IPs
Why it's wrong here
Network tags are not a mechanism for controlling whether a VM gets an external IP; they are primarily used for applying firewall rules and for logically grouping VM instances for network policy decisions. Tags cannot be used to block or restrict the assignment of an external IP address because the existence of an external IP is a property of the VM's network interface, not a traffic rule. Firewall rules associated with tags can only filter network traffic, not alter the IP configuration of the VM, so this option is fundamentally mismatched to the requirement.
- ✓
Define IAM policies at the organization level
Why this is correct
Defining IAM policies at the organization level ensures that permissions are inherited by all child projects, but IAM policies govern who can perform actions on resources, not what those resources are allowed to look like. For example, an IAM policy can grant someone permission to create VMs, but it cannot enforce that those VMs are created without an external IP address. While this option is correct about inheritance, it addresses a different concern (access control) rather than the required resource configuration guardrail, so it does not solve the stated problem.
Go deeper
Related to this question
Learn chapter
Compute Options on Google Cloud
Key term
Compute Engine
Compute Engine is Google Cloud's Infrastructure-as-a-Service (IaaS) offering that lets you create and run virtual machines on Google's infrastructure.
Key term
Organization
An Organization is a top-level container in Google Cloud that represents your company or entities and serves as the root node for all your cloud resources, policies, and access control.
About these practice questions
One of 829 original GCDL practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This GCDL practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the GCDL exam.