Organization (Google Cloud)

The top-level node in the Google Cloud resource hierarchy, representing a company or domain managed by Cloud Identity or Google Workspace. It owns all folders and projects beneath it and is where org-wide policies and IAM can be applied.

An optional grouping node under an organization used to organize projects (and other folders) by department, environment, region, or other logical structure. IAM and organization policies attached to a folder are inherited by its child projects and resources.

The main container for Google Cloud resources, APIs, and services. Projects are the primary boundary for billing, quotas, and many IAM policies. Every resource such as a VM or bucket belongs to exactly one project.

Legacy, broad roles (Owner, Editor, Viewer) that apply at the project or higher level and grant large sets of permissions across many services. Simple but not aligned with least-privilege for production use.

A collection of users and/or service accounts identified by a single email address. IAM roles are granted to the group, and membership is managed centrally, simplifying access management.

An optional grouping node under an organization used to organize projects (and other folders) by department, environment, region, or other logical structure. IAM and organization policies attached to a folder are inherited by its child projects and resources.

The main container for Google Cloud resources, APIs, and services. Projects are the primary boundary for billing, quotas, and many IAM policies. Every resource such as a VM or bucket belongs to exactly one project.

Projects, Resource Hierarchy, and IAM Foundations — Google Cloud Associate Cloud Engineer: Complete Exam-Ready Masterclass

Orientation: Why Projects and IAM Matter for ACE

Why This Module Matters

As an Associate Cloud Engineer, you will work with multiple projects and secure them using IAM almost every day. These topics are core to setting up and managing Google Cloud environments.

What You Will Learn

You will learn how organizations, folders, and projects form the resource hierarchy, how project lifecycle works, and how IAM ties identities and roles to specific resources.

Exam and Real-World Relevance

These concepts map directly to high-weight exam domains like setting up a cloud solution environment and configuring access and security, and are essential for real production environments.

Google Cloud Resource Hierarchy: Organizations, Folders, Projects

Hierarchy Overview

Google Cloud organizes everything in a hierarchy: Organization → Folders → Projects → Resources. This structure controls how policies, IAM, and billing apply.

Organization Node

The Organization represents your company. It appears when you use Cloud Identity or Google Workspace and lets you apply org-wide policies and IAM that all child folders and projects inherit.

Folders

Folders are optional grouping layers under the organization. You can group by department, environment, or region, and attach IAM or policies that apply to all projects inside.

Projects and Inheritance

Projects are where resources live and where billing and many quotas are tracked. IAM and org policies inherit from org and folders down into projects and then to individual resources.

Designing a Resource Hierarchy for a Sample Company

Acme Retail Scenario

Acme Retail has Sales, Analytics, and IT departments, and uses Dev, Test, and Prod environments. They need a clear structure to separate access and policies.

Proposed Hierarchy

Under the acme-retail.com Organization, create Prod and Non-Prod folders. Inside each, create Sales and Analytics folders, and then projects like sales-crm-prod or analytics-warehouse-dev.

Benefits of This Design

Security can get org-wide read-only, SREs can get access only to the Prod folder, and Sales engineers can be limited to Sales folders and projects without touching Analytics.

Exam Insight

If a scenario asks to apply policies to all Prod projects but not Dev/Test, think folder-level policies. For isolating business units, folders are also a strong exam-friendly answer.

Project Creation and Lifecycle

Creating Projects

Create projects in the Console via Manage resources → Create project, or with gcloud projects create. Set a unique project ID, a human-friendly name, and link to a billing account.

Placement in Hierarchy

When you create a project, you can place it under a folder or directly under the organization. This placement controls which IAM and org policies it inherits.

Lifecycle Stages

Projects move from Active to Marked for deletion when you shut them down, then to Deleted after a retention period. During Marked for deletion, you can still restore them.

Exam Traps

Deleting a project deletes its resources and you cannot reuse its project ID after final deletion. For decommissioning questions, think about backups before deleting a project.

IAM Foundations: Identities, Roles, and Resources

IAM in One Sentence

Identity and Access Management (IAM) lets you manage access control by defining who (identity) has what access (role) for which resource.

The IAM Binding Model

IAM works as bindings: a principal (like user or group) gets a role on a specific resource (org, folder, project, or specific resource), which grants a set of permissions.

Identity Types

Common identities are Cloud Identity users, groups, and service accounts. A service account is a special account used by an application or workload, not a person.

Least Privilege and Inheritance

IAM policies attach to resources and inherit down the hierarchy. For security, grant roles at the lowest level that still meets the requirement.

Users, Groups, Cloud Identity, and Service Accounts

Cloud Identity Users

Cloud Identity manages human user accounts like alice@company.com. These users sign in with passwords and MFA and represent real employees.

