GCP ACE Practice / Study guide / Topics / Resource Hierarchy, Projects & APIs

Resource Hierarchy, Projects & APIs

What actually gets tested on the Google Cloud Associate Cloud Engineer exam, the traps to know, and 6 free sample questions with full explanations.

Every resource in Google Cloud sits inside a strict hierarchy: an organization at the root, optional folders beneath it (folders can nest inside folders), projects inside folders or directly under the organization, and individual resources — VMs, buckets, databases — inside projects. IAM policies set higher in the tree are inherited downward, which makes a Finance folder with a policy on it a genuinely effective way to manage access centrally across every project underneath, automatically, without touching each project individually.

Project lifecycle has two facts the exam tests constantly: the project ID is chosen once at creation and is immutable forever, while the project name is just a mutable display label — and the project number is a third, separate identifier Google assigns automatically. A deleted project enters a roughly 30-day pending-deletion state during which someone with the right permissions can run gcloud projects undelete or use the console to restore it; after that window, it's gone for good and its ID can never be reused by anyone.

Before using a Google Cloud service in a project, its API has to be enabled — a step that's easy to forget when reading a scenario and a common reason a described setup "doesn't work" until you notice the API was never turned on. This is also the domain where Cloud Identity and Google Workspace decisions get made (see the Service Accounts & Identity topic for the identity side of that), and where billing accounts first get linked to a project.

Exam tips for this topic

Sample questions — Resource Hierarchy, Projects & APIs

These 6 questions are drawn from our full bank of 658 to show the style and depth you'll get in the app. Each comes with the full explanation you'd see after answering in a real practice session.

APIs

Your new project throws an error that the Compute Engine API has not been used or is disabled. What should you do?

Why: Each project must explicitly enable the APIs it uses; gcloud services enable (or the console API Library) fixes this. IAM roles and service accounts don't matter if the API itself is disabled, and billing being enabled is a prerequisite but the error specifically indicates a disabled API.
Projects

You accidentally deleted a project yesterday. What should you do?

Why: A deleted project enters a ~30-day pending-deletion state during which someone with the right permissions can restore it (gcloud projects undelete or the console). After the window it is gone permanently, and its project ID can never be reused — so re-creating with the same ID is impossible and support isn't required within the window.
Resource hierarchy

Your company wants IAM policies for the finance department to automatically apply to all of that department's current and future projects. What should you do?

Why: IAM policies set on a folder are inherited by every project (and resource) inside it, so a Finance folder gives centralized, automatic policy management. Repeating policies per project is error-prone, a second organization fragments administration, and labels are metadata for organization and billing reports — IAM policies cannot target labels.
APIs

How can you list which APIs are currently enabled in your project?

Why: gcloud services list shows enabled services by default (--available lists everything you could enable). The other commands don't exist in that form or list unrelated resources.
Projects

Which attribute of a Google Cloud project can be changed after the project is created?

Why: The project name is a mutable display label. The project ID is chosen at creation and immutable afterward, and the project number is assigned by Google and also immutable. This is why teams should pick meaningful project IDs up front.
Resource hierarchy

What is the correct top-down order of the Google Cloud resource hierarchy?

Why: The hierarchy is Organization at the root, optional Folders below it (which can nest), Projects inside folders or directly under the organization, and individual resources (VMs, buckets, etc.) inside projects. IAM policies inherit down this tree.

Practice this for real

The app has dozens more questions on this and every other topic, with instant scoring, spaced repetition of what you get wrong, and progress tracking across sessions.

Start practicing →

This topic shows up in

Domain 1Setting Up a Cloud Solution Environment

Other topics

TopicIAM Roles & Permissions TopicService Accounts & Identity TopicBilling, Pricing & Cost Management TopicGoogle Kubernetes Engine (GKE) Topicgcloud CLI Commands TopicChoosing the Right Compute Option TopicCompute Engine Deployment & Operations TopicCloud Monitoring, Logging & Audit Logs TopicVPC Networking & Load Balancing TopicChoosing a Database on Google Cloud TopicCloud Storage: Classes, Access & Security TopicServerless Compute: Cloud Run & App Engine TopicData Protection: Encryption & Secret Manager TopicInfrastructure as Code & Cloud Shell