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 (folders can nest), 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 comes from a Google Workspace or Cloud Identity account on a verified domain (see the next section). Folders group projects by department, team, or environment (for example finance/prod and finance/dev) and are the natural attachment point for policies and administrators that apply to a subset of the company. A common, exam-friendly design is one organization, a folder per department, and environment subfolders inside each: a department's guardrails and admins are set once on its folder, and every project created there later picks them up automatically. Separate organizations per department are the wrong answer — they split identity, billing and policy management instead of delegating it.

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 default answer to "how do I isolate two workloads?" is almost always "separate projects."

Who may create projects and manage folders

The rule behind the table: a creation role takes effect only beneath the node where it is bound, so the place you grant it is the boundary of what the holder can create. Administering folders is a separate permission set from creating projects in them, and managing a project's IAM policy is separate from using its resources — which is why Project IAM Admin, not the basic Owner role, is the least-privilege way to delegate access management.

A standalone organization is a Google Cloud organization for a company that does not use Google Workspace: you sign up for Cloud Identity on your own domain, verify that you own the domain, and the organization resource is provisioned automatically for that account. Cloud Identity has a Free edition with no per-user licence (Premium adds device and security management), whereas Workspace is licensed per user — so a company that does not use Google for email and collaboration has no reason to buy Workspace licences just to get an organization; Cloud Identity Free is enough.

The setup sequence:

1. Sign up for Cloud Identity with the company domain; the person signing up becomes the first super administrator of the Admin console.
2. Verify the domain (typically a DNS TXT record).
3. Sign in to the Google Cloud console with that account and accept the terms; the organization resource is created then (for a user who already used Google Cloud, it appears when they next create a project or billing account). Existing projects created by domain users can be migrated into it.
4. Grant Organization Administrator to an admin group, and add users — manually, synced from a directory, or with SSO to your existing identity provider.

Lock down the default grants. When an organization is created, the entire domain is granted Project Creator and Billing Account Creator on the organization node, so every user can create projects and billing accounts. Remove that domain binding at the organization node (adding a narrower grant for the platform team does not take anything away, because allow policies are additive), then grant those roles only to the groups that need them.

Workforce Identity Federation cannot replace this first step: a workforce identity pool is created inside an organization, so you need the Cloud Identity (or Workspace) account and its organization before you can federate anyone. The order is always the same: an organization from a Cloud Identity or Workspace account on the verified domain first, then sign-in through your existing identity provider — via SSO for those accounts, or a workforce pool added later. A pool on its own has nowhere to live.

IAM allow 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 allow policy on a resource is the union of the policy set on it and every policy inherited from above. Allow policies only add: granting someone Viewer on a project does not reduce the Editor role they hold on the organization. The only way to block an inherited grant without removing it at its source is an IAM deny policy (next section).

An allow 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, a domain, or a federated principal set. 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.

Moving a project changes what it inherits. Inheritance follows the current parent: after a project moves from one folder to another, it gets the new folder's (and its ancestors') bindings and loses the old folder's. Bindings set on the project itself move with it, and grants on the organization still apply. The same is true of organization policies, so check both before a move.

The three role types

Time-bound and attribute-based grants: IAM Conditions

An IAM Condition is a CEL expression attached to a role binding; the binding applies only while the expression is true. The usual use is temporary access: a condition such as request.time < timestamp("2026-12-31T00:00:00Z") makes a contractor's grant expire on its own, with no one having to remember to remove it. Conditions can also limit a grant to resources with a given name prefix or tag. Two limits matter: conditions cannot be used with basic roles (Owner, Editor, Viewer), so a time-bound grant must use a predefined or custom role; and not every resource type supports them.

Habits that keep this manageable: grant roles to groups, not individual users, at the lowest level of the hierarchy that covers every resource the group needs — a folder when the need spans its current and future projects, a single project when it does not.

An IAM deny policy is a set of rules that stop named principals from using named permissions, regardless of which roles they hold. Deny policies attach to an organization, folder or project, are inherited by everything beneath, and are evaluated before allow policies: if a deny rule matches, the request fails even when an allow binding grants the permission. Creating and managing them needs the Deny Admin role (roles/iam.denyAdmin).

Each deny rule lists:

• Denied principals — users, groups, service accounts, or principal sets (for example all principals).
• Denied permissions — written in the service's FQDN form, for example cloudresourcemanager.googleapis.com/projects.delete; some permission groups are supported.
• Exception principals (optional) — principals the rule does not apply to. Exceptions are set per rule, so exempting one person from a group-wide rule means adding them to that rule's exceptions, not granting them another role.
• An optional denial condition, for example to deny only on resources carrying a certain tag.

Because deny rules sit on top of allow policies rather than replacing them, they solve two kinds of problem: carving a single resource out of a broad inherited grant without touching the grant itself, and setting an ancestor-level prohibition that every existing and future descendant inherits, with a small exempt set of principals named in the rule.

