Setting Up Google Cloud Projects, Resource Hierarchy, and IAM

The resource hierarchy is a tree: one organization node at the root, optional folders beneath it, projects inside the organization or folders, and every actual resource — VMs, buckets, databases — inside a project. Resource Manager is the service that creates and manages this tree.

The organization node represents your company and is created automatically when you set up Cloud Identity or Google Workspace with a verified domain. If your company has no Google Workspace, you can set up a standalone organization by creating a free Cloud Identity account, verifying domain ownership, and then creating your first project under it — the organization node appears the first time a user from that domain creates a project or billing account. Folders group projects by department, team, or environment (for example engineering/prod and engineering/dev) and are the natural attachment point for policies that apply to a subset of the company.

Projects are the unit that matters day to day. Every project has three identifiers: a mutable display name, a globally unique, immutable project ID you choose at creation (used in gcloud commands and API calls), and a Google-assigned immutable project number. Create one with gcloud projects create my-app-prod --organization=ORG_ID or place it in a folder with --folder=FOLDER_ID. APIs are enabled per project, billing is linked per project, and quotas are enforced per project — which is why the exam's default answer to "how do I isolate two workloads?" is almost always "separate projects."

IAM policies attached at a higher level of the hierarchy are inherited by everything beneath: a role granted on the organization applies to every folder, project, and resource in it; a role granted on a folder applies to all its projects; a role granted on a project applies to all resources in that project. The effective policy on a resource is the union of the policy set on it and every policy inherited from above — and a lower level can never remove or restrict a grant made higher up. If someone is Editor on the organization, making them Viewer on one project does not reduce their access there.

An IAM policy is a set of role bindings: each binding ties a role (a bundle of permissions) to one or more principals — a Google Account, a group, a service account, or a domain. Grant one in a project with gcloud projects add-iam-policy-binding my-app-prod --member=group:devs@example.com --role=roles/compute.instanceAdmin.v1.

The three role types

Two habits the exam rewards: grant roles to groups, not individual users, and grant at the lowest level of the hierarchy that satisfies the need.

Organization policies constrain what can be done with resources, regardless of who is doing it — the complement to IAM, which controls who can do what. An organization policy is built from a constraint, and constraints come in two flavors: boolean constraints that enforce or not (for example constraints/compute.disableSerialPortAccess or constraints/iam.disableServiceAccountKeyCreation) and list constraints that allow or deny specific values (for example constraints/gcp.resourceLocations to restrict which regions resources may be created in, or constraints/compute.vmExternalIpAccess to control which VMs may have external IPs).

Like IAM, organization policies attach to the organization, a folder, or a project and are inherited downward. Unlike IAM, a lower node can override the inherited policy — replacing it entirely or, for list constraints, merging with the parent's values — unless the parent is configured to block overrides. That override behavior is a favorite exam discriminator: IAM inheritance is strictly additive; organization policy inheritance can be overridden below.

Setting policies requires the Organization Policy Administrator role (roles/orgpolicy.policyAdmin), which is granted at the organization level. A typical scenario: the security team wants to guarantee that no resource in the finance folder is ever created outside approved regions. The answer is a gcp.resourceLocations list constraint on that folder — not an IAM change, because IAM cannot express "nobody, not even Owners, may do this." When you see "prevent anyone from…" or "enforce across all projects," think organization policy before IAM.

Cloud Identity is where the human identities live — Google Cloud IAM grants roles to identities but never creates them. Cloud Identity provides Google Accounts for your domain (free and premium tiers exist) and is administered in the Admin console at admin.google.com, which is separate from the Google Cloud Console. Users, groups, and organizational units are managed there by a Super Admin.

Manual management means creating users and groups directly in the Admin console: add alice@example.com, create the group devs@example.com, add members. This works for small teams but drifts out of date fast.

Automated management keeps Cloud Identity synchronized with an existing source of truth. The main options:

• Google Cloud Directory Sync (GCDS) — a tool you run on-premises that performs one-way sync from an LDAP directory into Cloud Identity. The directory server remains authoritative; GCDS never writes back to it.
• SAML single sign-on — authentication is delegated to your external identity provider, so users sign in with corporate credentials while their accounts still exist in Cloud Identity.
• Provisioning APIs and connectors — the Admin SDK Directory API or your IdP's provisioning integration can create and deactivate users automatically as people join and leave.

The operational pattern the exam expects: sync or provision users automatically, organize them into groups that mirror job functions, and bind IAM roles to those groups. When an engineer changes teams, membership changes in one place and every project's access updates with it — no IAM edits required.

Workforce Identity Federation lets your employees access Google Cloud using their existing external identity provider without creating Google Accounts for them at all — the alternative to syncing users into Cloud Identity. Your IdP authenticates the user via SAML 2.0 or OpenID Connect, and Google Cloud trusts that assertion directly.

