How do you ensure that only the right person — or the right computer — can access your cloud resources, and only for the exact tasks they need to do? This is the central challenge of cloud security, and it's what IAM (Identity and Access Management) solves. For the Google Professional Cloud Security Engineer exam, understanding IAM is not optional — it's the foundation of nearly every security control you will design. Without IAM, your cloud environment is like a building with no locks on the doors.
Jump to a section
A simple way to picture IAM Roles, Policies, and Service Accounts
Have you ever wondered how a museum decides who can enter which rooms and what they can do once inside?
You've just started working at a massive museum with a priceless collection. The museum doesn't give you a single master key to every door because that would be a security nightmare — anyone with that key could steal the crown jewels or start a fire in the restoration lab. Instead, the museum uses a sophisticated key card system.
Your key card is a 'service account' — it's a permanent identity that belongs to you, not to a person who might leave the job. When you arrive, the security team assigns you a 'role'. This role isn't a piece of paper; it's a bundle of permissions. For example, the 'Curator' role lets you enter the gallery, open display cases, and move items. The 'Security Guard' role lets you patrol the building, lock doors, and watch cameras, but never touch the artworks. The 'Restorer' role lets you handle delicate paintings in the conservation lab but not access the cash office.
Each role has an attached 'policy' — a written rulebook. The rulebook for the 'Curator' might say: 'Allowed to open display cases between 9 AM and 5 PM' and 'Forbidden to remove items from building'. These policies are the museum's rules. They define exactly what actions (enter, view, move, unlock) are permitted on which resources (galleries, cases, storage rooms).
The beauty of this system is that when a new security guard starts, the museum doesn't write a new rulebook from scratch. They just assign the existing 'Security Guard' role to the person's key card. And if the museum decides that security guards should also patrol the roof, they update the role policy once, and all security guards immediately get that new permission. This is exactly how Google Cloud's IAM works — roles are reusable bundles of permissions, policies are the rules that define them, and service accounts are the 'key cards' for automated systems, not people.
IAM stands for Identity and Access Management. Think of it as the security guard and the lock system for your entire Google Cloud project. It answers three simple but critical questions: Who can do what, and on which resource?
Let's break down the three key pieces: identities, roles, and policies.
Identities are the 'who'. An identity can be a human user (like an employee with a Google account), a Google Group (a collection of accounts), or a 'service account' (a special kind of account for software, not a person). Service accounts are crucial for automation — for example, when a virtual machine needs to talk to a storage bucket, it uses a service account to authenticate itself, just like a robot using its own ID badge.
Roles are bundles of permissions. A permission is a single atomic action, like 'storage.buckets.list' (which lets you see a list of buckets) or 'compute.instances.start' (which lets you turn on a virtual machine). A role collects dozens or hundreds of these permissions into a named package. For instance, the 'Storage Object Viewer' role includes all the permissions needed to look at files in a storage bucket, but not to delete them or create new folders.
Google Cloud has three main types of roles:
Basic Roles: These are the broad, legacy roles that apply to the whole project. They are 'Owner', 'Editor', and 'Viewer'. 'Owner' can do everything, including manage permissions. 'Editor' can create, modify, and delete resources but cannot change IAM policies. 'Viewer' can only read resources. Avoid using Basic Roles in production because they are too permissive — like giving a guest the keys to the whole house.
Predefined Roles: These are fine-grained roles created and maintained by Google Cloud. For example, 'Compute Instance Admin' gives specific permissions to manage virtual machines. These are much safer than Basic Roles because they follow the principle of least privilege — giving only the minimum permissions needed.
Custom Roles: When Google's predefined roles don't fit your exact needs, you can create your own. You pick and choose individual permissions to form a custom bundle. This is like tailoring a suit instead of buying off the rack. However, custom roles require more maintenance and can become chaotic if not managed carefully.
Policies are the binding that connects a role to a set of identities. A policy is a JSON or YAML document that says: 'Grant the role X to these identities (users, groups, service accounts) on this specific resource or project'. When you attach a policy, you are saying, 'From now on, user Alice has the role of Storage Admin on the bucket named 'my-company-files'.' The policy is the rule that makes the role actually work.
How does it all fit together in a real Google Cloud project? Imagine you have a project called 'retail-web-app'. Your team includes a developer named Bob, a security auditor named Carol, and a billing specialist named Dave. Without IAM, everyone has full access — a disaster. With IAM, you create policies: one policy attaches the 'roles/viewer' role to Carol on the entire project (so she can read logs but not touch resources). Another policy attaches the 'roles/iam.securityReviewer' role to Carol as well, allowing her to see all IAM policies. Bob gets the 'roles/container.developer' role on a specific cluster, so he can deploy code but not delete the cluster. Dave gets the 'roles/billing.viewer' role on the billing account. Each policy is a separate statement that grants a specific role to a specific identity on a specific resource.
Why does this matter for the PCSE exam? Because exam questions love to test whether you understand the difference between granting a role at the organisation level versus the project level versus the resource level. A role granted at the organisation level (the top of the hierarchy) applies to all projects underneath. A role granted directly on a single storage bucket applies only to that bucket. Understanding this inheritance is vital — it's the most common trap in the exam. Also, the exam tests service accounts heavily: when to use them, how to create them, and the difference between a user-managed service account and a Google-managed service account. The key takeaway is that IAM is not just 'who can access' — it is 'who can do what, where, and under what conditions'.
Identify the Identity
Determine who or what needs access. Is it a human user, a group of users, or an application (service account)? For humans, use their individual Google accounts or add them to a Google Group. For applications, create a service account (e.g., my-app-sa@project.iam.gserviceaccount.com). This step is crucial because the rest of the process depends on the identity type.
Choose the Right Role
Select a role that provides the exact permissions needed. Start with Google's predefined roles (e.g., roles/storage.objectViewer) because they are maintained and secure. Avoid Basic Roles (Owner, Editor, Viewer) unless absolutely necessary. If no predefined role fits, create a custom role with only the required permissions. Remember: least privilege is the goal.
Attach a Policy to the Resource
Create a policy that binds the chosen role to the identity on the target resource. For example, use the gcloud command: 'gcloud projects add-iam-policy-binding PROJECT_ID --member='user:alice@example.com' --role='roles/storage.objectViewer'. This policy is the actual mechanism that grants access. Without this step, the role is just a definition with no effect.
Test and Verify Access
Use tools like the Google Cloud Console's 'Policy Troubleshooter' or the 'gcloud policy-troubleshoot' command to verify that the identity has the expected permissions. This step catches errors like incorrect role selection or missing policy bindings. Also, check that no Deny policies (if used) are blocking the access.
Audit and Review Regularly
IAM is not a set-and-forget system. Use the Policy Analyzer and IAM Recommender to identify over-permissive roles and stale service accounts. Revoke unnecessary permissions and remove unused service accounts. Schedule regular reviews (e.g., quarterly) to ensure compliance with the principle of least privilege and to adapt to changing team roles.
Implement Conditions for Fine-Grained Control
For advanced scenarios, add IAM Conditions to your role bindings. For example, a condition that only allows access if the request comes from a corporate IP address or during business hours. This ensures that even if someone has a role, they cannot use it from an unauthorised location or time.
Let's walk through a real scenario at a company called 'FreshCart', a grocery delivery startup that hosts its app on Google Cloud. As the new cloud security engineer, you need to set up IAM for the entire engineering team. FreshCart has 30 engineers, a database that stores customer addresses, and a storage bucket for delivery route maps.
Step 1: Audit existing access. You discover that the previous engineer gave everyone in the company the 'Editor' Basic Role on the project. This is a nightmare — the customer support intern can delete the production database. Your immediate task is to remove these broad permissions and replace them with specific roles.
Step 2: Organise users into Google Groups. Instead of assigning roles to 30 individual accounts, you create three groups: 'freshcart-developers', 'freshcart-devops', and 'freshcart-security-auditors'. You add the relevant people to each group. This is a best practice — managing groups is much easier than managing individual users.
Step 3: Assign roles to groups. You attach policies that grant roles to these groups. For example:
On the project 'freshcart-production', you grant the 'roles/viewer' role to the 'freshcart-security-auditors' group. This allows them to see all resources but change nothing.
You grant the 'roles/container.clusterAdmin' role to the 'freshcart-devops' group only on the Kubernetes cluster where the app runs. This lets them manage the cluster but not touch the billing account.
You grant the 'roles/storage.admin' role to the 'freshcart-devops' group on the storage bucket containing delivery routes.
Step 4: Create service accounts for automation. The app itself needs to write logs to a log bucket. You create a service account called 'app-log-writer@freshcart.iam.gserviceaccount.com'. You then attach a policy granting this service account the 'roles/logging.logWriter' role on the project. The app uses the credentials of this service account to authenticate, so it can write logs without anyone having to log in manually. This is critical because it means no human passwords are shared with the application.
Step 5: Test and review. You simulate an attack: what if a developer's laptop is compromised? Since you used groups and service accounts, the attacker can only do what the developer's group role allows. The developer does not have the service account key, so the attacker cannot write logs or access the database. You also set up 'Access Transparency' logs to audit all role grants.
Step 6: Use conditions. FreshCart later adds a compliance requirement that developers can only deploy code to production between 9 AM and 5 PM. You create an IAM condition attached to their roles: 'request.time < timestamp('2025-01-01T17:00:00Z')'. Now, their policy automatically denies deployment outside working hours.
What does an IT professional actually do with this? They spend a large part of their day writing and updating JSON policy files, using the 'gcloud' command-line tool to assign roles, auditing policies with the Policy Analyzer, and troubleshooting why a user can't access a resource (which usually means a missing or incorrect role assignment). They also regularly use the 'IAM Recommender' — a Google Cloud tool that suggests roles based on actual usage patterns, helping to remove excessive permissions. In short, a cloud security engineer's job is 50% IAM management.
The PCSE exam tests IAM Roles, Policies, and Service Accounts in a variety of tricky ways. This is not a rote memorisation section — you must understand the concepts deeply to distinguish between similar-sounding options.
Question types that appear frequently:
Scenario-based role selection: The question describes a team member's job (e.g., 'A network admin needs to create VPCs but not delete existing ones') and asks which predefined role to assign. The trap is that 'Network Admin' has delete permissions, while 'Network Viewer' only has read permissions. The correct answer is often a custom role or the 'Compute Network User' role.
Inheritance questions: The exam loves asking: 'If a user has the Viewer role at the project level and the Editor role on a single bucket, what can they do on the bucket?' The answer is Editor-level permissions — because resource-level policies override (are evaluated in addition to) project-level ones. But careful: a DENY policy always overrides an ALLOW. Google Cloud now supports deny policies, and the exam tests this.
Service account vs. user account: You will be asked when to use a service account. The correct answer is typically 'for applications and automated processes, not for human users'. A trap answer will say 'for the CEO's personal access' — that's wrong.
Custom roles vs. predefined roles: Questions ask why you should use predefined roles. The answer is that predefined roles are maintained by Google, which reduces the risk of misconfiguration. The exam loves to suggest chaos if you use custom roles without proper versioning.
Conditions and attributes: Newer exam questions test IAM conditions — for example, restricting access based on IP address, time of day, or resource type. You must know the syntax of the Common Expression Language (CEL) used in conditions.
Key concepts to memorise for the exam:
Resource hierarchy: Organisation -> Folder -> Project -> Resource. Permissions flow downward but are additive. A role granted at the organisation level applies to all projects.
Binding vs. Policy: A binding is the association of one role with a set of members. A policy is the collection of all bindings for a given resource. This is important for understanding JSON policies.
Primitive vs. Predefined vs. Custom: Know the exact names: Basic Roles (Owner, Editor, Viewer), Predefined (like roles/storage.objectViewer), Custom (you name them).
Service account keys: There are two types: Google-managed keys (automatically rotated) and user-managed keys (you download a JSON key file). The exam warns against downloading user-managed keys unless absolutely necessary because they are a security risk if leaked.
Workload Identity Federation: This is a newer feature that lets you use external identities (like from AWS or Azure) without creating a service account key. The exam is starting to include this as a secure alternative.
Common trap patterns:
The exam will offer 'Owner' as an answer when a more specific role would suffice. Always choose the least-privilege option.
They will suggest using a service account for a human user. Never choose that.
They will claim that denying at the organisation level prevents an inherited allow from working — that's false in old IAM but true with Deny policies (a new feature). Know the difference.
They will offer 'roles/iam.serviceAccountUser' as a role that lets you delete service accounts — it doesn't. That role only lets you use the service account. To delete, you need 'roles/iam.serviceAccountAdmin'.
To prepare, practise writing policies in JSON and using the gcloud command-line tool. Understand the difference between 'add-iam-policy-binding' and 'set-iam-policy'. The exam will test both the concept and the implementation details.
IAM is the system that controls who (identity) can do what (role/permission) on which Google Cloud resource (policy binding).
There are three types of roles: Basic (Owner, Editor, Viewer — avoid these), Predefined (fine-grained, Google-managed), and Custom (you define, but maintain yourself).
Service accounts are non-human identities for applications and virtual machines; they should never be shared with or used by human users.
Policies are documents that bind a role to a set of members on a specific resource; they are the only way to make a role effective.
Permissions flow down the resource hierarchy from Organisation to Folder to Project to Resource, but Deny policies override Allow policies.
Always apply the principle of least privilege: grant only the minimum permissions required for a user or service to perform their tasks.
Google Groups simplify IAM management by letting you assign roles to a group rather than to dozens of individual users.
IAM Conditions let you add restrictions (like time of day or IP address) to a role binding, giving you fine-grained control beyond just the role definition.
These come up on the exam all the time. Here's how to tell them apart.
IAM Role
A bundle of permissions (e.g., view objects, create instances).
Defines the set of allowed actions.
Exists independently of any user or resource.
IAM Policy
A document that binds a role to one or more identities on a resource.
Defines who gets the role and on what resource.
Is always attached to a specific resource and a specific set of members.
Service Account
Non-human identity for applications and VMs.
Cannot log into the Google Cloud Console interactively.
Authenticates via private keys or attached compute resource.
User Account
Human identity for individual people.
Can log into the Console with a password and 2FA.
Typically used for manual administration and development.
Predefined Role
Created and maintained by Google Cloud.
Includes permissions that Google considers safe for common tasks.
Automatically updated when Google adds new features.
Custom Role
Created by the organisation from scratch.
You manually select each permission; risk of misconfiguration.
Not updated automatically; requires manual maintenance.
Basic Role (Owner)
Grants full control over all resources in the project.
Includes permissions to manage IAM policies.
Recommended only for a few project managers, not daily use.
Predefined Role (e.g. Compute Admin)
Grants specific permissions only to compute resources.
Cannot modify IAM policies directly.
Recommended for granular, least-privilege access.
Allow Policy
Grants permissions to identities.
Is additive — multiple allow policies combine.
Traditional IAM only supports allow policies.
Deny Policy
Explicitly blocks permissions even if an allow policy exists.
Is evaluated first and overrides any allow.
Introduced later; used for strict security controls.
IAM Condition
Adds a restriction to a role binding (e.g., time, IP).
Allows granular access control beyond the role definition.
Uses Common Expression Language (CEL) syntax.
Without Condition
Role binding is unconditional and applies always.
Simpler to configure but may grant broader access.
No additional logic is evaluated during access.
Mistake
IAM roles are the same as permissions — if I have a role, I automatically have every permission in that role forever.
Correct
Roles are bundles of permissions, but you only have those permissions when a policy attaches the role to your identity on a specific resource. Also, roles can be updated by Google, so your effective permissions can change if a predefined role is modified.
Beginners confuse the definition of a role with its application. They think of a role as a static key rather than a dynamic template that only becomes active through a policy binding.
Mistake
Service accounts are a type of user account that can log in to the Google Cloud Console with a username and password.
Correct
Service accounts are non-human identities used by applications and virtual machines. They cannot log in interactively to the Console. They authenticate using private keys or IAM roles attached to the compute resource.
The name 'service account' sounds similar to 'user account', leading beginners to assume it works like a normal account. In reality, it is a robot ID, not a person ID.
Mistake
Granting the 'Owner' role to a user is a good way to give them full control over a specific folder without affecting other folders.
Correct
The 'Owner' role is a Basic Role that grants permissions at the project level (or higher). If you grant it on a folder, it applies to all projects within that folder but not to other folders at the same level. However, Basic Roles (Owner, Editor, Viewer) are not recommended because they include many permissions that are excessive. The correct approach is to use a Predefined or Custom role for the folder.
People think 'Owner' is granular because the word sounds specific, but in IAM, it is the broadest role. The term 'Owner' implies responsibility; in reality, it is a permissions bundle that is too permissive for most use cases.
Mistake
If you deny a permission at the organisation level, and then allow it at the project level, the allow wins.
Correct
With Google Cloud's Deny policies (introduced later), a deny at a higher level overrides an allow at a lower level. However, with the traditional allow-only IAM, you cannot deny — you simply don't grant the role. The newer Deny policies follow the rule that explicit deny overrides any allow.
This misconception arises from confusion between the old IAM system (which only allowed) and the new system (which supports both allow and deny). Beginners assume allow always wins, but deny policies are designed to be stronger for security control.
Mistake
IAM roles assigned to a Google Group apply to every member of the group, including external users outside your organisation.
Correct
IAM roles assigned to a Google Group apply only to members who have Google accounts within your Cloud Identity or Google Workspace domain. External users not in your domain cannot inherit those roles unless explicitly added to the group and granted access to the resource.
Beginners assume groups are automatically transitive across domains. In reality, Google Cloud IAM groups only work for identities managed by the same organisation or for Cloud Identity users. External access requires additional configuration like domain-wide delegation or service accounts.
Mistake
A service account can be used to impersonate a human user to perform actions that the human cannot.
Correct
A service account is a separate identity from a human user. It cannot impersonate a human user because it is not a person. Instead, a human user (with the 'iam.serviceAccountTokenCreator' role) can impersonate a service account to let the service account perform actions, but the service account's permissions are fixed by its own roles, not the human's.
This misunderstanding comes from the word 'impersonate' which appears in IAM feature names. People think a service account can masquerade as a user, but the relationship is the reverse — the user can temporarily 'act as' the service account for automated tasks.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An IAM role is a bundle of permissions (like a job description). An IAM policy is the document that attaches that role to a specific identity (user, group, or service account) on a particular resource. The role says what can be done; the policy says who can do it and where.
Yes, you can assign any role — including custom roles — to a Google Group. When you attach a policy that grants the role to the group, every member of that group inherits the role's permissions on the resource. This is a best practice for managing permissions at scale.
If you delete a service account, any policies that granted roles to that service account become ineffective because the identity no longer exists. Any application relying on that service account will fail to authenticate. You should always remove the service account from policies before deleting it, or better, disable it first.
Yes, generally you should create a separate service account for each application or each distinct function. This follows the principle of least privilege and makes it easier to audit which application accessed what. Using one service account for everything is a security risk because a breach in one app affects all resources.
You cannot directly grant folder-level permissions in Cloud Storage using IAM. IAM roles apply to the entire bucket or project. However, you can use IAM Conditions to restrict access based on object name prefix (e.g., only objects starting with 'folder1/'). Alternatively, use Access Control Lists (ACLs) for more granular object-level control, but note that ACLs are legacy and IAM is preferred.
A service account key is a private key (usually a JSON file) that allows an application to authenticate as the service account. A user account password is used for interactive login by a human. Service account keys are meant to be stored securely by applications and should never be used by humans. They also have a longer lifespan than typical passwords.
You've finished IAM Roles, Policies, and Service Accounts. Continue through the PCSE study guide to build a complete picture of the exam.
Done with this chapter?