Free ACE practice questions

The Google Cloud resource hierarchy defines how resources are grouped and how IAM policies and organization policies flow downward. Its layers, from top to bottom, are the organization node, folders, projects, and finally the service resources themselves.

Option (a) is the only ordering that matches Resource Manager's model: the organization is the root, folders provide optional intermediate grouping (for departments, teams, or environments), every resource must belong to exactly one project, and projects attach to a folder or directly to the organization. Options (b) and (d) invert the folder/project relationship — projects can never contain folders. Option (c) places folders above the organization, which is impossible because the organization node is always the root of the hierarchy.

1. Remember the hierarchy top-down: organization, folders, projects, resources.
2. Note that folders are optional and can be nested, but projects and the organization node are not optional in an enterprise setup.
3. Recall that IAM allow policies set at a higher level are inherited by everything beneath that level, which is why the ordering matters on the exam.

Exam tip: The hierarchy is organization, folders, projects, resources — and policies inherit downward through it.

Compute selection on Google Cloud maps workload characteristics to the platform that manages the most for you: Cloud Run for stateless request-driven containers, GKE for orchestrated container fleets you control, and Compute Engine when you need the VM itself.

The workload is stateless, containerized, and request-driven with long idle periods - exactly the Cloud Run profile. Cloud Run bills per use, scales from zero to many instances automatically, and removes all node and OS management. GKE and Compute Engine both leave always-on infrastructure and operational tasks with the team, which contradicts the least-operational-overhead and scale-to-zero requirements.

1. Identify the workload shape: stateless container, HTTP-driven, bursty traffic, long idle periods.
2. Match scale-to-zero plus fully managed requirements to serverless container platforms, which on Google Cloud means Cloud Run.
3. Eliminate GKE and Compute Engine options because both keep billable infrastructure running while idle and require node or VM management.

Exam tip: Stateless container plus bursty traffic plus minimal ops equals Cloud Run - it is the only listed option that scales to zero.

Identity-Aware Proxy (IAP) TCP forwarding lets you SSH or RDP into Compute Engine instances that have no external IP by tunneling the connection through Google's IAP service, authenticated by IAM.

gcloud compute ssh INSTANCE --tunnel-through-iap wraps the SSH session in an IAP tunnel that terminates on the instance's internal IP. Access is controlled by the roles/iap.tunnelResourceAccessor IAM role and a firewall rule allowing IAP's source range, so the VM stays completely private. An ephemeral external IP re-exposes the VM, Cloud NAT is outbound-only by design, and no firewall rule can make a private internal address internet-routable.

1. Grant your user the roles/iap.tunnelResourceAccessor role on the instance or project.
2. Ensure a firewall rule allows ingress on tcp:22 from IAP's source range 35.235.240.0/20.
3. Connect with: gcloud compute ssh INSTANCE_NAME --zone=ZONE --tunnel-through-iap.

Exam tip: To SSH into a VM with no external IP, use gcloud compute ssh --tunnel-through-iap with IAP TCP forwarding.

An IAM policy is a collection of role bindings attached to a resource, where each binding pairs a role with a list of principals. Viewing the policy on a project shows exactly who can do what at that level.

gcloud projects get-iam-policy <PROJECT_ID> prints the IAM policy attached to the project, including every binding of role to principals. That is precisely what an access audit needs. The other commands either modify the policy (add-iam-policy-binding), list role definitions (iam roles list), or list service account resources (service-accounts list) — none of them reports the project's role bindings.

1. Identify the resource whose access you need to audit — here, the project my-app-prod.
2. Run gcloud projects get-iam-policy my-app-prod to retrieve the policy attached to that project.
3. Read the bindings array: each entry shows a role and the members (principals) granted that role.
4. Remember that this shows only direct grants at the project level; roles inherited from the folder or organization appear in the ancestors' policies.

Exam tip: Use gcloud projects get-iam-policy to view a project's role bindings; add-iam-policy-binding changes them.

Two Google-recommended practices combine here: grant IAM roles to Google groups rather than individual users, and grant roles at the highest level of the hierarchy where they legitimately apply so inheritance does the fan-out for you.

A single binding of BigQuery Data Editor to the team's group on the "analytics" folder is inherited by all 12 projects beneath it, and monthly membership churn becomes a group-membership edit rather than an IAM change. Individual per-project grants (b) multiply the maintenance burden and risk drift. An organization-level grant (c) leaks the role into every unrelated project, violating least privilege. A shared account (d) removes individual accountability from Cloud Audit Logs and is explicitly discouraged.

1. Create or reuse a Google group in Cloud Identity that represents the data engineering team.
2. Add a single IAM binding on the "analytics" folder granting roles/bigquery.dataEditor to that group.
3. Manage joiners and leavers through group membership; the IAM policy never needs to change.

Exam tip: Grant roles to groups at the folder level and let inheritance and group membership do the ongoing work.