Identity and Access Management (IAM)

IAM is the authorisation system. Every action on every resource passes through it. The model is deliberately small: you grant a role to a member on a resource, and the role is a bundle of permissions.

It is worth stating the model precisely, because the wording matters. You do not grant permissions directly to people. You grant a role, which contains permissions, to a member, at a point in the resource hierarchy.

IAM is the highest-yield topic in the entire certification programme relative to time spent studying it. It appears on every exam, it is tested precisely, and the questions have a reliable shape: four roles that would all technically work, one of which grants least privilege.

In production it matters for a simpler reason. Over-granted permissions are the most common serious misconfiguration in cloud environments, and they are the mechanism by which a small compromise becomes a large one.

• Member (principal) — the identity: a user account, a group, a service account, a domain, or a federated external identity.
• Permission — the finest-grained unit, expressed as service.resource.verb, such as compute.instances.start. You never grant these individually.
• Role — a collection of permissions. The only thing you actually grant.
• Policy binding — the attachment of a role to a member at a specific resource. The set of bindings on a resource is its IAM policy.
• Inheritance — policy flows down the hierarchy. A role granted at the folder level applies to every project and resource beneath it. It never flows upward.
• Service account — an identity for software rather than a person. Applications, virtual machines and pipelines act as one.
• Impersonation — allowing an identity to temporarily act as a service account. Preferable to distributing key files because the access can be revoked instantly and every use is logged.
• Workload identity federation — letting an external system authenticate as a service account using its own identity provider, so no key file is ever created.
• IAM conditions — attaching restrictions to a binding, such as an expiry date or a restriction to specific resource names.

The consequence deserves emphasis: IAM is additive and there is no deny that undoes an allow granted higher up. If someone has Editor at the organisation level, you cannot remove their access to one project by adjusting that project's policy. You must fix the grant where it was made.

Service accounts cause more real-world security incidents than any other IAM feature, almost always because of key files. A downloaded key is a long-lived credential that works from anywhere, does not expire, and is trivially committed to a repository by accident.

• Create a dedicated service account per workload. Never share one across unrelated services, and never use the default service account for production.
• Attach the service account to the resource — a virtual machine, a Cloud Run service, a Kubernetes workload — so credentials are obtained automatically and rotated for you.
• Use workload identity federation for systems outside the platform rather than issuing a key.
• Use impersonation for human access that needs elevated rights, so it is temporary and audited.
• If a key genuinely cannot be avoided, rotate it on a schedule and monitor for its use from unexpected locations.

• Grant to groups rather than individuals so access follows role changes automatically.
• Grant at the lowest level of the hierarchy that satisfies the need, not the most convenient level.
• Start from a predefined role that is slightly too narrow and add to it, rather than starting broad and intending to trim later.
• Use conditions to add expiry to temporary elevated access.
• Review who holds broad roles regularly; permission grants accumulate and are rarely removed voluntarily.
• Separate duties: whoever administers encryption keys should not also administer the data those keys protect.