Managing Identity and Access Management (IAM)

Study guide for Associate Cloud Engineer, Unit 5 · Topic 1. This is the topic's lecture in reading form — every slide's teaching, figures and worked examples, in order — followed by the official Google Cloud pages its claims rest on.

What the exam guide asks, quoted. Managing Identity and Access Management (IAM). Considerations include:

Viewing and creating IAM policies
Managing the various role types and defining custom IAM roles (e.g., basic, predefined, custom)

Managing Identity and Access Management (IAM)

The policy says who holds a role; the role says what it allows

Objective 1 — the policy: what an allow policy is made of, how to read it and rewrite it without losing anyone's access, how grants inherit down the hierarchy, and where a deny policy overrides them. Objective 2 — the role: basic, predefined and custom roles, and the life of a custom role from gcloud iam roles create to deletion.

Identity and access management, or IAM, answers one question every time anyone touches a Google Cloud resource: may this principal use this permission here? The answer is assembled from two separate things, and this topic's two objectives are exactly those two things. The first is the policy. Google says you give a principal permission by granting them a role on a resource, and that you grant roles using an allow policy. So the first objective is about allow policies — reading them, changing them safely, understanding how a grant on a folder reaches the projects beneath it, and knowing where a deny policy can take away what an allow policy gave. The second is the role. You cannot hand out permissions one at a time; Google is explicit that roles are collections of permissions. So the second objective is about which kind of role to use — basic, predefined or custom — and how an engineer defines, stages, disables and deletes a custom role. Unit 1 already showed the one-line grant; this topic is what sits underneath it.

What an allow policy is made of

Role bindings, plus an etag and a version

An allow policy is attached to a resource and holds a collection of role bindings
A binding ties one or more principals to exactly one role, optionally with a condition
Metadata: an etag for safe concurrent updates, a version for the syntax schema
Version 1 has no conditions; version 3 adds the condition field
Principals in bindings look like group:my-group@example.com

Worked example (synthetic). A policy grants roles/storage.objectViewer to group:analysts@example.com with a condition that expires at quarter end. One binding, one role, one principal set — and the condition travels with that binding only.

Start with the shape, because every later command operates on it. Google defines an allow policy as a collection of role bindings and metadata, attached to a Google Cloud resource. A role binding associates, or binds, one or more principals with a single identity and access management role, together with any conditions that change how and when the role is granted. So a binding is always one role — if the same group needs two roles, that is two bindings, or one group listed in two. Principals are written with a type prefix; Google's own example is group colon my-group at example dot com, and Google groups are the convenient way to grant to a collection of people at once. The metadata is small but it matters. The etag is a value that changes every time the policy is updated, and it is how Google Cloud stops two writers overwriting each other. The version field records the syntax schema: version one supports binding one role to one or more principals but not conditional bindings, and version three introduces the condition field — Google's examples are temporary access to resolve a production issue, or access only from the corporate network. One restriction to remember: conditions cannot be used on the legacy basic roles Owner, Editor and Viewer.

Every field of an allow policy

What each field holds, and what goes wrong if you ignore it

Field	What it holds	Why it matters
`bindings`	The role bindings — the whole grant list	Writing a policy replaces this list entirely
`members`	One or more principals, such as `group:…`	A group lets you change people without editing the policy
`role`	Exactly one role per binding	Two roles for one group means two bindings
`condition`	Optional context the grant depends on	Needs version 3; a conditional binding never narrows an unconditional one
`etag`	A value that changes on every update	A stale etag makes your write fail instead of clobbering
`version`	The syntax schema of the policy	Version 1 cannot carry conditions

Worked example (synthetic). An engineer adds a condition to a group's binding, but the same group also holds that role unconditionally in another binding. The condition changes nothing: the unconditional binding still grants the role.