The setup has three parts. First, create a workforce identity pool at the organization level — a container representing a set of external identities. Second, add a workforce pool provider to it, configured with your IdP's metadata and attribute mappings that translate IdP claims (like group membership) into Google Cloud attributes you can reference in IAM bindings. Third, grant IAM roles to principals from the pool, using identifiers such as principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/GROUP. Federated users then sign in through a dedicated federated Console URL or configure gcloud for workforce federation.

Choosing between the approaches is a classic exam decision:

• Sync into Cloud Identity (GCDS or provisioning) when users need full Google Accounts — for Google Workspace apps, or the broadest product compatibility.
• Workforce Identity Federation when the organization wants no duplicate account lifecycle to manage and users only need Google Cloud access. Identities live solely in the external IdP; deactivating someone there removes their access.

Do not confuse this with Workload Identity Federation, which does the same trick for applications and CI pipelines instead of humans — that one belongs to the service-account domain of the exam.

Every Google Cloud service is exposed through an API that is disabled by default in a new project — you must enable it before the service will accept requests. Enable through the Console's APIs and Services page or with gcloud: gcloud services enable compute.googleapis.com. List what is already on with gcloud services list --enabled, and disable with gcloud services disable. Enabling an API requires the serviceusage.services.enable permission, and some enablements automatically create Google-managed service agents in the project. If a deployment fails with an error saying an API "has not been used in project… or it is disabled," the fix is enabling the API — a frequent exam distractor dressed up as a permissions problem.

Quotas cap how much of each resource a project may consume. They come in two kinds: rate quotas that reset over a time window (API requests per minute) and allocation quotas that cap concurrent resources (CPUs per region, VPC networks per project, static IPs). Quotas are per project, and many are also per region.

View and manage quotas on the Cloud Quotas page (IAM and Admin, then Quotas) or with gcloud services quota commands. When a quota blocks you — say a managed instance group cannot scale because the regional CPU allocation is exhausted — you request an increase from that page. Increases are reviewed by Google, are not guaranteed, and can take time to approve, so the exam expects you to plan ahead rather than request mid-incident. Requesting increases requires quota-admin permissions, and raising a quota never raises your bill by itself — you pay only for what you actually consume.

Google Cloud Observability — Cloud Monitoring, Cloud Logging, and companion tools like Cloud Trace and Cloud Profiler — is provisioned per project, and its baseline works with no setup: platform metrics for supported services flow into Monitoring automatically, and platform logs land in Logging's _Default log bucket, with admin activity audit logs kept in the non-configurable _Required bucket.

The setup tasks the exam cares about sit on top of that baseline:

• Metrics scopes for multi-project monitoring. A Monitoring metrics scope defaults to seeing only its own project. To build one dashboard across many projects, add those projects to a central scoping project's metrics scope — a standard pattern for ops teams overseeing separate prod projects per service.
• The Ops Agent on Compute Engine VMs. Without it, a VM reports only hypervisor-visible metrics (CPU, disk and network throughput). Installing the Ops Agent adds in-guest telemetry — memory utilization, disk space, application logs — so any question about missing memory metrics or in-VM application logs is answered by "install the Ops Agent."
• Log routing. Log sinks route entries to destinations such as BigQuery for analysis, Cloud Storage for archival, or Pub/Sub for streaming to external systems; exclusion filters drop noise to control cost.

Provisioning also includes deciding retention on log buckets and creating notification channels (email, chat, PagerDuty-style integrations) so that alerting policies created later have somewhere to send incidents. At setup time your job is wiring: agents installed, scopes arranged, sinks pointed at the right destinations.

Initial network setup means deciding what VPC networks your projects use. New projects ship with a default auto mode VPC — one subnet pre-created in every region with fixed IP ranges and permissive default firewall rules. Convenient for experiments, wrong for production: the exam-preferred practice is to delete or ignore it and create a custom mode VPC (gcloud compute networks create prod-vpc --subnet-mode=custom), then add subnets only in the regions you need with CIDR ranges that will not collide with on-premises or peered networks. For multi-project setups, a Shared VPC lets a host project own the network while service projects attach workloads to it — centralizing network administration while keeping workloads isolated in their own projects.

Verify product availability before you commit to a region. Not every product, machine type, or GPU exists in every region or zone. List locations with gcloud compute regions list and gcloud compute zones list, check a specific resource with commands like gcloud compute machine-types list --zones=europe-west2-a, and consult Google's per-product locations pages. A scenario that requires a specific region for data-residency plus a product missing there is testing exactly this verification step.

Finally, Cloud Asset Inventory gives you visibility over everything the hierarchy contains: search assets and IAM policies across the organization (gcloud asset search-all-resources), export full snapshots to BigQuery or Cloud Storage, and review up to five weeks of change history. Gemini Cloud Assist layers AI on top — you can ask it in the Console to analyze and summarize your resources, investigate configuration questions in natural language, and surface optimization suggestions, which is how the current exam guide expects resource analysis to be done.