Setting up a cloud solution environment practice questions

IAM allow policies in Google Cloud are additive and allow-only. A resource's effective policy is the union of the policy set directly on it and the policies inherited from its ancestors — a lower level can add access but never take inherited access away.

Because the Viewer grant lives at the organization level, it flows down to every project, including the sensitive one. Option (c) is right: the only clean fixes are to change the grant at its source — for example, remove the org-level binding and instead grant Viewer on the folders or projects the auditor actually needs. Option (a) fails because there is no project-level binding to remove. Option (b) confuses organization policy (configuration guardrails) with IAM (who can do what). Option (d) invents deny entries inside allow policies, which do not exist.

1. Identify where the binding was made — here, on the organization node.
2. Recall that inheritance is additive: child policies cannot subtract ancestor grants.
3. Rescope the grant: remove the org-level Viewer binding and re-grant it on the specific folders or projects that should be visible.

Exam tip: You cannot revoke an inherited role at a lower level — fix the grant where it was made.

Organization policies and IAM answer different questions. IAM decides who can perform actions; organization policy constraints decide what resource configurations are allowed at all, and they bind everyone — even project owners — throughout the subtree where they are set.

The requirement is a configuration guardrail that must hold "regardless of IAM roles," which is the textbook use case for an organization policy constraint. Applying compute.vmExternalIpAccess (set to deny all) at the organization node enforces it everywhere, including future projects. Option (a) tries to encode a configuration rule in IAM, which cannot express it reliably and must be repeated for every principal. Option (b) restricts traffic after the fact but leaves the external IP assignable. Option (d) is monitoring, not prevention.

1. Recognize "must hold regardless of who or which role" as an organization policy requirement, not an IAM one.
2. Choose the matching constraint — compute.vmExternalIpAccess — and configure it to deny all external IPs.
3. Set the constraint at the organization node so every current and future folder and project inherits it.

Exam tip: Use organization policy constraints for what can be configured; use IAM for who can act.

Google recommends binding IAM roles to Google groups managed in Cloud Identity, so that onboarding and offboarding are group-membership operations rather than IAM policy edits.

The access model is already correct: roles are attached to data-analysts@example.com. Adding the three hires to that group (c) gives them exactly the team's access, instantly and auditable. Option (a) creates parallel individual bindings that will drift when the group's roles evolve. Option (b) grants a basic role that is much broader than needed, violating least privilege. Option (d) forks the access model into a second group that must be kept manually in sync — the definition of avoidable operational risk.

1. Confirm the team's roles are bound to the Google group, not to individuals.
2. Add the new analysts' Cloud Identity accounts to the group.
3. Verify access, and rely on the same mechanism (removal from the group) when people leave.

Exam tip: When roles are bound to a group, onboarding is a group-membership change — never a pile of new IAM bindings.

Every Google Cloud service exposes its functionality through an API that must be enabled per project before use. The gcloud services command group (enable, disable, list) manages this enablement.

The error is the standard symptom of a disabled API in a fresh project, and gcloud services enable compute.googleapis.com (b) is the canonical fix, optionally with --project to target a specific project. Options (a), (c), and (d) name command groups or subcommands that do not exist — gcloud apis is not a group, gcloud projects handles project lifecycle rather than APIs, and gcloud compute has no enable-api verb. Remembering that all API enablement flows through gcloud services eliminates every distractor.

1. Read the error: an "API has not been used" message means the service API is disabled in the project.
2. Run gcloud services enable compute.googleapis.com --project=PROJECT_ID (or rely on the configured default project).
3. Confirm with gcloud services list --enabled, then retry the original command.

Exam tip: APIs are enabled per project with gcloud services enable SERVICE_NAME.

Google Cloud quotas cap resource usage per project, typically per region. When legitimate need exceeds a quota, the supported path is a quota increase request, which is reviewed and may take time to approve — so plan ahead of demand spikes.

Option (a) matches Google's guidance exactly: identify the constrained quota (CPUs in us-central1), file an increase request from the Quotas page, and do it early because approval is not immediate. Option (b) proposes a control that does not exist. Option (c) confuses support entitlements with capacity limits. Option (d) is an anti-pattern: multiplying projects to evade quota complicates IAM, networking, and cost management and does not scale as an operating practice.

1. In the console, open IAM & Admin > Quotas and filter to the Compute Engine CPUs quota for us-central1.
2. Select the quota and submit an increase request with the new required value and justification.
3. Submit well before the launch date, since requests are reviewed and are not guaranteed to be instant.

Exam tip: Quotas are raised by an increase request on the Quotas page — request early, because approval is not instant.

Least privilege in the resource hierarchy has two dimensions: pick the narrowest role that covers the task, and grant it at the lowest level of the hierarchy that covers the required scope.

The task is exactly what roles/resourcemanager.projectCreator exists for, and binding it on the "engineering" folder (c) confines project creation to that subtree. Folder Admin (a) matches the scope but not the role — it adds folder IAM and structure management the lead should not have. Option (b) matches the role but not the scope, allowing creation across the whole organization. Organization Administrator (d) fails both tests, granting org-wide IAM control for a single-folder need.

1. Identify the minimal capability required: creating projects, nothing else.
2. Map it to the predefined role roles/resourcemanager.projectCreator.
3. Bind the role on the "engineering" folder so it applies only within that subtree.

Exam tip: Least privilege means the narrowest role at the lowest sufficient level — Project Creator on the specific folder.