Here is the whole anatomy in one place, with the consequence of each field, because the exam's traps live in the consequences. The bindings are the grant list, and when you write a policy back the list you send replaces the one that was there. Members are the principals; granting to a group means later joiners and leavers change the group, not the policy. Role is exactly one per binding. Condition is optional, needs policy version three, and carries a rule people misread: Google says conditional role bindings don't override role bindings with no conditions, so if a principal already holds a role unconditionally, adding them to a conditional binding for the same role has no effect. The etag is the concurrency guard — it changes on every update, and a write carrying an out-of-date etag fails rather than silently overwriting someone else's change. And version records the schema: version one cannot carry conditions at all.

Viewing and changing a policy from the command line

One binding: add it. Many changes: read, modify, write — and respect the etag

Loading Diagram...

Figure 1 — Mermaid diagram

Figure: A flow chart of the read-modify-write cycle: get-iam-policy saves the policy, the file is edited, set-iam-policy writes it back; if the etag is still current the policy is replaced, otherwise the write fails and the cycle starts again from reading. A separate path shows add-iam-policy-binding for granting one role to one principal.

Worked example (synthetic). Two automation jobs both read a project's policy at nine o'clock and each adds a binding. The second write fails on its etag, re-reads, re-applies its one change, and writes again — so neither job's binding is lost.

There are two ways to change access from the command line, and the exam tests when to use which. For one role for one principal, Google says the add-iam-policy-binding command lets you quickly grant a role — one binding is a member, a role and an optional condition. For anything larger, Google prescribes the read-modify-write pattern. First read: the get-iam-policy command gets a project's, folder's or organization's allow policy, and you can save it as a file. Then modify that file. Then write: the set-iam-policy command sets the policy in the request as the new allow policy, and the output of get-iam-policy is itself a valid input. The warning that makes this a pattern rather than a convenience is this one: setting a new allow policy permanently overwrites the existing allow policy on the resource. If someone else changed the policy after you read it, the etag no longer matches and your write fails. Google's instruction for that failure is to retry the entire series — read again, modify again, write again — never to force the old copy through. Viewing works the same way without the write: the console's identity and access management page, the IAM page, lists principals including those who inherited roles from parent resources, and Policy Troubleshooter explains why a user does or doesn't have access.

Inheritance: the effective policy is a union

Grants flow down and add up; a lower level cannot take one away

Figure. An organization resource containing three folders — Finance, Engineering and Shared — each holding one project. A Viewer grant sits at the organization, reaching every folder and project. A second role is granted on the Finance folder, reaching only the ledger project inside it. The callout says a project inherits every grant above it, and its own allow policy can add roles but never remove an inherited one.

Worked example (synthetic). An auditor holds Viewer on the organization. A project owner opens the ledger project's IAM page to remove that access and finds it cannot be edited there — it must be changed on the organization, where it was granted.

This is the idea the diagram exists for. Google calls it the effective policy: all parent allow policies in the resource hierarchy are inherited for a resource. Concretely, the effective policy of the ledger project is the union of its own allow policy, the Finance folder's, and the organization's. And a request is granted if any of those role bindings grants it — Google's wording is that access is granted if any of the higher-level role bindings grant access to the request. Two consequences follow, and both are exam favourites. First, adding a binding anywhere above a resource can only widen access: if a new role binding is introduced at any level of a resource's inherited policy, the access grant scope increases. Second, a lower level cannot subtract an inherited grant. Google says you cannot edit inherited roles when managing access to a resource; to edit them, go to the resource where the role was granted. So the Viewer grant on the organization reaches every folder and project, the Finance grant reaches only ledger, and no project's own policy can revoke either. When you genuinely need to take a permission away regardless of grants, that is not an allow policy's job — it is a deny policy's, which is next.

Allow policies against deny policies

An allow policy grants; a deny policy is the guardrail no grant can pass

