Cloud IAM Study Notes

Cloud IAM is Google Cloud's identity and access management system that controls who can do what on which resource. Every API call is checked against an IAM policy before it is allowed, making IAM the foundation of security for all Google Cloud services.

Key facts

• An IAM policy is a collection of bindings, where each binding pairs one or more members with a single role and optionally a condition.
• IAM policies are set on resources in the resource hierarchy: organization, folder, project, and individual resources such as buckets or instances.
• Policy inheritance flows downward, so a binding granted at the organization level applies to all folders, projects, and resources below it.
• There are three role types: basic roles (Owner, Editor, Viewer), predefined roles maintained by Google for specific services, and custom roles you define yourself.
• Members can be a Google Account, a service account, a Google Group, a Google Workspace domain, a Cloud Identity domain, or special identifiers such as allUsers and allAuthenticatedUsers.
• IAM denies take precedence in evaluation when using deny policies, which can block access even if an allow policy would otherwise grant it.
• Predefined roles follow a naming pattern such as roles/storage.objectViewer, where the service and permission level are visible in the name.
• IAM Conditions use Common Expression Language (CEL) to grant access only when attributes match, for example resource type, name prefix, or request time.
• By default, the user who creates a project becomes its initial Owner, and no other principal has access until a policy grants it.

What the exam expects you to know

• Apply the principle of least privilege by choosing the narrowest predefined role that still lets a user complete their job.
• Explain policy inheritance and predict effective permissions when bindings exist at both folder and project levels.
• Distinguish basic roles from predefined roles and know why basic roles are discouraged in production environments.
• Use Google Groups as members instead of individual accounts so access changes follow group membership automatically.
• Recognize when a custom role is needed because no predefined role matches the exact permission set required.
• Understand IAM Conditions for time-bound or resource-scoped access, such as expiring access after a set date.

Cloud IAM vs Organization Policy: when to use which

Use IAM when the question is about who can perform an action: it grants or denies permissions to specific identities on specific resources. Use Organization Policy when the question is about what is allowed at all in the organization, regardless of who asks, such as requiring OS Login or blocking public IPs. IAM answers who and what role, while Organization Policy sets guardrails that even administrators cannot override with a role grant. On the exam, if a user has a role but is still blocked by a constraint, the answer involves Organization Policy, not a missing IAM binding. See also the Organization Policy notes.

Useful gcloud commands

gcloud projects add-iam-policy-binding PROJECT_ID --member=user:alice@example.com --role=roles/storage.objectViewer
gcloud projects get-iam-policy PROJECT_ID
gcloud projects remove-iam-policy-binding PROJECT_ID --member=user:alice@example.com --role=roles/storage.objectViewer
gcloud iam roles describe roles/storage.objectViewer

Common exam traps

• Granting Owner or Editor at the project level for convenience violates least privilege and is almost never the correct exam answer when a narrower service role exists.
• Removing a binding at a lower level does not remove access inherited from a parent folder or organization, because allow policies are additive.
• allUsers means anyone on the internet, including unauthenticated users, while allAuthenticatedUsers means anyone signed in with any Google Account.
• Basic roles include hundreds of permissions across all services, so choosing Viewer, Editor, or Owner for a single-service task is a common wrong answer.

Frequently asked questions

What is the difference between a role and a policy in IAM?

A role is a named collection of permissions, such as roles/storage.objectViewer, and it has no effect until it is bound to a member. A policy is the object attached to a resource that contains bindings linking members to roles. You grant access by editing the policy, not by editing the role itself.

Can IAM explicitly deny access?

Yes, IAM deny policies let you block specific principals from using specific permissions even if an allow policy grants them. Deny policies are evaluated before allow policies. They are useful for guardrails, such as preventing most users from deleting protected resources, with narrow exceptions for a break-glass administrator group.

Why use groups instead of individual members in bindings?

Binding a Google Group means you manage access by changing group membership rather than editing IAM policies in many projects. Joining or leaving the group updates access everywhere at once. This reduces errors, simplifies auditing, and is the approach Google recommends for teams and for exam scenarios about onboarding staff.

Study aid disclaimer: Cloud Cert Notes is an independent educational study aid. It is not affiliated with, endorsed by, or sponsored by Google, Microsoft, Amazon, Oracle, or Alibaba. Google Cloud, Associate Cloud Engineer, and Cloud Digital Leader are trademarks of Google LLC; all other certification names and product names are trademarks of their respective owners. Always confirm service details against the official provider documentation before sitting an exam.