Identity and Access Management at Scale solves the problem of allowing thousands of people and automated systems to access hundreds of cloud resources across multiple AWS accounts without compromising security or slowing down productivity. For someone studying SAP-C02, understanding this concept is crucial because the exam heavily tests how to design secure, scalable access strategies that work for large organisations, where a single mistake can expose sensitive data across dozens of accounts.
Jump to a section
A simple way to picture Identity and Access Management at Scale
A city builds a new apartment building with 100 units, so they must create a master key system that lets residents enter only their own flat while allowing the building manager to access every unit and the postman to access only the ground-floor mail room. This leads to a situation where a single master key, if lost, could compromise the entire building, so the city implements a system of individual flat keys, a manager master key, and a separate mail-room key, each with specific permissions. Each tenant receives a key that unlocks precisely their door and the main entrance, nothing more. The manager, however, carries a master key that opens every flat, plus a basement key for the boiler room. The postman has a key only for the mail room, not any flat. When a tenant moves out, the locksmith re-keys that flat without affecting any other key. This real-world scenario maps directly to AWS Identity and Access Management at Scale: a large company with many accounts is like the building; each account is a flat; the master key is a cross-account IAM role; re-keying a flat is like rotating access keys. The system must scale: the building might have 10,000 flats, just as a large enterprise might have hundreds of AWS accounts, each needing precise access rules without giving everyone a single skeleton key.
Crucially, the building's key system also includes a logbook at the main entrance that records which key was used to enter at what time. This is the AWS CloudTrail log, which tracks every access request. If a manager uses their master key to enter a flat when they shouldn't, the logbook reveals the breach. The system also has a rule: keys can be temporarily delegated. For example, the manager can give the postman a one-use key to the mail room if the mail room door is stuck, but that key expires automatically after one hour. This is an IAM role with a session policy and a time limit. The entire system is designed so that no single keyholder can accidentally access a unit they shouldn't, and if they do, there is an audit trail.
Identity and Access Management, or IAM, is the system AWS uses to control who can do what with your cloud resources. At its core, IAM involves three main concepts: a user, a group, and a policy. A user is a person or application that needs access. A group is a collection of users who share the same access needs, like all software engineers. A policy is a JSON document that defines what actions a user or group can perform on which resources. For example, a policy might say: 'Allow user Alice to start and stop EC2 instances, but only in the London region.' Policies are attached to users or groups to grant permissions.
Now, when you have only one AWS account and ten employees, IAM is straightforward: you create a user for each employee, put them in groups, and attach policies. But for a large enterprise with 50,000 employees, hundreds of applications, and dozens of AWS accounts, managing that manually becomes impossible. This is where 'Identity and Access Management at Scale' comes in. The key idea is to separate the concept of who you are (authentication) from what you are allowed to do (authorisation). Instead of creating a separate IAM user in every account for each employee, you use a central identity provider, often called an IdP. The IdP is a service that stores all employee identities in one place, like Microsoft Entra ID (formerly Azure Active Directory) or AWS IAM Identity Center (successor to AWS SSO).
When an employee logs into AWS, they authenticate against the IdP, not against each individual account. The IdP then hands them a temporary security credential, much like a digital ticket, that allows them to assume an IAM role in a specific AWS account. An IAM role is similar to a user but is designed to be assumed by anyone who gets permission, rather than being tied to a single person. The role has a set of policies attached to it that define what the *role* can do, not the person. This means you can create one role called 'Developer' in the production account that allows read-only access to databases, and another role called 'Admin' in the management account that allows full access. The employee assumes the appropriate role based on their job function, which is defined in the IdP.
This approach replaces the old method of managing dozens of IAM users in each account, which was error-prone and insecure. At scale, you also need to manage access for automated systems, like a continuous integration (CI) server that deploys code. These systems use IAM roles, not users. The CI server, running on an EC2 instance, assumes an IAM role through a feature called an Instance Profile, which grants the server temporary credentials automatically. This avoids storing long-term access keys on the server, a common security vulnerability.
Why does this matter at scale? Because without this centralised approach, you would have to:
Create and manage an IAM user for each employee in every account they need to access.
Rotate passwords for each user manually.
Track which users are still active across dozens of accounts.
Deal with the risk of users sharing passwords when they forget them.
IAM Identity Center solves all of this by providing a single sign-on (SSO) portal where employees see only the accounts they have permission to access. The same principle applies to cross-account access: you can grant a user in Account A access to a resource in Account B by creating a role in Account B that trusts the IAM Identity Center or a specific IAM user from Account A. This is called cross-account IAM roles, and it is tested heavily in SAP-C02.
To make this concrete, here are the core components you will encounter:
IAM Roles: A set of permissions that can be assumed by users, applications, or AWS services. Unlike IAM users, roles do not have permanent credentials. They issue temporary security tokens through the AWS Security Token Service (STS).
IAM Identity Center: The central service for managing user access to multiple AWS accounts and business applications. It integrates with external IdPs like Microsoft Entra ID or Okta.
Permission Sets: In IAM Identity Center, a permission set is a collection of policies that you assign to users for a specific account. For example, a 'ReadOnly' permission set might be assigned to all developers for the staging account.
Service Control Policies (SCPs): These are policies that manage permissions at the organisation level, not at the account level. They act as a central guardrail, limiting what IAM policies can grant in child accounts. For instance, you can create an SCP that denies access to all services that are not approved, like denying use of the 'us-east-1' region for all accounts in your organisation.
Identity Federation: The process of allowing users from an external identity system (like Microsoft Entra ID) to access AWS resources without creating an IAM user in AWS. This is done through SAML 2.0 (Security Assertion Markup Language) or OIDC (OpenID Connect).
At scale, you must also consider the principle of least privilege: give each user or role only the minimum permissions necessary to do their job. This is hard to enforce manually, but tools like IAM Access Analyzer can review policies and suggest more restrictive ones. The exam tests your ability to design a strategy that uses IAM Identity Center, SCPs, and cross-account roles to manage access across hundreds of accounts, all while ensuring audit trails are maintained via CloudTrail and AWS Config.
Finally, you must understand the resource-based policies versus identity-based policies. An identity-based policy is attached to a user, group, or role and defines what they can do. A resource-based policy is attached to a resource itself, like an S3 bucket, and defines who can access it. For cross-account access, you often need both: the role in Account A must have an identity-based policy allowing access to the S3 bucket, and the S3 bucket must have a resource-based policy granting access to that role. This two-way permission check is a classic exam trap, so we will cover it in the exam focus section.
Establish a Central Identity Source
Begin by connecting your existing identity directory (like Microsoft Entra ID, Okta, or an on-premises Active Directory) to AWS IAM Identity Center. This synchronises your users and groups into AWS, giving you a single source of truth for who your employees are. This is the foundation, as without it you would have to manually create users in every account.
Define Permission Sets in IAM Identity Center
Create permission sets that represent job functions, such as 'ReadOnlyAccess', 'DatabaseAdmin', or 'NetworkEngineer'. Each permission set contains one or more IAM policies that define what actions are allowed. For example, a 'ReadOnlyAccess' permission set might include the AWS managed policy 'ReadOnlyAccess'. This step separates the policy definition from the user assignment, allowing scalability.
Assign Users to Accounts via Permission Sets
In IAM Identity Center, assign a user or group to one or multiple AWS accounts with a specific permission set. For instance, you assign the 'Developers' group to the 'Staging' account with the 'ReadOnlyAccess' permission set. This creates an IAM role in the target account behind the scenes, which the user can assume. The assignment is centralised, so you do not need to log into each account.
Configure Service Control Policies at the Organisation Level
Use AWS Organizations to create and attach SCPs to OUs (Organisational Units) or the root of the organisation. For example, attach an SCP that denies all actions in non-approved regions. This acts as a safety net, ensuring that even if a permission set grants region access, the SCP can block it. This step is critical for preventing accidental data exfiltration or compliance violations.
Set Up Cross-Account Roles for Applications
For automated processes (like a CI/CD pipeline running in one account that needs to deploy to another), create an IAM role in the target account with a trust policy that allows the source account's role to assume it. Then attach the necessary policies to the target role. This avoids storing long-term keys in the application. Finally, test the access using the AWS CLI or SDK.
Implement Monitoring and Access Reviews
Enable AWS CloudTrail to record all IAM actions and cross-account role usage. Use IAM Access Analyzer to generate reports of any unintended public access. Schedule quarterly access reviews using IAM Credential Report to identify and disable inactive users or keys. This ensures the system remains secure as the organisation evolves.
Let us walk through the day of Priya, a cloud security architect at a global retail company with 200 AWS accounts, 5,000 employees, and 2,000 automated applications. Priya's job is to design and maintain the access management strategy so that employees can get their work done without creating security holes.
Priya starts her morning by checking a report from AWS IAM Access Analyzer, which alerts her to a policy that grants broad access to an S3 bucket containing customer data. The policy allows anyone from another account to read the bucket, which is a risk. She revises the policy to use least privilege: she changes it to allow access only from a specific IAM role used by the data analytics team, and only for reading, not writing. She then tests the policy using IAM Policy Simulator before deploying it.
Next, her team receives a request from a new project: the mobile app team needs temporary access to a production database to investigate a bug. Instead of creating a permanent IAM user for each team member, Priya sets up a cross-account IAM role. She creates a role in the production account called 'ProdDatabaseAuditor' with a policy that allows only SELECT queries to that specific database. She then configures IAM Identity Center to allow members of the mobile app team to assume this role, but only for the next 8 hours by adding a session duration limit. She also adds a condition in the role's trust policy that requires the user to have multi-factor authentication (MFA) enabled.
Later, the company acquires a smaller startup that has its own AWS accounts. Priya must integrate their accounts into the existing organisation. She uses AWS Organizations to create a new organisational unit (OU) for the acquired accounts, then attaches a Service Control Policy (SCP) that denies access to all services outside of a pre-approved list, like denying the use of AWS Lambda in China regions. She also sets up IAM Identity Center to propagate the same permission sets to the new accounts, so that existing employees can access them immediately without additional setup.
At 2 PM, a developer reports that their CI/CD pipeline (a system that automatically builds and deploys code) is failing because it cannot access a new S3 bucket. Priya investigates and finds that the CI server uses an IAM role attached to its EC2 instance via an Instance Profile. She updates the role's policy to include permissions for the new bucket, then uses CloudTrail to verify that the role is being assumed correctly and not using static credentials.
Finally, at the end of the day, Priya reviews the quarterly access review. She runs a script that uses AWS IAM Credential Report to list all IAM users that have not logged in for 90 days and deactivates them. She also checks for any IAM users that have long-term access keys; she replaces those keys with roles and notifies the owners. She then generates a report using AWS Config to verify that no resource-based policies, like S3 bucket policies, grant public access. The entire daily process involves:
Using IAM Identity Center for user management.
Applying SCPs at the organisation level.
Creating cross-account roles with temporary credentials.
Using IAM Access Analyzer for policy validation.
Monitoring with CloudTrail and Config.
Automating key rotation and inactive user detection.
This scenario is exactly what an experienced professional does, and it mirrors the design challenges the SAP-C02 exam tests.
The SAP-C02 exam loves to test your ability to design an identity strategy that scales across many accounts. The domain 'Design Secure Access Management Strategies Across Accounts and Identities' is a key part of the exam, often worth several scenario-based questions. Here is what you need to focus on:
First, understand the difference between IAM Identity Center and IAM users in a single account. The exam will never ask you to create a separate IAM user in each account for a large company. The correct answer pattern for almost any multi-account question is: use IAM Identity Center with external identity federation (e.g., Microsoft Entra ID). The trap is that you might be tempted to create IAM users in each account, which is a security and management nightmare. The correct answer will always involve centralising identity and using roles with temporary credentials.
Second, Service Control Policies (SCPs) are a favourite topic. You must know that SCPs are not IAM policies; they are a guardrail that limits what IAM can grant in child accounts. They cannot grant permissions, only deny or allow them, and they do not affect the management account. A classic exam question: 'You want to prevent all accounts in an organisation from using a specific service. What do you do?' The answer is: attach an SCP to the root OU that denies access to that service. The trap is that beginners try to create an IAM policy for each account, which is not scalable.
Third, cross-account access questions test your understanding of resource-based policies versus identity-based policies. A classic trap: 'A user in Account A wants to access an S3 bucket in Account B. Which policies must be in place?' Many candidates say only the bucket policy, but the correct answer is both: the user must have an identity-based policy allowing s3:GetObject, and the bucket must have a resource-based policy granting access to that user or role. The exam uses this pattern repeatedly, often with a twist where the user has permissions but the bucket denies because of a missing policy.
Fourth, the concept of permission sets in IAM Identity Center. You will see questions where an administrator has multiple accounts and needs to assign read-only access to some developers and full access to others. The correct approach is to create two permission sets: one with a read-only policy and one with an administrator policy, then assign them to the appropriate users via groups in the IdP. The trap is that beginners try to create a separate role for each user, which does not scale.
Fifth, IAM conditions are heavily tested. You need to know how to restrict access based on MFA, IP address, time of day, or resource tags. For example, a question might ask: 'A company requires all access to production accounts to come from a specific IP range and require MFA. How do you enforce this?' The answer is to add a condition block in the IAM role's trust policy that checks the aws:SourceIp and aws:MultiFactorAuthPresent keys. The trap is that they might suggest using an SCP, which cannot check IP addresses at that level.
Here are the specific exam topics and traps to memorise:
IAM Identity Center vs. IAM users: Always prefer Identity Center for multiple accounts.
SCPs can only define the maximum permissions, never grant.
Cross-account roles require both a role in the target account and a policy in the source account.
Resource-based policies can grant access to external accounts directly, but identity-based policies must be combined with a resource-based policy for cross-account.
Permission sets are collections of one or more policies assigned to a group in a specific account.
Conditions: aws:SourceIp, aws:MultiFactorAuthPresent, aws:PrincipalOrgID, aws:ResourceTag.
IAM Access Analyzer can identify unintended public access to resources.
CloudTrail logs all IAM actions and is essential for auditing who assumed which role.
Finally, the exam loves to test the concept of 'delegation of administration'—how to allow a central security team to manage IAM policies across accounts without giving them full admin rights. The answer is to create a role in each account with a policy that allows only IAM-related actions, and then grant the security team permission to assume that role via IAM Identity Center.
You will also encounter questions about 'service-linked roles'—these are roles created by AWS services themselves, like the IAM role for Amazon Macie or AWS Config. The exam might ask who can modify them, and the answer is only the linked service can, not the user.
To prepare, practise drawing a mental map: user logs into IdP -> assumes a role via Identity Center -> gets temporary credentials -> applies to cross-account access. Understand that all of this is stateless and centralised, which is the key to scaling.
IAM Identity Center is the central service for managing human access to multiple AWS accounts and replaces the need for individual IAM users for employees.
Service Control Policies (SCPs) act as a central permission guardrail across all accounts in an AWS Organisation and can deny or allow actions but never grant them.
Cross-account access always requires both an identity-based policy in the source account and a resource-based policy in the target account unless using role assumption.
Temporary security credentials from AWS STS (Security Token Service) are more secure than long-term keys because they have a limited lifetime and are automatically rotated.
The principle of least privilege should be enforced using IAM conditions like MFA, IP address ranges, and resource tags to scope down permissions precisely.
Auditing all identity access is done via AWS CloudTrail, which logs every call to the IAM and STS APIs, allowing you to trace who assumed which role and when.
These come up on the exam all the time. Here's how to tell them apart.
IAM User
Has a permanent password and up to two access keys that never expire unless rotated manually.
Tied to one specific identity, like a person or application, and cannot be assumed by others without sharing credentials.
Best used for long-term machine access or a break-glass account for emergencies.
IAM Role
Issues temporary security credentials via STS that expire after a configurable duration, reducing risk.
Can be assumed by any authorised user, application, or AWS service, allowing flexible delegation.
Best used for human access via federation and for granting cross-account permissions to applications.
Identity-Based Policy
Attached to an IAM user, group, or role to grant permissions for actions on resources.
Defines what the identity can do across all resources that allow those actions.
Only supports granting permissions to the identity it is attached to; does not allow cross-account access on its own.
Resource-Based Policy
Attached directly to a resource like an S3 bucket or an SQS queue to define who can access it.
Defines which principals (users, roles, accounts) can perform actions on that specific resource.
Can grant access to identities in other AWS accounts without requiring an IAM role in the resource's account.
AWS Organizations SCP
Applies at the organisation, OU, or account level, affecting all users and roles in that scope.
Cannot grant permissions; it can only allow or deny actions, acting as a filter.
Does not affect the management account of the organisation.
IAM Policy
Applies to a specific IAM entity (user, group, role) within a single account.
Can grant or deny permissions; it is the primary mechanism for giving access.
Affects only the entity it is attached to, within its own account.
Mistake
I can just create one IAM user per employee in the main account and give that user access to all other accounts via cross-account roles. That keeps it simple.
Correct
You should never create IAM users for employees except for break-glass scenarios. Instead, use IAM Identity Center with an external identity provider. IAM users are for applications or long-term service accounts, not humans. Managing passwords and rotating keys for hundreds of IAM users is not scalable and is less secure than using temporary credentials from a central IdP.
This mistake is common because beginners start with small setups where they directly create a few IAM users. They carry that mindset to larger environments, not realising that IAM users are meant for machine access, not human users at scale.
Mistake
Service Control Policies can grant permissions to accounts in my organisation.
Correct
SCPs can only define an upper boundary on what permissions IAM policies can grant. They cannot grant access themselves. To grant access, you still need to attach identity-based or resource-based policies. SCPs are like a filter that blocks permissions that go beyond your rules.
This error arises because SCPs are often described as 'managing permissions', which misleads people into thinking they grant access. In reality, they are a guardrail, not a faucet.
Mistake
If I attach a resource-based policy to an S3 bucket granting access to an external account, that account's users can access the bucket without any additional setup.
Correct
While the S3 bucket policy allows access, the user in the external account must still have an identity-based policy from their own account that allows s3:GetObject (or similar action). Cross-account access requires a two-way permission check: both the resource policy and the user's permissions must allow it.
Beginners think because the bucket is 'public' to an account, the user automatically has access. They forget that the user still needs to be authorised by their own account to perform the action.
Mistake
IAM roles and IAM users are interchangeable for human access.
Correct
Roles are designed to be assumed temporarily and issue short-lived credentials, while users have long-term credentials (password and access keys). For human access, always use roles via federation, never create IAM users. Roles are also used by AWS services (like EC2) to get temporary access.
This confusion comes from the similar names and the fact that both can grant permissions. But the exam emphasises roles for automated and federated access, and users for cases where long-term credentials are absolutely necessary (like a backup admin).
Mistake
To revoke a user's access to all accounts, I should delete the IAM user from each account individually.
Correct
With IAM Identity Center, you disable the user in the central identity provider (e.g., Microsoft Entra ID), and within minutes the user loses access to all accounts automatically without touching any AWS account. Deleting IAM users in each account is inefficient and error-prone.
This misconception persists because people trained in on-premises Active Directory think in terms of individual resource management. The cloud's centralised identity model is a paradigm shift they haven't internalised.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
IAM is the service that defines users, groups, and policies within a single AWS account. IAM Identity Center is a separate service that allows you to manage user access across multiple AWS accounts and applications from one place, integrating with external identity providers like Microsoft Entra ID.
You need to create a cross-account role in the account that owns the S3 bucket, with a policy allowing the necessary actions. The user in the other account must then assume that role. Alternatively, you can set a resource-based policy on the S3 bucket itself that grants access to the user's IAM user or role, but the user's account must also allow the action in their own policy.
An SCP is a policy that defines the maximum permissions for all accounts in an AWS Organisation. It cannot grant permissions, only allow or deny them. IAM policies are attached to users, groups, or roles and define what those entities can do within a single account. SCPs act as a guardrail above IAM policies.
No. For human users, you should use IAM Identity Center with an external identity provider. This allows users to sign in with their corporate credentials and assume roles in the accounts they need. IAM users are best for long-term machine access, such as for automated scripts or third-party integrations.
You can add a condition to the trust policy of the IAM role that users assume in the production account, requiring the key 'aws:MultiFactorAuthPresent' to be true. You can also enforce this via an SCP that denies actions if MFA is not present, but using a condition in the role itself is more direct.
A permission set is a collection of one or more IAM policies that define a set of permissions. You create a permission set once, then assign it to users or groups for specific AWS accounts. For example, you might have a 'ReadOnly' permission set that you assign to all developers for the development account.
You've finished Identity and Access Management at Scale. Continue through the SAP-C02 study guide to build a complete picture of the exam.
Done with this chapter?