Aspect	Allow policy	Deny policy
What it does	Grants roles to principals	Blocks named permissions for named principals, whatever roles they hold
Where it attaches	A resource that accepts allow policies	An organization, folder or project
Inheritance	Inherited by descendants, unioned with theirs	Inherited by every lower-level resource
Evaluation order	Checked after deny policies	Checked first
Group identifier	`group:my-group@example.com`	`principalSet://goog/group/my-group@example.com`

Worked example (synthetic). Security wants nobody outside the project-admins group to delete a project anywhere in the company, whatever roles are granted later. That is a deny policy on the organization — Google's own example — not a trimmed allow policy.

Deny policies are how Google Cloud expresses the thing allow policies cannot: a limit. Google describes them as letting you set guardrails on access, with deny rules that prevent certain principals from using certain permissions, regardless of the roles they're granted. That last phrase works because of evaluation order — identity and access management always checks relevant deny policies before checking relevant allow policies. Each deny policy is attached to an organization, folder or project, and like allow policies they are inherited by all lower-level resources beneath the attachment point. Google's own example is exactly the scenario the exam likes: a deny policy that blocks all principals from deleting projects unless they are in the project-admins group. One practical trap: the two policy types write principals differently. In an allow policy a group is group colon my-group at example dot com; in a deny policy the same group is a principalSet identifier. And when you cannot tell which policy is deciding, Policy Troubleshooter takes a principal, a resource and a permission and examines the allow policies, deny policies and principal access boundary policies that affect that access.

Basic, predefined and custom roles

Broad and legacy, granular and Google-maintained, or granular and yours

Basic: broad access; Owner, Editor and Viewer are now called legacy basic roles
Basic roles hold thousands of permissions — avoid them in production
Predefined: granular per service; created, maintained and updated by Google
Custom: only the permissions you list — and you maintain them
The IAM recommender flags excess permissions from 90 days of use

Worked example (synthetic). A team grants Editor to every developer because it is quick. The IAM recommender later shows each of them used a fraction of it; the fix is the predefined roles for the services they actually touch.

Identity and access management offers three kinds of role, and the difference is who decides what is inside. Basic roles provide broad access to Google Cloud resources. The three everyone knows — Owner, Editor and Viewer — are what Google now calls legacy basic roles, because they existed before identity and access management; Editor, for example, is all Viewer permissions plus permissions to modify state. Google also has a new basic set, Admin, Writer and Reader, currently in Preview. Whatever the name, Google's caution is the same: basic roles include thousands of permissions across all Google Cloud services, and in production you should not grant them unless there is no alternative. Predefined roles are the default choice: they give granular access for a specific service, and they are created and maintained by Google, which automatically updates their permissions as services add features. Custom roles contain only the permissions you list, which makes them the tool for least privilege — and the price is that you maintain them, with a limit on how many a project or organization can have. To find over-granting in practice, the IAM recommender compares the permissions a principal holds with the ones it used over the last 90 days.

The three role types, side by side

Who maintains it, how wide it is, and where it can be granted

Aspect	Basic	Predefined	Custom
Who defines it	Google	Google	You
Who keeps it current	Google	Google, automatically	You
Width	Thousands of permissions	One service's task	Exactly your list
Where it can be granted	Anywhere	Anywhere	Only in the project or organization that defines it
Production use	Avoid	The default choice	When no predefined role fits

Worked example (synthetic). A payments team needs to read one service's configuration and nothing else, and no predefined role is that narrow. That is the case for a custom role — defined in the organization, because the projects that need it sit in different folders.

Read the table across and the choice makes itself. Basic and predefined roles are both Google's; the difference is width. Basic roles carry thousands of permissions, which is why Google says to avoid them in production, while a predefined role covers one service's task and is kept current by Google automatically. Custom roles are the only row where you are both author and maintainer. They also carry a boundary the others do not: you can only grant a custom role within the project or organization in which you created it. That boundary is the source of a common exam scenario — a custom role defined in one project cannot be granted in its neighbour. So the order of preference is predefined first, custom when no predefined role is narrow enough, and basic almost never.

Defining a custom role