A lien is a guard against accidental deletion of a single project; a deny policy is the organization-wide, owner-proof control.

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 sets a constraint, and constraints come in two flavors: boolean constraints that are enforced or not (for example constraints/iam.disableServiceAccountKeyCreation or constraints/compute.skipDefaultNetworkCreation) and list constraints that allow or deny specific values (for example constraints/gcp.resourceLocations to restrict where resources may be created, or constraints/compute.vmExternalIpAccess to control which VMs may have external IPs). You can also write custom constraints on specific resource fields of supported services.

Organization policies are not a substitute for quotas or budgets either: a quota caps how much a project can consume, a budget alerts on spend, and an org policy decides which configurations are allowed at all. The underlying rule: a control that must bind even project Owners cannot be an IAM allow grant (Owners can change those), and coverage of projects that do not exist yet requires attaching the control to an ancestor — the organization or a folder.

How organization policy inheritance works

A node with no policy of its own inherits its parent's effective policy. A node that sets its own policy chooses how it relates to the parent:

The practical difference: merging keeps the child connected to its parent, so values the organization adds or removes later still reach it; replacing freezes the child on its own list and cuts it off from every later change above. Choose merge when a node needs extra values on top of the company-wide list, and replace only when it must deliberately diverge. This is the key contrast with IAM: allow-policy inheritance is strictly additive, whereas a lower node can replace an inherited organization policy.

Two behaviors to remember. Policies are not retroactive: enforcing a constraint blocks new non-compliant actions but does not delete or change resources that already violate it. And you can test before enforcing: a dry-run policy (supported for custom constraints, managed constraints and some legacy managed constraints) blocks nothing but writes would-be violations to the audit logs with protoPayload.metadata.dryRunResult="DENIED", giving you evidence of which teams would be affected; the Policy Simulator for organization policies previews a change against the resources that already exist. Setting policies needs the Organization Policy Administrator role (roles/orgpolicy.policyAdmin), granted at the organization.

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 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 administrators.

Manual management means creating users and groups directly in the Admin console — one at a time, or many at once with a CSV bulk upload of users. It suits small teams but drifts out of date as people join and leave.

Automated management keeps Cloud Identity in step with an existing source of truth. Two separate decisions are involved, and exam scenarios often need both:

GCDS is a tool you run on a server in your network on a schedule. It performs a one-way sync from Active Directory or another LDAP directory into Cloud Identity, with no custom code. The directory stays authoritative: GCDS never writes back, and with its default deletion rules a change made directly to a synced user or group in the Admin console or through the Directory API is overwritten on the next run. To add someone to a synced group, add them in Active Directory.

SSO and provisioning are complementary: SSO with a third-party IdP still requires a Cloud Identity user account for each person; it only changes where they authenticate. If you want no Google accounts at all, that is Workforce Identity Federation (next section).

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

Workforce Identity Federation lets your employees access Google Cloud using their existing external identity provider without creating or syncing Cloud Identity user accounts for them. 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 in your organization — a container for a set of external identities (the organization must already exist). Second, add a workforce pool provider configured with your IdP's metadata and:

