Identity and Access Management (IAM)

What Is Identity and Access Management (IAM)?

Identity and Access Management (IAM) is the Google Cloud service that decides who can do what on which resource. For the Cloud Digital Leader (CDL) exam, IAM is the cornerstone of cloud security — it is the digital "lock and key" system that protects every project, every Cloud Storage bucket, every BigQuery dataset, and every Compute Engine virtual machine in your organization. Without IAM, Google Cloud would be a wide-open warehouse where anyone could take anything. With IAM, every door has a guard, every guard checks an ID, and every ID is tied to a precise list of permitted actions.

The CDL exam does not ask you to write gcloud commands or YAML role definitions. Instead, it tests whether you understand the three pillars of IAM as a business leader would discuss them. Those three pillars are the principal (the "who"), the role (the "what"), and the resource (the "which"). Together, the three pillars form a simple sentence: "Allow this principal to perform this role on this resource." That sentence is the heart of every IAM policy in Google Cloud.

IAM also enforces a guiding philosophy known as the principle of least privilege. This principle states that any person, application, or workload should only be granted the minimum permissions necessary to do its job — nothing more. Granting a developer the Owner role to a production project "just in case they need it" is the classic violation of least privilege, and it is the kind of mistake that leads to data breaches, accidental deletions, and audit failures. IAM is designed to make least privilege easy to implement and easy to audit.

The Three Pillars: Who, What, and Which

Every IAM decision in Google Cloud boils down to answering three questions. CDL candidates should be able to recite this sentence in their sleep: "Who can do what on which resource?"

The "Who" — Principals (Identities)

A principal is the identity that is requesting access to a Google Cloud resource. Principals come in several flavors:

• Google Account — an individual human user, identified by an email address like [email protected].
• Google Group — a named collection of users and other groups, identified by a group email like [email protected]. Groups are the recommended way to manage access at scale.
• Service Account — a non-human identity used by applications, virtual machines, and automated workloads. A service account is identified by an email such as [email protected].
• Google Workspace or Cloud Identity domain — an entire company's domain, granting access to every account within it.
• allAuthenticatedUsers / allUsers — special principals representing "anyone signed into Google" or "anyone on the internet." These are dangerous and rarely appropriate.

The "What" — Roles and Permissions

A role is a named bundle of permissions. Permissions are the atomic units of access in IAM — they look like storage.objects.get or bigquery.tables.create and they describe a single action on a single resource type. You never grant individual permissions directly to a principal; you grant roles, which are pre-packaged collections of related permissions.

Google Cloud offers three categories of roles:

1. Primitive (Basic) roles — Owner, Editor, and Viewer. These are legacy roles that existed before fine-grained IAM. They are extremely broad.
2. Predefined roles — service-specific roles like roles/storage.objectViewer or roles/bigquery.dataEditor. Google curates and maintains these.
3. Custom roles — roles you define yourself by hand-picking specific permissions for unusual or highly regulated workflows.

The "Which" — Resources and the Hierarchy

A resource is anything in Google Cloud you can act upon — a project, a folder, a storage bucket, a virtual machine, a BigQuery dataset, a Pub/Sub topic. Resources live in a hierarchy that flows from broad to specific: Organization → Folder → Project → Resource. Where in this hierarchy you attach an IAM policy determines how widely it applies.

白話文解釋（Plain English Explanation）

IAM can feel abstract because permissions and policies are invisible — there is no physical lock you can touch. But IAM behaves a lot like access control systems we already use in the physical world. The three analogies below each highlight a different face of IAM.

Analogy 1 — The Office Building Access Card (Principals, Roles, and Resources)