Organization or project — never a folder — and only supported permissions

Figure. Four cards describing how to define a custom role: it lives in exactly one organization or project and never a folder; it is built from a title, description, launch stage and permissions, with list-testable-permissions showing what is allowed; each permission has a support level of supported, testing or not supported; and gcloud iam roles copy starts a custom role from an existing role, omitting deprecated and restricted permissions.

Worked example (synthetic). An engineer copies a predefined role into a project, removes two permissions, and sets the stage to BETA while a pilot team tries it. The role now belongs to that project only.

Defining a custom role starts with a placement decision. Google says that when you create a custom role, you must choose an organization or project to create it in, and the create command enforces it: you must also specify the organization or project flag. There is no third option — you cannot define custom roles at the folder level, and Google's advice when a folder needs one is to define it at the organization level. The content is a title, description, launch stage and permission list, supplied as flags or in a role file. Not every permission is allowed: the list-testable-permissions command shows which permissions are available for custom roles in a project or organization, and each permission carries a support level — supported, testing, or not supported. Testing permissions can be included but Google warns you might see unexpected behaviour and does not recommend them for production. The quickest start is usually an existing role: gcloud iam roles copy creates a role from an existing role, and when the source is a predefined role, deprecated and restricted permissions are omitted. Finally, a governance note: editing a custom role is powerful, so Google advises allowing only a small number of highly trusted principals to do it.

A custom role's life, from stage to deletion

Most stages are labels; DISABLED and deletion change what grants do

Loading Diagram...

Figure 2 — Mermaid diagram

Figure: A flow chart of a custom role's lifecycle: informational launch stages ALPHA, BETA and GA lead either to DISABLED, where bindings are inactive, or to deletion, where bindings have no effect. From deletion, undelete within seven days restores the previous state; after seven days permanent deletion runs for up to thirty days, after which bindings are removed and the role ID can be reused.

Worked example (synthetic). A custom role was deleted by mistake eight days ago. Undelete is no longer possible; the team recreates the permissions under a new ID, because the old ID only frees up once permanent deletion completes.

The last thing the objective asks for is managing a custom role over time, and the lifecycle has one important split. Most launch stages — alpha, beta, general availability — are informational; Google says they help you track whether a role is ready for widespread use. The exception is DISABLED. Setting the stage to DISABLED, most easily with the stage flag, disables the role, and any role bindings related to it are inactivated — granting it has no effect. Deletion goes further. A deleted role is suspended and cannot be used in new bindings, and existing bindings that include it have no effect. You can undelete within 7 days, which returns the role to its previous state. After 7 days Google Cloud begins permanent deletion, which can take up to 30 days; only when it completes are the bindings that refer to the role removed and the role ID, its identifier, free to reuse. So disabling is the reversible way to switch a role off, undelete has a one-week window, and a role's identifier is not immediately reusable after deletion.

What this topic actually tests

Five habits for reading access questions

One role, one binding. Many changes? Read, modify, write — a stale etag fails, so retry the whole cycle. Grants add up down the hierarchy; remove one where it was granted. To forbid regardless of grants, use a deny policy. Custom roles live in a project or organization, never a folder — disable to switch off, undelete within 7 days.

Five habits answer most of this topic. First, a binding is one role for one or more principals, so read a policy as a list of bindings. Second, for anything more than a single grant, use read-modify-write, because setting a policy overwrites it, and when the etag says someone else wrote first, retry the whole cycle. Third, the effective policy is the union of the resource's own policy and every ancestor's — grants only add up going down, and an inherited role is changed where it was granted. Fourth, when access must be impossible whatever roles exist, reach for a deny policy, which identity and access management checks before any allow policy. Fifth, custom roles belong to a project or an organization, never a folder, can only be granted where they are defined, are switched off with the DISABLED stage, and can be undeleted for 7 days.

Unit 5.1 study guide — Managing Identity and Access Management (IAM)

Managing Identity and Access Management (IAM)