Managing Access with Cloud IAM

In Google Cloud, Identity and Access Management (IAM) is the framework that allows administrators to authorize who can take action on specific resources. It provides a unified view of security policy across the entire organization, ensuring that the principle of Least Privilege is maintained.

The “Security Guard” Analogy

Imagine a high-security office building. Identity is your ID badge (Who are you?). Role is your job description (What are you allowed to do? e.g., Janitor, CEO, or Guest). Resource is the specific room (The server room, the breakroom, or the executive suite). IAM is the security system that checks your badge and job title before letting you swipe into a specific room.

Detail Elaboration: The IAM Policy Binding

An IAM policy is a collection of bindings. A binding ties a Member to a Role on a specific Resource. For example, you might bind the user alice@example.com to the Storage Object Viewer role on a specific Cloud Storage bucket.

Members: Can be Google Accounts, Service Accounts, Google Groups, or Workspace/Cloud Identity domains.
Roles: A collection of permissions (e.g., resourcemanager.projects.get).
Resources: Projects, Folders, Organizations, or individual services (Buckets, Compute instances).

Core Concepts & Best Practices

Reliability: Use Google Groups for access control. If an employee leaves, removing them from the Group revokes access across all resources simultaneously.
Security (Least Privilege): Never grant “Editor” if “Viewer” suffices. Use IAM Conditions to grant temporary or conditional access based on time or resource tags.
Operational Excellence: Audit your IAM policies regularly using the IAM Policy Analyzer to find over-privileged accounts.

Comparison: IAM Role Types

Role Type	Granularity	Use Case	Risk Level
Primitive	Coarse (Owner, Editor, Viewer)	Development/Sandbox environments.	High (Too many permissions).
Predefined	Fine-grained (e.g., Pub/Sub Publisher)	Production environments (Standard).	Low (Targeted permissions).
Custom	Ultra-fine (User-defined)	Strict compliance requirements.	Medium (Requires maintenance).

Scenario-Based Learning: Decision Matrix

If the requirement is…

…to allow an application to call a GCP API: Use a Service Account.
…to grant the same permissions to a team of 10: Use a Google Group.
…to restrict access to a specific time of day: Use IAM Conditions.
…to manage permissions for multiple related projects: Apply IAM Policy at the Folder level.

Exam Tips: Golden Nuggets

Inheritance is Key: Permissions are inherited from Organization > Folder > Project > Resource. You cannot take away a permission granted at a higher level (Child policies are additive).
Service Account Identity: Service accounts are both an Identity (when they act as a resource) and a Resource (when you grant a user permission to “act as” that service account).
Avoid Primitive Roles: On the ACE exam, “Owner” or “Editor” is almost always the wrong answer for production scenarios. Look for the specific Predefined role.
The “gcloud” Command: Remember gcloud projects add-iam-policy-binding [PROJECT_ID] --member='user:[EMAIL]' --role='[ROLE]'.

The flow of authorization: A Member is bound to a Role to access a Resource.

Key Services

Cloud Identity
Service Accounts
Google Groups

Common Pitfalls

Storing SA Keys in code
Granting Owner role
Ignoring Audit Logs

Patterns

Hierarchy Inheritance
Group-based Access
Conditional IAM