Groups for Access Management

Groups like analytics-admins@company.com bundle many users. You assign IAM roles to the group and manage membership separately for easier scale.

Service Accounts Defined

A service account is a special kind of account used by an application or compute workload, not a person, to make authorized API calls and access Google Cloud resources.

Exam Patterns

Use service accounts when apps need access without user credentials. Use groups when you need easy, scalable access changes as people join or leave teams.

Basic, Predefined, and Custom Roles

Role Categories

Google Cloud roles come in three main types: basic (owner, editor, viewer), predefined (service-specific), and custom (you define the permissions).

Basic Roles

Basic roles like roles/owner, roles/editor, and roles/viewer are very broad and apply at the project or higher level. They are usually too coarse for production.

Predefined Roles

Predefined roles are curated by Google per service, such as roles/storage.objectViewer. They are designed to be granular and follow least privilege.

Custom Roles and Exam Use

Custom roles are built by you at org or project level for special combinations of permissions. On the exam, prefer predefined roles unless a scenario clearly demands a custom role.

Thought Exercise: Choosing the Right Role Type

Work through these scenarios and decide which role type (basic, predefined, or custom) fits best. There is no auto‑grading here; this is for you to reason like an exam item writer.

Scenario A: Small Test Project

You are spinning up a short‑lived test project for a hackathon. Three developers need full control over everything in the project, and security risk is low.
Which role type would you use for them at the project level, and why?

Scenario B: Storage‑Only Access

A data science intern needs to read objects from a specific Cloud Storage bucket in a production project, but must not modify anything.
Which role type and example role would you choose? At which resource level (project vs bucket)?

Scenario C: Compliance‑Driven Permissions

Your company’s compliance team requires an auditor role that can: list all Compute Engine instances and view their configurations, but cannot start/stop, create, or delete instances, and must not see any other resources.
Would you look for a predefined role or design a custom role? Explain your reasoning.

Scenario D: Evolving Service Permissions

A central platform team manages Pub/Sub across dozens of projects. You want to ensure they always have the minimal necessary permissions, even as Google adds new Pub/Sub features.
Would you rely on a predefined role that Google updates, or manage a custom role yourself?

Write down your answers in brief bullet points. Then, compare your reasoning to these hints:

If the requirement is “quick and simple, low risk”, basic roles may be acceptable.
If the requirement is “specific to one service, and Google likely has a role for it”, start with predefined.
If the requirement is “very specific, cross‑cutting, or compliance‑driven”, custom roles are strong candidates.

Quiz 1: Resource Hierarchy and IAM Basics

Check your understanding of the resource hierarchy and IAM fundamentals.

Your company wants to apply a policy that restricts the regions where resources can be created, but only for production environments across multiple projects. Where is the BEST place to attach this policy?

On each individual resource (VMs, buckets) in every production project
On the Organization node so it applies to all projects, including non-production
On a dedicated 'Prod' folder that contains all production projects
On each production project separately, one by one

Show Answer

Answer: C) On a dedicated 'Prod' folder that contains all production projects

Attaching the policy to a dedicated 'Prod' folder that contains all production projects lets you apply the restriction once and have it inherited by all prod projects, without affecting non-production. Attaching at the Organization level would also restrict non-prod; per-project or per-resource configuration is harder to manage and more error-prone.

Quiz 2: Roles and Identities

Test your understanding of roles and identity types.

A web application running on Cloud Run needs to write logs to a BigQuery dataset. According to best practice, which identity should be granted the necessary IAM role, and what type of role is MOST appropriate?

Grant a basic Editor role on the project to the developer's user account
Grant a predefined BigQuery data editor role to a service account used by the Cloud Run service
Grant a custom role with all BigQuery permissions to a Google Group of developers
Grant the Owner role on the project to the Cloud Run service account

Show Answer

Answer: B) Grant a predefined BigQuery data editor role to a service account used by the Cloud Run service

Applications should use service accounts, not human user accounts. You should grant a predefined BigQuery role with the minimal required permissions (for example, data editor or job user) to the Cloud Run service's service account. Basic roles (Editor, Owner) and overly broad custom roles violate least-privilege.

Key Term Flashcards: Projects and IAM

Use these flashcards to reinforce the core vocabulary for projects, resource hierarchy, and IAM.

