Google Cloud IAM Role Types: ACE Study Guide
In Google Cloud, Identity and Access Management (IAM) is the gatekeeper. It defines who (identity) can do what (role) on which resource. Understanding the three types of roles is critical for the Associate Cloud Engineer exam, as many questions focus on the principle of least privilege and resource hierarchy.
The “Hotel Access” Analogy
Imagine a large hotel:
- Basic Roles: Like a master key that opens every room, the kitchen, and the safe. It’s powerful but dangerous if lost.
- Predefined Roles: Like a “Housekeeping Key” that only opens guest rooms and laundry chutes, or a “Chef Key” that only opens the kitchen.
- Custom Roles: Like a special key created specifically for a contractor that opens exactly three specific doors for two days only.
Core Concepts & Deep Dive
GCP IAM follows the Principle of Least Privilege. Always grant the minimum permissions necessary for a user to complete their job. This enhances Security and Operational Excellence by reducing the blast radius of compromised credentials.
1. Basic (Primitive) Roles
These were the original roles available in GCP. They are broad and apply to all services within a project.
- Viewer: Read-only access.
- Editor: All Viewer permissions plus modify/delete.
- Owner: All Editor permissions plus managing roles/permissions and billing.
2. Predefined Roles
Managed by Google, these roles provide granular access to specific services. For example, roles/storage.objectAdmin allows full control over GCS objects but not the buckets themselves. These are the recommended choice for most production scenarios.
3. Custom Roles
Created by the user when predefined roles are too broad. You pick specific permissions (e.g., compute.instances.start).
Note: Custom roles require maintenance; if Google adds a new permission to a service, you must manually update your custom role.
Comparison Table: IAM Role Variants
| Feature | Basic (Primitive) | Predefined | Custom |
|---|---|---|---|
| Granularity | Very Coarse (Project-wide) | Fine-grained (Service-specific) | Highly Specific (Permission-level) |
| Management | Google Managed | Google Managed | User Managed |
| Best Practice | Avoid in Production | Primary Recommendation | Use if Predefined is too broad |
| Maintenance | None | Automatic updates | Manual updates required |
Decision Matrix: If/Then Scenarios
If the requirement is to allow a user to manage only GCS objects… Then use roles/storage.objectAdmin.
If a developer needs to start/stop VMs but not delete them… Then create a Custom Role or find a specific Predefined role.
If you need to grant a user the ability to change IAM policies… Then use the Owner role or roles/resourcemanager.projectIamAdmin.
If you are setting up a production environment… Then Avoid Basic Roles (Owner/Editor/Viewer).
ACE Exam Tips: Golden Nuggets
- Distractor Alert: If an exam answer suggests granting “Editor” role to a service account for a simple task, it is likely incorrect. Look for a Predefined role.
- Hierarchy: Permissions are inherited. If you grant “Owner” at the Folder level, that user is “Owner” of all Projects inside that folder.
- Custom Role Limits: Custom roles cannot be used at the Folder or Organization level if they contain certain permissions; they are most commonly used at the Project level.
- Service Accounts: Treat Service Accounts as identities. You grant roles to service accounts so they can interact with other services.
Visualizing IAM Role Hierarchy
Key GCP Services
- IAM: The framework for policy management.
- Resource Manager: Used to set policies at Org/Folder level.
- Cloud Audit Logs: Tracks who did what and when.
Common Pitfalls
- Using Primitive Roles in production environments.
- Granting permissions to individual emails instead of Google Groups.
- Ignoring the Policy Troubleshooter tool.
Architecture Patterns
- Group-Based Access: Assign roles to Groups, add users to Groups.
- Service Account Per Service: Give each microservice its own identity.
- Role Separation: Separate Network Admin from Security Admin.