Free ACE practice questions

The Google Cloud resource hierarchy is a tree managed by Resource Manager: one organization node at the root, optional (and nestable) folders, projects, and the service resources inside projects. IAM allow policies and organization policies attached to a node are inherited by everything below it.

Only the organization-folders-projects-resources ordering matches the model. The organization node is always the root; folders give optional intermediate grouping for departments or environments; each resource belongs to one project; and a project is parented by a folder or by the organization. The other orderings either put folders under projects, which is impossible, or place something above the organization node.

1. Identify the root: the organization node, created from a Cloud Identity or Google Workspace domain.
2. Place folders as the optional grouping layer beneath it (folders can nest).
3. Place projects under folders or directly under the organization.
4. Remember that every service resource lives inside exactly one project.

Exam tip: Organization > folders > projects > resources, and policies inherit downward along that path.

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

The API is stateless, already containerized and request-driven with long idle periods, and the team wants no nodes and no idle charges: that is the Cloud Run profile, because Cloud Run scales to zero instances. GKE Autopilot is the tempting near-twin since it also hides nodes, but the cluster fee and the running Pods keep billing while idle. GKE Standard and managed instance groups add node or VM management on top of idle charges.

1. Note the workload shape: stateless container, HTTP requests, bursty, idle for hours.
2. Apply the two constraints: no node or VM management, and no charges while idle.
3. Eliminate options that keep billable infrastructure running while idle (both GKE modes, managed instance groups).
4. Choose Cloud Run, which scales to zero.

Exam tip: Stateless container + no infrastructure to manage + nothing to pay while idle = Cloud Run; Autopilot hides nodes but does not stop billing when idle.

Identity-Aware Proxy (IAP) TCP forwarding lets you SSH or RDP to Compute Engine VMs that have only internal IPs, by tunnelling the connection through Google's IAP service and authorising it with IAM.

gcloud compute ssh --tunnel-through-iap wraps the SSH session in an IAP tunnel that ends on the VM's internal IP, so the VM stays private and the laptop needs nothing but gcloud and IAM permission. The tempting near-twin is --internal-ip: it also avoids a public IP, but it needs network reachability to the private address, which the stem rules out (no VPN or Interconnect). A temporary external IP breaks the stated policy, and Cloud NAT is outbound-only.

1. Note the constraints: no external IP, no bastion, no private network path from the laptop.
2. Eliminate anything that adds a public IP or relies on a route into the VPC (--internal-ip).
3. Remember Cloud NAT is egress-only, so it cannot carry an inbound SSH session.
4. Choose IAP TCP forwarding: gcloud compute ssh VM --zone=ZONE --tunnel-through-iap.

Exam tip: No external IP and no private network path: gcloud compute ssh --tunnel-through-iap; --internal-ip needs a VPN, Interconnect or a host inside the VPC.

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 practices combine here: bind roles to groups rather than individual users, and attach the binding at the lowest hierarchy node that covers all the resources that need it. Folder-level bindings are inherited by every project in the folder, including projects created later.

A single group binding on the analytics folder satisfies both moving parts: people change through group membership, and new projects inherit the folder binding automatically. Per-project group grants handle people but not new projects; an organization-level grant handles both but over-scopes access to every project; per-user grants handle neither.

1. List what changes over time: team members and the number of projects.
2. Group-based binding absorbs membership changes without IAM edits.
3. A folder-level binding absorbs new projects through inheritance.
4. Reject the organization node because it grants access beyond the analytics folder.

Exam tip: Group plus the lowest common ancestor folder: people change in the group, projects inherit from the folder.