Imagine you work in a 30-floor office tower in Taipei. On your first day, the security desk hands you an access card. The card is your identity — it represents you, the principal. Engraved on the back of the card (digitally, in the building's system) is a list of permissions: "Can enter floors 5, 6, and 7. Can use the gym in the basement. Cannot enter the executive floor on 30."

This list of permissions is your role. The CEO has a different role — her card opens every door, including the rooftop helipad. The cleaning staff have yet another role — their cards open the janitor closets on every floor but cannot open the secure server room. Roles are bundles of permissions, just like Google Cloud's roles/storage.objectViewer bundles storage.objects.get and storage.objects.list.

The building itself, the floors, and the individual rooms are the resources. The lobby is like the organization node — everyone passes through it. The floors are like folders — you might rent out floor 10 to one company and floor 12 to another. The rooms on each floor are like projects, and the desks inside the rooms are like the individual buckets and virtual machines.

When a new contractor joins for a week, the security desk does not hand them the CEO's master key "just in case." They issue a temporary card that opens only the meeting room they need. That is the principle of least privilege in action. If the contractor's card is later stolen, the damage is contained to one meeting room rather than the whole building.

Analogy 2 — The Company Org Chart and Inherited Authority

Picture a Taiwanese semiconductor company's organizational chart. The CEO sits at the top. Below her are the VPs of Engineering, Sales, and Finance. Below each VP are directors, managers, and individual contributors. This is the resource hierarchy of Google Cloud in human form.

Now imagine the CEO issues a memo: "Everyone in the company can use the gym membership benefit." Because the CEO sits at the very top, that benefit flows downward to every single employee — VPs, directors, managers, interns. Nobody has to re-issue the memo at every level. This is exactly how IAM policy inheritance works. A role granted at the organization node automatically applies to every folder, every project, and every resource underneath it.

Now imagine the VP of Engineering issues a narrower memo: "Everyone in Engineering can access the lab on the 7th floor." That memo only flows down through the Engineering branch — Sales and Finance employees do not get lab access. This is the equivalent of granting roles/compute.viewer at the folder level: only projects inside that folder are affected.

The trap to watch for: policies are additive and unioned. If the CEO grants you "gym access" at the org level, and a manager later tries to "take it away" at the project level, the manager cannot remove what was granted higher up — they can only add more permissions. The CDL exam loves to test this point because it is counterintuitive to people coming from traditional file-system permissions where lower levels can override higher ones.

Analogy 3 — The Bank Vault and the Armored Truck Driver (Service Accounts)

So far the analogies have featured human employees. But in the cloud, most access happens machine-to-machine, not human-to-machine. This is where service accounts come in.

Picture a bank with a vault full of gold. Customers (humans) come to the lobby and use their personal IDs to make deposits. But the bank also hires armored truck drivers to physically move gold between branches. The truck driver is not a customer — he is a non-human identity that the bank itself created and gave a special badge to. The badge says "Allowed to enter the vault, allowed to load gold into the truck, allowed to drive between branches A and B." It does NOT say "Allowed to open customer accounts" or "Allowed to fire bank employees."

In Google Cloud, a service account is exactly that armored truck driver's badge. When a Compute Engine VM needs to write logs to Cloud Logging, it does not log in as a human. It uses a service account email like [email protected], and that service account has been granted roles/logging.logWriter — and nothing else.

The danger of a service account is the same as the danger of giving the armored truck driver a master key to every vault in every branch. If the badge is stolen (the service account key leaks onto GitHub), the thief can drain every vault — silently, automatically, at machine speed. This is why the principle of least privilege is even more important for service accounts than for humans: machines do not pause, do not ask questions, and can act 24 hours a day.

The Resource Hierarchy in Detail

The Google Cloud resource hierarchy is a tree with four levels, and understanding it is essential for the CDL exam.

Level 1 — Organization

The organization node sits at the top and represents your company. It is automatically created when you sign up for Cloud Identity or Google Workspace. All folders, projects, and resources belong to the organization. Org-level IAM policies are powerful because they apply to everything below.

Level 2 — Folder

Folders are optional grouping containers that sit between the organization and projects. A typical company might create folders for Production, Development, and Sandbox, or by business unit such as Marketing and Engineering. Folders can be nested up to 10 levels deep.

Level 3 — Project

A project is the primary unit of organization in Google Cloud. Every resource — every VM, bucket, database — must belong to exactly one project. Projects are also the boundary for billing, APIs enabled, and quotas.

Level 4 — Resource

The actual resources — Compute Engine instances, Cloud Storage buckets, BigQuery datasets, Pub/Sub topics — sit at the bottom. Some services support attaching IAM policies directly to individual resources for fine-grained control (for example, granting one user access to a single bucket without giving them access to the whole project).

Role Types: Primitive, Predefined, and Custom

The CDL exam expects you to compare the three role categories and know which to recommend in business scenarios.

Primitive (Basic) Roles

The three primitive roles — Owner, Editor, and Viewer — predate fine-grained IAM. They are extremely broad:

• Viewer (roles/viewer) — read-only access to all resources in a project.
• Editor (roles/editor) — read and write access to most resources, but cannot manage IAM or billing.
• Owner (roles/owner) — full control, including the ability to grant other people roles and to delete the project.

These roles are convenient but dangerous. An Editor on a project can modify every Cloud SQL database, every BigQuery dataset, and every Compute Engine instance in that project — even if their actual job only requires access to one bucket.

Predefined Roles

Predefined roles are curated by Google for specific services and job functions. Examples include:

• roles/storage.objectViewer — read objects in Cloud Storage buckets, nothing else.
• roles/bigquery.dataEditor — read and write BigQuery data, but cannot manage datasets or run billable queries.
• roles/compute.instanceAdmin — manage Compute Engine VMs but not networks or firewalls.
• roles/pubsub.subscriber — pull messages from Pub/Sub subscriptions only.

Predefined roles are the default recommendation for almost every scenario. They are tested, maintained, and updated by Google as services evolve.

Custom Roles

When neither primitive nor predefined roles fit your need, you can create a custom role by selecting specific permissions one at a time. Custom roles are useful for unusual workflows — for example, allowing a third-party auditor to list buckets but not read their contents — but they require ongoing maintenance. If Google adds a new permission to a service, your custom role does not automatically pick it up.

Service Accounts: Non-Human Identities

A service account is a special kind of Google account that belongs to your application or virtual machine, not to a human user. Service accounts are used whenever code needs to call a Google Cloud API — when a Cloud Run service writes to Cloud Storage, when a Compute Engine VM reads a Cloud SQL database, when a Cloud Function publishes to Pub/Sub.

Why Service Accounts Matter for the CDL

Service accounts are powerful and dangerous in equal measure. Three things make them risky:

1. They can be granted broad roles. It is tempting for a developer to grant roles/editor to a service account because "the app needs to do a lot of things." This is the most common IAM mistake in real-world Google Cloud deployments.
2. Their credentials can leak. A service account key (a JSON file) checked into a public GitHub repository can give an attacker full access to your project within minutes. Bots scan GitHub for leaked keys constantly.
3. They act at machine speed. A compromised human account might log in once and steal some data. A compromised service account can delete an entire database in seconds.

Service Account Best Practices

• Use one service account per workload. Do not share a single service account across unrelated applications.
• Avoid downloading service account keys. Use workload identity federation or attached service accounts instead.
• Rotate keys if you must use them, and never commit them to source control.
• Audit who can impersonate a service account. The roles/iam.serviceAccountUser role grants the ability to "act as" a service account, which is effectively a privilege escalation path.

The Principle of Least Privilege

The principle of least privilege (PoLP) says that every principal — every user, every group, every service account — should have only the permissions required to perform its specific tasks, and no more. This is not a Google Cloud invention; it is a foundational security principle that dates back to the 1970s. But IAM gives you the tools to actually implement it.

Why PoLP Matters

• Limits blast radius. If a developer's credentials are stolen, the attacker can only access what the developer could access.
• Prevents accidents. A junior engineer cannot accidentally delete the production database if they do not have delete permissions on it.
• Simplifies audits. Auditors can easily verify "this person could not have done that action" when permissions are tightly scoped.
• Satisfies compliance. Standards like SOC 2, ISO 27001, and HIPAA all require evidence of access control discipline.

Cloud Identity and Google Workspace

Where do the human identities in IAM come from? They come from one of two sources:

Cloud Identity

Cloud Identity is Google's standalone identity-as-a-service offering. It provides user accounts, group management, and single sign-on for organizations that do not use Google Workspace. The free tier supports a limited number of users; the paid tier (Cloud Identity Premium) adds security features like advanced device management and security investigation tools.

Google Workspace

Google Workspace (formerly G Suite) bundles Cloud Identity with productivity apps — Gmail, Google Drive, Google Docs, Google Meet, and Google Calendar. If a company already uses Google Workspace, every Workspace account is automatically a valid Google Cloud identity.

For the CDL exam, remember:

• Both Cloud Identity and Google Workspace provide the organization node in the resource hierarchy.
• Both manage users and groups that show up as principals in IAM policies.
• The choice between them is a business one: if you need email and productivity apps, choose Workspace. If you only need identity for Google Cloud, choose Cloud Identity.

Federation with External Identity Providers

Many enterprises already use Active Directory, Okta, or Microsoft Entra ID as their identity source. Google Cloud supports single sign-on (SSO) and workload identity federation so users do not need a separate Google password — they sign in with their corporate identity, and IAM still works because that identity has been mapped to a Google account.

Audit Logging and Accountability

IAM grants access, but Cloud Audit Logs record what was actually done with that access. Every API call to a Google Cloud service is logged, including the principal who made the call, the resource that was acted upon, and the result.

There are four categories of audit logs:

• Admin Activity — administrative actions like creating or deleting resources. Always enabled, cannot be turned off, free of charge.
• Data Access — read and write operations on resource data. Disabled by default for most services because the volume is high.
• System Event — automatic Google Cloud actions like maintenance events.
• Policy Denied — denied access attempts, useful for detecting attack attempts.

For the CDL exam, you do not need to memorize log retention periods or filter syntax. You only need to know that IAM defines who can do what, and Cloud Audit Logs prove what actually happened. Together they form the foundation of accountability in Google Cloud. For a deeper dive into compliance, see Compliance and Privacy.

How IAM Connects to Other CDL Topics

IAM does not exist in isolation. It is the access-control layer that underpins almost every other Google Cloud security topic.

• Data encryption — IAM controls who can read encrypted data and who holds the keys. See Data Encryption and Protection for how customer-managed encryption keys (CMEK) tie back to IAM permissions on Cloud KMS.
• Compliance — IAM provides the evidence that access is controlled, which is essential for SOC 2, HIPAA, GDPR, and ISO 27001. See Compliance and Privacy.
• Cost management — IAM also controls billing access. Only users with roles/billing.admin can change payment methods or close billing accounts.
• Cloud value proposition — strong IAM is part of what makes Google Cloud's cloud value proposition credible to security-conscious enterprises.

Common IAM Mistakes to Avoid

For the CDL exam, recognize these anti-patterns when they appear in scenarios:

1. Granting roles/owner to a service account. Service accounts should almost never be owners; they should hold narrow predefined roles.
2. Using allUsers on a Cloud Storage bucket. This makes the bucket public to the internet. Acceptable for a public website, catastrophic for a customer database.
3. Granting access to individual users instead of groups. When the user changes teams or leaves the company, you have to remember to update dozens of policies. Groups solve this.
4. Storing service account keys in source control. Use workload identity federation or attached service accounts.
5. Ignoring the IAM Recommender. Google will tell you which permissions are unused. Use that data to right-size roles.

Frequently Asked Questions

What is the difference between authentication and authorization in IAM?

Authentication answers "who are you?" — it is the process of verifying that the principal is who they claim to be, typically via a password, security key, or token. Authorization answers "what are you allowed to do?" — it is the process IAM performs after authentication to check whether the principal's roles permit the requested action. IAM is primarily an authorization system; authentication is handled by Cloud Identity, Google Workspace, or a federated identity provider.

Why are primitive roles like Owner and Editor still available if they are discouraged?

Primitive roles exist for backwards compatibility with Google Cloud projects created before fine-grained IAM was introduced. They are also useful for small sandbox or learning projects where the convenience outweighs the security risk. For any production workload, Google recommends replacing primitive roles with predefined roles scoped to the specific services in use. The CDL exam tests this preference directly.

Can I deny a permission to a specific user even if they inherit it from a higher level?

Yes, but only through IAM Deny policies, which are a separate and relatively recent feature. Standard IAM allow policies are additive — you cannot subtract a permission that was granted at a higher level. Deny policies let you explicitly block specific permissions for specific principals regardless of inherited allow policies. For the CDL exam, the key takeaway is that allow policies are unioned, and deny policies exist as an escape hatch but are not the primary tool.

What happens when an employee leaves the company?

When an employee leaves, their identity is typically suspended or deleted in Cloud Identity or Google Workspace. Once the identity is gone, all IAM bindings referencing that identity become inactive — even if the IAM policy entries still exist. Best practice is to also remove the principal from any groups they belonged to and run a cleanup of any orphaned bindings. This is one reason granting roles to groups rather than individuals is recommended: removing the person from the group revokes all their access in one step.

How does IAM handle external users from outside my organization?

External users — for example, contractors with Gmail addresses or partners from another company's domain — can be granted IAM roles directly by adding their email as a principal. However, this is risky because you do not control their authentication or device security. Cloud Identity Premium and Access Context Manager allow you to enforce conditions (such as requiring a managed device or a specific location) before external users can use granted permissions, giving you tighter control over third-party access.

Are service account keys ever safe to use?

Service account keys (JSON files) are functionally usernames and passwords that never expire by default. They are safe only when stored in a secrets manager, rotated regularly, and never committed to source control. For most workloads, Google now recommends keyless authentication mechanisms such as workload identity federation (for workloads outside Google Cloud) and attached service accounts (for workloads inside Google Cloud like Compute Engine and Cloud Run). These eliminate the long-lived key entirely.

Summary: IAM as the Foundation of Cloud Security

For the Cloud Digital Leader exam, IAM is the security topic that ties everything together. Remember the three pillars — principal (who), role (what), and resource (which) — and remember the four-level hierarchy — Organization → Folder → Project → Resource — with policies inheriting downward. Choose predefined roles over primitive ones, apply the principle of least privilege religiously to both human and service-account identities, and always pair IAM with Cloud Audit Logs to prove accountability after the fact.

A CDL who can explain these concepts in business language — "we grant the marketing team's group roles/bigquery.dataViewer at the folder level so they can read campaign data across all marketing projects, without being able to modify it" — is ready to advise stakeholders on secure cloud adoption. IAM is not just a technical tool; it is the organizational discipline that makes Google Cloud safe to use at scale.