What is identity and access management (IAM)?

Authentication vs authorisation: who you are vs what you can do

IAM rests on two questions that beginners often blur. Authentication establishes who you are: you prove your identity with something you know (a password), something you have (a phone or hardware key), or something you are (a fingerprint). Authorisation establishes what you can do: once the platform knows who is asking, it checks the permissions attached to that identity before allowing the action. A useful mnemonic — authentication is the passport check, authorisation is the visa.

The order matters, and so does the separation. Being authenticated proves nothing about permissions: you can be logged in and still be refused every action, which is precisely how a well-run account treats a brand-new user. Exam questions love this distinction — a scenario describes a user who can sign in but cannot perform some action, and the correct diagnosis is an authorisation problem, not an authentication one.

Identities, policies and least privilege

The building blocks of IAM are consistent across providers, whatever the local names:

• Users — identities for individual people (or occasionally applications), each with their own credentials.
• Groups — collections of users that share permissions, so access is managed once per team rather than once per person.
• Roles — identities with permissions but no permanent credentials, assumed temporarily by people or services that need them for a task.
• Policies — documents that define permissions: which actions are allowed or denied, on which resources, under which conditions. Attaching policies to users, groups or roles is how authorisation is actually granted.

Why IAM is the most important security control in the cloud

The principle that ties the building blocks together is least privilege: every identity should hold the minimum permissions needed for its job, and nothing more. It sounds obvious and is routinely violated, because broad permissions are convenient — an administrator policy attached “temporarily” to unblock someone has a way of becoming permanent. The cost appears later: when a credential leaks or an application is compromised, the blast radius is exactly the set of permissions that identity held. Least privilege is what keeps that blast radius small.

This is also where the shared responsibility model — covered in our explainer on it — bites hardest. The provider secures the infrastructure, but who can access your resources and what they may do is squarely the customer’s job, on AWS and Azure alike. No provider can protect you from a permission you granted. That is why the most common cloud security failures are access failures: over-permissive identities, credentials leaked into code repositories, and privileged accounts without multi-factor authentication. IAM is not one security control among many; it is the control the others depend on.

Multi-factor authentication: the highest-value habit

Multi-factor authentication (MFA) requires a second proof of identity beyond the password — typically a code from an authenticator app or a tap on a hardware security key. The reasoning is simple: passwords leak, through phishing, reuse and breaches elsewhere, and a stolen password is useless to an attacker who cannot supply the second factor as well. Enabling MFA on every human identity — and treating it as non-negotiable for administrative ones — is the single highest-value IAM habit, which is why both AWS and Microsoft push it so hard and why certification exams treat “enable MFA” as a reflexively correct answer for protecting accounts.

MFA protects sign-ins; it does not fix bad authorisation. An over-permissioned identity behind MFA is still an over-permissioned identity. The two controls answer different threats — MFA against stolen credentials, least privilege against the damage any single identity can do — and a sound account uses both.

Roles and temporary credentials vs long-lived keys

The most consequential IAM idea beyond the basics is preferring temporary credentials over long-lived ones. A long-lived access key is a static secret: it works for anyone who obtains it, indefinitely, until someone remembers to rotate it. Keys of this kind end up pasted into scripts, committed to repositories and forgotten — and each one is a standing risk.

Roles solve this structurally. Instead of holding a permanent key, a person or service assumes a role and receives short-lived credentials that expire automatically — nothing durable exists to steal. An application running in the cloud can be granted a role directly, so it never stores a secret at all; a human can assume an administrative role only for the minutes a task requires. The principle generalises across providers: identities for people, roles and temporary credentials for workloads and for elevated access, and long-lived keys only where nothing better exists. Exams reward this preference consistently — an answer that embeds a static key in an application is almost always the wrong one.

AWS IAM, Microsoft Entra ID — and the exams

The implementations you will actually meet: AWS calls its service simply IAM — Identity and Access Management — with users, groups, roles and JSON policy documents as above. Azure’s identity service is Microsoft Entra ID, the current name for what was long known as Azure Active Directory (Azure AD); it manages users and groups and handles sign-in, while Azure authorisation is expressed through role-based access control (RBAC) — roles assigned to identities over specific scopes such as a subscription or resource group. The vocabularies differ; the concepts in this guide map across almost one-to-one.

Few topics repay certification study as reliably. AWS Cloud Practitioner (CLF-C02) tests IAM fundamentals in its security domain — users versus roles, policies, MFA, least privilege. The AWS Security – Specialty (SCS-C03) goes deep: policy evaluation, cross-account access, credential management and federation. The Azure Administrator Associate (AZ-104) opens with identities and governance — Entra ID users and groups, and RBAC assignments. Learn the concepts once, precisely, and they pay marks on every paper you sit; the per-cert revision lessons on this site then take each exam’s IAM syllabus to full depth.