How do you stop the wrong person from accessing your company's most sensitive data in the cloud, while letting the right people do their jobs without constant hassle? That's the core problem identity and access management (IAM) solves. For the CCSP exam, understanding IAM is non-negotiable because cloud environments are shared, remote, and constantly under attack.
Jump to a section
A simple way to picture Cloud Management Plane and Identity Management
Ever walked into a hotel and wondered how the front desk knows exactly which room you can enter, which floors you can access, and whether you can use the gym or the business centre? That's not magic, that's identity management at work.
When you check in, the hotel registers you as a guest — that's identity creation. They take your name and verify your booking — that's authentication. But the real power is the key card the receptionist hands you. That plastic card isn't just a piece of metal and chip; it's a token that grants you specific permissions. It might let you into room 305 but not room 306. It might open the pool door but not the staff-only maintenance closet. The hotel's central system — the management plane — decides what each key card can do based on who you are and what you booked.
Now imagine you lose the card. You go back to the front desk, they cancel the old key and issue a new one. The physical locks on the doors don't change; only the central system's instructions change. That's the cloud management plane in action: a central control layer that manages who you are, what you can access, and how permissions are updated or revoked. In the cloud, the management plane is the hotel's front desk system, and identity management is the key card strategy. Without it, anyone could walk into any room.
Let's start from the beginning. Identity and Access Management, or IAM, is the system that answers two simple questions: Who are you? And what are you allowed to do? In the physical world, a security guard with a clipboard does this. In the cloud, software does it automatically.
First, you need to understand the cloud management plane. Think of the cloud provider — like Amazon Web Services, Microsoft Azure, or Google Cloud — as having three layers. At the bottom is the data plane, where your actual stuff lives: virtual servers, databases, storage buckets. Above that is the control plane, which lets you create, modify, and delete those resources. At the very top is the management plane. The management plane is the overarching system through which you configure security, monitor activity, and manage users. Everything you do to set up your cloud account — creating users, assigning permissions, setting up roles — happens in the management plane.
Now, IAM is the part of the management plane that handles identities. An identity is simply a digital representation of a person or thing. Every person who needs access to the cloud gets a user identity. But machines also need identities — for example, a web server might need to talk to a database server. Those are called service accounts or system identities.
Authentication is the process of verifying that an identity is genuine. It answers the question: 'Are you really who you claim to be?' The most common method is a password, but stronger methods include multi-factor authentication (MFA) — which requires something you know (password), something you have (phone), and something you are (fingerprint).
Once you're authenticated, authorisation decides what you can do. This is where IAM policies come in. A policy is a set of rules that says who can do what with which resources. For example, a policy might say: 'User Alice can read files in bucket B1 but cannot delete them.' Policies are evaluated every time a request is made to the management plane or the data plane.
The CCSP exam places heavy emphasis on three core IAM concepts:
Users: individual human accounts.
Groups: collections of users that share the same permissions (like 'Finance Team' or 'Developers').
Roles: identities that can be assumed by a user or service temporarily, often used to grant cross-account access.
Why does this matter? Before cloud computing, companies had a single network with on-premise servers. You logged in once to the company network and then could access everything. That was simple but dangerous — if a hacker got in, they had free reign. In the cloud, you have multiple accounts, multiple environments (development, testing, production), and thousands of users spread across the globe. IAM allows you to give the minimum necessary access to each user — a principle called least privilege. This dramatically reduces the damage if one account is compromised.
The management plane in IAM also handles federation — allowing users to log in using their existing corporate credentials (like Google or Microsoft Entra ID) instead of creating a new cloud password. This is done through Security Assertion Markup Language (SAML) or OpenID Connect. Federation means the cloud provider trusts your company's identity system.
Finally, there is the concept of cloud management plane separation. Large organisations often manage multiple cloud subscriptions or accounts. They need a way to control access across all of them from one place. That's where management groups or organisational units come in — hierarchical containers that allow you to apply policies to multiple accounts at once. The CCSP exam expects you to know that the management plane is a critical attack surface. If an attacker compromises a user with management plane permissions, they can take over your entire cloud environment.
Define the Identity Source
The first step is deciding where user identities will live. You can create them directly in the cloud provider's IAM system (like AWS IAM), or you can connect an external identity provider like Microsoft Entra ID via federation. This determines the root of trust for all future access decisions.
Create Users and Groups
You create individual user accounts for each person who needs access. To simplify management, you place users into groups that reflect job functions, such as 'Developers' or 'Auditors'. Permissions are then assigned to groups rather than to individual users, making updates easier when people change roles.
Define IAM Policies
You write policies — typically in JSON format — that specify exactly which actions are allowed or denied on which resources. For example, a policy might allow reading from a storage bucket but deny deleting it. Policies are attached to users, groups, or roles. The order of rules matters: explicit Deny rules override Allow rules.
Assign Permissions Using the Principle of Least Privilege
You review each user's job responsibilities and grant only the permissions necessary to perform that role. This minimises the damage if an account is compromised. Avoid granting broad permissions like 'AdministratorAccess' unless absolutely required. Regularly audit and refine permissions.
Enable Multi-Factor Authentication and Monitoring
You enforce MFA for all human users, especially those with management plane access. You also enable logging services — such as AWS CloudTrail or Azure Monitor — to record every action taken in the management plane. This creates an audit trail for detecting suspicious activity and for compliance reporting.
Establish an Ongoing Review Cycle
IAM is not a one-time project. You schedule quarterly or monthly access reviews to remove stale accounts, revoke permissions for users who have changed roles, and verify that service accounts are still needed. This step is critical for maintaining a secure cloud environment over time.
Imagine you work as a cloud administrator for a mid-sized company called 'GreenLeaf Analytics'. The company has 500 employees, uses Amazon Web Services, and runs a customer-facing analytics platform. Your boss says: 'We need to hire three new data scientists. Give them access to the development environment, but not to production. Also, they should be able to launch virtual machines but not delete databases.'
Here is what you actually do, step by step:
First, you navigate to the AWS Management Console — the graphical interface for the management plane. You open the IAM section. You create three new user accounts, each with a unique username and a temporary password. You require MFA on each account because the company security policy mandates it.
Second, instead of attaching permissions directly to each user (which would be tedious and error-prone), you add them to an existing group called 'Developers'. That group already has a policy attached that grants read/write access to development resources. But the policy also includes a 'Deny' for production databases — a deliberate denial rule that overrides any other permissions.
Third, you need to provide the developers access to an internal tool that runs in a separate AWS account dedicated to analytics. To do that, you create a role in the analytics account and assign it permissions to read data from the developers' group. Roles allow cross-account access without sharing passwords.
Fourth, you test the setup. You log in as one of the new users and try to launch a virtual machine in development — it works. You try to delete a production database — it fails. You also try to access the analytics tool — it works because the role assumption is automatic.
Fifth, you set up cloud logging to monitor everything. You enable AWS CloudTrail, which records every action taken in the management plane. If one of the data scientists accidentally tries to delete a storage bucket, you'll get an alert. You also set up a monthly review to check if any users have more permissions than they need — a process called access review or entitlement review.
In the real world, IAM is not a one-time setup. Users join, leave, or change roles. A developer might get promoted to team lead and need additional permissions. A contractor might need temporary access for a project. Your job is to continuously adjust permissions using the management plane. You also need to respond to incidents. If you detect unusual activity — like someone logging in from an unexpected country — you disable that user's access immediately from the management plane.
The CCSP exam tests your understanding of the cloud management plane and identity management in several specific ways. Here is what you must absolutely master.
First, the exam loves to test the difference between authentication and authorisation. A typical question might describe a scenario where a user can log in but cannot perform an action. The answer will likely be: the user is authenticated but lacks authorisation. There is a classic trap where the question describes a user being denied access, and two answer options involve 'authentication failed' versus 'authorisation failed'. Remember: authentication is about identity verification; authorisation is about permission granting.
Second, the exam frequently asks about the principle of least privilege. You will see scenarios where a security breach occurred because a user had more permissions than needed. The correct answer will recommend applying the least privilege model — granting only the permissions necessary for a specific job function.
Third, you must understand roles versus users. The exam will present a situation where a company needs to give temporary access to a contractor or to a service across accounts. Roles are the correct answer because they are designed for temporary, cross-account access without the need to manage long-term credentials.
Fourth, the exam tests federation. Questions will describe a company that wants its employees to log into the cloud using their existing corporate credentials (e.g., Microsoft Entra ID). The correct answer will involve federation using SAML or OIDC. A trap is that beginners might think you need to create separate cloud users for each employee. You don't — federation avoids that.
Fifth, the exam tests your knowledge of the management plane itself as a security boundary. Questions will ask: 'What is the greatest risk if an attacker gains access to a user with management plane permissions?' The answer: the attacker can take over the entire cloud environment — create, modify, or delete all resources, change policies, and lock out legitimate administrators.
Here are the specific exam topics you need to memorise:
- IAM: Identity and Access Management — the system that controls who can do what. - Authentication vs. Authorisation: authentication is proving identity; authorisation is granting permissions. - Least privilege: granting only the minimum necessary permissions. - Roles: temporary, cross-account identity assignments. - Groups: collections of users for easier permission management. - Policies: JSON documents that define permissions (Allow or Deny). - Federation: using external identity providers for authentication. - MFA: multi-factor authentication for stronger security. - Management plane: the centralised control layer for configuring cloud resources. Traps to watch for:
The exam might say 'service control policies' instead of 'policies' — know that these are a type of policy used in AWS organisations.
They might use the term 'Condition' in policies — conditions are rules that limit when a policy applies (e.g., 'only allow access from 9 AM to 5 PM').
They might describe a user who 'should not be able to see other users' — that is about privilege escalation prevention, which is a property of well-designed IAM.
They might use 'shared responsibility model' — remember that the customer is responsible for managing who accesses their cloud resources (IAM), even though the provider secures the infrastructure.
The cloud management plane is the central control layer where all identity and permission decisions are made, separate from the data plane where actual resources live.
Authentication answers 'Who are you?' while authorisation answers 'What can you do?' — they are two distinct steps in every access request.
The principle of least privilege means granting only the minimum permissions necessary for a user or service to perform its job function.
Roles are temporary, cross-account identities ideal for granting short-term or cross-organisation access without creating permanent user accounts.
In cloud IAM, an explicit Deny always overrides any Allow, forming the foundation of secure policy design.
Federation allows users to authenticate using their existing corporate credentials (like Microsoft Entra ID) instead of creating separate cloud accounts.
Multi-factor authentication (MFA) is a non-negotiable security control for all users with management plane access.
Service accounts (machine identities) must be managed with the same rigour as human identities to prevent automated attacks.
These come up on the exam all the time. Here's how to tell them apart.
Authentication
Answers 'Who are you?'
Usually involves passwords, MFA, or biometrics
Happens first in the access sequence
Authorisation
Answers 'What can you do?'
Involves policies and permissions
Happens after authentication is confirmed
User Identity
Permanent, long-lived identity for a person or service
Has static credentials (e.g., password or access key)
Typically used for daily, ongoing access
Role Identity
Temporary, short-lived identity assumed as needed
Has no permanent credentials; must be assumed
Ideal for cross-account access or temporary tasks
Explicit Allow
Creamission granted by a policy
Can be overridden by a Deny rule
Not sufficient alone; must not contradict a Deny
Explicit Deny
Deliberate block set by a policy
Overrides any Allow rule
Used to enforce sensitive resource protection
On-Premise IAM (Legacy)
Controlled within a company's own network
Often uses a single Active Directory domain
Users access resources only from inside the network
Cloud IAM
Managed via cloud provider's management plane
Supports federation with external identity providers
Users can access from anywhere globally
Group (IAM)
A collection of users for permission management
Users are added to groups permanently
Permissions assigned to the group apply to all members
Role (IAM)
A temporary identity that is assumed
Not a collection of users; used for short-term access
Assumed by a user or service for a specific purpose
Data Plane
Where actual resources (servers, storage, databases) live
Handles data operations (read, write, delete)
Accessed by users and applications directly
Management Plane
Central control layer for configuring resources
Handles management operations (create, modify, delete changes)
Accessed by administrators and IAM policies
Mistake
Once a user is authenticated, they can access everything in the cloud account.
Correct
Authentication only proves who you are. Authorisation, which is separate, determines what resources you can access. You can be authenticated but completely blocked from most resources.
In many old-school applications, logging in gave you access to the whole system. People mistakenly carry that mental model to the cloud, where explicit permissions are required for every action.
Mistake
IAM only applies to human users, not to computer programs or services.
Correct
IAM applies to all identities, including applications, virtual machines, and automated scripts. These non-human identities are called service accounts or system identities and must be managed just as carefully as human users.
Beginners often think of security as person-to-system. They forget that in cloud environments, machines talk to other machines, and each machine needs its own identity and permissions.
Mistake
If a user is in a group that grants 'Read' access to a file, and separately has a policy that says 'Deny' for that same file, the user gets to read the file because the Allow overrides the Deny.
Correct
In cloud IAM, a Deny rule always overrides any Allow rule. This is called 'explicit deny' and is a fundamental security principle. The user would be blocked from reading the file.
Many people think permissions work like 'the most permissive rule wins', similar to how some social media settings work. In cloud security, the opposite is true by design to prevent accidental privilege escalation.
Mistake
Multi-factor authentication (MFA) is optional and only needed for high-risk users.
Correct
MFA should be required for all human users, especially those with management plane access. The CCSP exam expects you to know that MFA is a critical defence against credential theft.
Beginners often underestimate how easy it is for passwords to be stolen through phishing, keyloggers, or data breaches. They think MFA is an inconvenience rather than an essential control.
Mistake
Once you set up IAM policies, you never need to change them.
Correct
IAM is dynamic. Users change roles, join or leave the company, and new cloud services are added. Policies must be reviewed and updated regularly — a process called access review.
People assume security is a one-time configuration, like installing a lock on a door. But cloud environments change constantly, and permissions that were appropriate six months ago might now be excessive or outdated.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The cloud management plane is the central layer of the cloud provider's system where you manage users, configure permissions, and control access. Think of it as the 'master control' interface. Every action you take to set up your cloud resources goes through the management plane.
Not necessarily. You can use federation to let employees log in using their existing corporate credentials from Microsoft Entra ID or Google Workspace. This avoids creating and managing hundreds of cloud-specific user accounts. Federation is considered a best practice for larger organisations.
A user is a permanent identity assigned to a specific person or service. A role is a temporary identity that can be assumed by a user or service for a specific task, often used to grant cross-account access or time-limited permissions. Roles do not require long-term credentials.
If a user has a policy that explicitly denies access to a resource, that Deny rule will override any Allow rule from any other policy. This is a fundamental security feature to ensure that no permissions can bypass a deliberate block. It prevents accidental privilege escalation.
A service account is an identity used by an application, virtual machine, or automated script rather than a human. It has its own permissions and credentials. For example, a web server might use a service account to read from a database. These must be managed carefully because they often have broad permissions.
Because the management plane controls everything in your cloud environment. If an attacker compromises a user with management plane permissions, they can create, modify, or delete all resources, change security policies, and lock out the real administrators. That is why MFA and strict access controls are essential for management plane users.
You've finished Cloud Management Plane and Identity Management. Continue through the CCSP study guide to build a complete picture of the exam.
Done with this chapter?