Organization (Google Cloud): The top-level node in the Google Cloud resource hierarchy, representing a company or domain managed by Cloud Identity or Google Workspace. It owns all folders and projects beneath it and is where org-wide policies and IAM can be applied.
Folder: An optional grouping node under an organization used to organize projects (and other folders) by department, environment, region, or other logical structure. IAM and organization policies attached to a folder are inherited by its child projects and resources.
Project: The main container for Google Cloud resources, APIs, and services. Projects are the primary boundary for billing, quotas, and many IAM policies. Every resource such as a VM or bucket belongs to exactly one project.
Identity and Access Management (IAM): Identity and Access Management (IAM) lets you manage access control by defining who (identity) has what access (role) for which resource.
Basic roles: Legacy, broad roles (Owner, Editor, Viewer) that apply at the project or higher level and grant large sets of permissions across many services. Simple but not aligned with least-privilege for production use.
Predefined roles: Service-specific roles curated by Google Cloud that group permissions for common tasks (for example, roles/storage.objectViewer). They are more granular than basic roles and are the recommended default for most use cases.
Custom roles: Organization- or project-level roles defined by customers, containing a chosen set of permissions for specialized needs or compliance requirements. They provide fine control but must be maintained by the customer.
Cloud Identity user: An individual user account managed by Cloud Identity or Google Workspace, representing a real person who signs in to access Google Cloud resources.
Group (IAM): A collection of users and/or service accounts identified by a single email address. IAM roles are granted to the group, and membership is managed centrally, simplifying access management.
Service account: A service account is a special kind of account used by an application or compute workload, not a person, to make authorized API calls and access Google Cloud resources.

Hands-On Walkthrough: Creating a Project and Granting IAM

Step 1: Place the Project

Decide where the project belongs, for example under a Prod/Analytics folder. This determines which IAM and org policies it will inherit.

Step 2: Create and Link Billing

Use gcloud projects create with a folder ID, then gcloud beta billing projects link to attach a billing account so the project can use billable services.

Step 3: Grant Access to a Group

Grant a predefined BigQuery viewer role at the project level to a group like analytics-users@company.com, so analysts can read data.

Step 4: Grant Access to a Service Account

Grant a predefined BigQuery editor role to a service account used by an ETL job, so the workload can write data while humans stay read-only.

Apply It: Mini Design Challenge

Design a simple resource hierarchy and IAM plan for this scenario, then compare to the guidance.

Scenario:

Company: `QuickBank` (financial startup).
Two environments: `Sandbox` (experiments) and `Prod`.
Teams: `Payments`, `Fraud`, and `Platform`.
Requirements:
Sandbox must be isolated from Prod.
Payments team must not see Fraud projects and vice versa.
Platform team can view and troubleshoot all Prod services but cannot change IAM.
All applications should use service accounts, not user credentials.

Your task:

Sketch the resource hierarchy (Organization, folders, projects) in text.
Decide where to place IAM for:

Payments engineers
Fraud engineers
Platform team

Identify at least one group and one service account you would create, and what predefined roles you would give them.

Sample reasoning to compare with:

Create folders `Sandbox` and `Prod` under the Organization.
Under each, create `Payments` and `Fraud` folders, then projects per service.
Grant Payments engineers roles at the `Payments` folder level; Fraud engineers at the `Fraud` folder level.
Grant Platform team a read‑only or troubleshooting role at the `Prod` folder level.
Use groups like `payments-dev@quickbank.com` and service accounts like `payments-api-sa@PROJECT_ID.iam.gserviceaccount.com` with appropriate predefined roles.

Key Terms

Group: A collection of users and/or service accounts identified by a single email address. IAM roles are granted to the group, and membership is managed centrally, simplifying access management.
Folder: An optional grouping node under an organization used to organize projects (and other folders) by department, environment, region, or other logical structure. IAM and organization policies attached to a folder are inherited by its child projects and resources.
Project: The main container for Google Cloud resources, APIs, and services. Projects are the primary boundary for billing, quotas, and many IAM policies. Every resource such as a VM or bucket belongs to exactly one project.
Basic roles: Legacy, broad roles (Owner, Editor, Viewer) that apply at the project or higher level and grant large sets of permissions across many services. Simple but not aligned with least-privilege for production use.
Custom roles: Organization- or project-level roles defined by customers, containing a chosen set of permissions for specialized needs or compliance requirements. They provide fine control but must be maintained by the customer.
Organization: The top-level node in the Google Cloud resource hierarchy, representing a company or domain managed by Cloud Identity or Google Workspace. It owns all folders and projects beneath it and is where org-wide policies and IAM can be applied.
Service account: A service account is a special kind of account used by an application or compute workload, not a person, to make authorized API calls and access Google Cloud resources.
Predefined roles: Service-specific roles curated by Google Cloud that group permissions for common tasks (for example, roles/storage.objectViewer). They are more granular than basic roles and are the recommended default for most use cases.
Cloud Identity user: An individual user account managed by Cloud Identity or Google Workspace, representing a real person who signs in to access Google Cloud resources.
Identity and Access Management (IAM): Identity and Access Management (IAM) lets you manage access control by defining who (identity) has what access (role) for which resource.