• Attribute mappings that translate IdP claims into Google attributes: google.subject (required, the user's identity), google.groups (group membership, for example from assertion.groups), and custom attribute.NAME values.
• An optional attribute condition — a CEL expression on the mapped attributes that decides which identities may authenticate through the provider at all (for example only one department). It filters sign-in; it is not an IAM Condition on a role binding.

Third, grant IAM roles to principals from the pool:

Federated users sign in through the federated console URL or configure gcloud for workforce federation.

Choosing between the approaches is a classic exam decision:

• Cloud Identity accounts (synced or provisioned, optionally with SSO) when users need Google accounts — for Workspace apps, the broadest product compatibility, or because you are creating the organization itself.
• Workforce Identity Federation when an organization already exists and wants no duplicate account lifecycle; identities live only in the external IdP, and 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 part of the exam.

Every Google Cloud service is exposed through an API that must be enabled in each project before the service will accept requests; most are disabled in a new project. Enable through the console's APIs and Services page or with gcloud services enable compute.googleapis.com. gcloud services list --enabled and --available only report state, and gcloud services disable turns an API off. Enabling needs the serviceusage.services.enable permission.

Diagnosing a disabled API. A request to a disabled API fails with HTTP 403 and the reason SERVICE_DISABLED (the message says the API "has not been used in project… or it is disabled"). It looks like a permissions problem but is not: the fix is gcloud services enable for that API, not a new IAM role.

What else a new project needs. Billable APIs such as Compute Engine can only be enabled once the project is linked to an active Cloud Billing account (billing setup is covered in the billing lesson). Enabling the Compute Engine API also creates things for you: the default VPC network (an auto mode network with permissive default firewall rules) unless the compute.skipDefaultNetworkCreation constraint is enforced, and the Compute Engine default service account (PROJECT_NUMBER-compute@developer.gserviceaccount.com). Some enablements also create Google-managed service agents.

Quotas

Quotas cap how much of each resource a project may consume. Rate quotas reset over a time window (API requests per minute); allocation quotas cap concurrent resources (CPUs per region, VPC networks per project, static IPs). Quotas are per project, and many are also per region — and several resources have both a regional and a global quota, each checked independently:

Read the quota named in a QUOTA_EXCEEDED error: if it is the regional CPUs quota, raising CPUS_ALL_REGIONS does not help, and moving to another region is not an option when data residency fixes the region. A project's first standard GPUs need both the regional per-model quota and the global GPUs quota raised; raising the preemptible quota does nothing for standard VMs.

View quotas on the Cloud Quotas page (IAM and Admin, then Quotas) or with gcloud quota commands, and request an increase there. Requesting an increase needs quota-admin permissions (for example the Quota Administrator role, which includes serviceusage.quotas.update). Increases are reviewed by Google, are not guaranteed, and can take time, so request them ahead of a launch rather than mid-incident. Keep three neighbours straight: a quota limits capacity; reservations hold zonal capacity and consume quota just like running VMs; a budget only alerts on spend and neither caps usage nor changes any quota. Raising a quota never raises your bill by itself — you pay only for what you use.

Google Cloud Observability — Cloud Monitoring, Cloud Logging, and companion tools like Cloud Trace and Cloud Profiler — works per project 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:

• 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, and log files written inside the guest — so missing memory metrics or missing application log files are fixed by installing it.
• Metrics scopes for multi-project monitoring. A project's metrics scope starts with only itself. To build dashboards and alerting policies across several projects, designate a scoping project whose metrics scope includes each monitored project; its charts and alerts can then read their metrics.
• Central log storage. A log sink routes entries to a destination — a log bucket (possibly in another project), BigQuery, Cloud Storage or Pub/Sub — and exclusion filters drop noise. To collect logs from every current and future project in a folder or organization, create an aggregated sink on that folder or organization with child resources included, and point it at a user-defined log bucket whose retention period you choose to match your requirement. Grant the sink's writer identity permission to write to the destination (for a log bucket in another project, Logs Bucket Writer).

Provisioning also includes creating notification channels (email, chat, paging integrations) so that alerting policies have somewhere to send incidents. At setup time your job is wiring: agents installed, scopes arranged, sinks pointed at the right destinations with the right retention.

Initial network setup means deciding which VPC networks your projects use. A VPC network is global; its subnets are regional.

Create one with gcloud compute networks create prod-vpc --subnet-mode=custom and then add subnets. An auto mode network can be converted to custom mode (one way only); its existing subnets are kept and you manage them from then on. The default network that comes with the Compute Engine API is auto mode with broad default firewall rules (SSH, RDP, ICMP from anywhere). To stop it appearing in every new project, enforce the compute.skipDefaultNetworkCreation organization policy on the organization or folder.

Shared VPC lets a host project own the network while service projects run workloads on it. A Shared VPC Admin enables the host project and attaches service projects. Service project developers then need Compute Network User (roles/compute.networkUser) in the host project — on the whole host project, or on individual subnets to limit which subnets they may use. A role in the service project such as Compute Instance Admin lets them create VMs there but does not grant use of host-project subnets.

Verify product availability before you commit to a location

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 machine type with gcloud compute machine-types list --zones=europe-west2-a; check GPU models with gcloud compute accelerator-types list, filtered to the zones you care about with --filter; and consult each product's locations page. A scenario that fixes a region for data residency and needs a specific product or GPU there is testing this check.

Location scope also decides what survives a zone outage:

Cloud Asset Inventory is the managed metadata inventory of your resources and policies across a project, folder or organization. It records resources together with their IAM policies, organization policies and other content types, and offers:

• Search — gcloud asset search-all-resources and search-all-iam-policies across a whole organization.
• Export — a point-in-time snapshot of all assets to BigQuery or Cloud Storage for analysis.
• Asset history — what an asset or its IAM policy looked like at any point in the last 35 days.
• Real-time feeds — publish each change to chosen asset types or content types (for example firewall rules, IAM policies) to a Pub/Sub topic, which a Cloud Run service or function can consume.

Two scoping details matter. A feed created on the organization or a folder covers projects created later; feeds created on each existing project miss every new project. And an export is a snapshot, so a Cloud Storage notification on the export bucket announces a new export file, not individual changes — use a feed for change notifications.

Know the neighbours: Cloud Audit Logs record who called which API (the change events), Cloud Asset Inventory records what the resources and policies look like now and over the last 35 days, and IAM recommendations (role recommender) suggest removing permissions a principal has not used.

Gemini Cloud Assist is the AI assistant inside the Google Cloud console: you ask in natural language about your own environment — which VMs have external IPs, what a failing deployment's errors mean, how resources are configured — and it analyzes the resources and logs to answer and suggest fixes. It is not Gemini Code Assist, the coding assistant for IDEs and the Cloud Shell Editor that helps write and explain code.