This chapter covers AWS Identity and Access Management (IAM) from a SysOps perspective, focusing on how to manage users, groups, roles, and policies to secure AWS resources. IAM is a core topic for the SOA-C02 exam, appearing in approximately 10-15% of questions across multiple domains, especially Security (Objective 4.1). Understanding IAM deeply is critical because misconfigurations are a leading cause of security incidents and a frequent source of exam scenario questions.
Jump to a section
Imagine a large corporation with multiple buildings, each containing sensitive areas like server rooms, HR files, and executive offices. The company issues a physical ID badge to every employee, contractor, and visitor. Each badge has a unique ID number and is encoded with specific permissions: which doors the holder can open and during what hours. A central security office manages badge activation, deactivation, and permission changes. When an employee swipes their badge at a door, the door's reader sends the badge ID to a central access control server. That server checks the badge's validity, whether the badge is active, and whether the holder has permission to enter that specific door at that time. The server then sends an 'unlock' or 'deny' signal back to the door. The badge itself does not grant access—it is merely a token. The central server holds the actual policy. If an employee is fired, the security office deactivates the badge instantly, and all doors will deny entry even if the badge is physically retained. Similarly, AWS IAM users have credentials (passwords, access keys) that are used to request access. IAM policies—attached to users, groups, or roles—define what actions are allowed or denied on which resources. The IAM service evaluates these policies each time a request is made, just like the central access control server. The badge (credentials) alone does not grant access; the policy evaluation engine decides based on the identity and the policy statements. This separation of authentication (badge) and authorization (policy) is fundamental to IAM.
What is IAM and Why Does It Exist?
AWS Identity and Access Management (IAM) is a web service that helps you securely control access to AWS resources. It is the primary mechanism for authentication (verifying identity) and authorization (granting permissions) in AWS. IAM is not a resource-specific service like EC2 or S3; it is a global service that operates across all AWS regions and services. This means that IAM policies are evaluated for every API call made to any AWS service.
Before IAM, AWS had only a single root account with unlimited access. This was a security nightmare. IAM was introduced to allow creation of multiple users with granular permissions, enabling the principle of least privilege. For the SOA-C02 exam, you must understand that IAM is free (no additional charge) and that it is region-agnostic—IAM resources are global, not tied to a specific region.
How IAM Works Internally
When a user or application makes an API request to AWS, the request is intercepted by the IAM policy evaluation engine. The engine performs the following steps:
Authentication: The request must include credentials (e.g., access key ID and secret access key for API calls, or a session token for temporary credentials). IAM verifies these credentials against its database. If authentication fails, the request is denied immediately with an "AccessDenied" error.
Authorization: Once authenticated, IAM determines whether the requester is authorized to perform the requested action on the specified resource. This involves evaluating all applicable policies:
- Identity-based policies (attached to the user, group, or role) - Resource-based policies (attached to the resource, e.g., S3 bucket policy) - IAM permissions boundaries - AWS Organizations service control policies (SCPs) - Session policies (for assumed roles)
Policy Evaluation Logic: IAM uses a default-deny model. By default, all requests are denied. An explicit allow overrides a default deny. An explicit deny overrides any allow. The evaluation follows this order:
If there is an explicit deny, the request is denied.
If there is an explicit allow and no explicit deny, the request is allowed.
If there is neither explicit allow nor deny, the request is denied (default deny).
Decision: The engine returns either "Allow" or "Deny". This decision is logged in AWS CloudTrail for auditing.
Key Components and Defaults
Users: Represent a person or service that needs long-term access. Each user has a friendly name, a unique Amazon Resource Name (ARN), and can have up to two access keys. By default, a new user has no permissions—no policies are attached.
Groups: A collection of users. Groups are not a true identity; they cannot be used for authentication. Instead, they simplify permission management. A user can belong to up to 10 groups. There is no default group.
Roles: An identity that can be assumed by trusted entities (users, AWS services, or external identities). Roles have temporary credentials issued via AWS Security Token Service (STS). The default maximum session duration for a role is 1 hour, but can be set from 15 minutes to 12 hours.
- Policies: JSON documents that define permissions. There are two types: - Managed policies: Standalone policies that can be attached to multiple entities. AWS provides over 500 AWS managed policies. Customer managed policies are created by you. - Inline policies: Policies embedded directly into a user, group, or role. They are not reusable.
Policy size limit: 6,144 characters for user/group/role inline policies, 5,120 characters for managed policies. The total policy size per account is limited to 1,024 policies (managed) and 1,536 roles.
Permissions Boundary: A managed policy used to set the maximum permissions that an identity-based policy can grant. It does not grant permissions by itself; it only limits the scope. Useful for delegating permission management to developers.
Service Control Policies (SCPs): Used in AWS Organizations to set permission guardrails for accounts. SCPs affect all users and roles in an account, including the root user (but root user cannot be restricted by SCP? Actually, root user is not affected by SCPs—this is a common exam trap).
Configuration and Verification Commands
Using the AWS CLI, you can manage IAM resources. Common commands:
# Create a user
aws iam create-user --user-name Alice
# Attach a managed policy to a user
aws iam attach-user-policy --user-name Alice --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
# Create an access key
aws iam create-access-key --user-name Alice
# List attached policies for a user
aws iam list-attached-user-policies --user-name Alice
# Simulate policy to test permissions
aws iam simulate-principal-policy --policy-source-arn arn:aws:iam::123456789012:user/Alice --action-names s3:ListBucketHow IAM Interacts with Other Services
CloudTrail: All IAM API calls are logged. You can use CloudTrail to audit policy changes, user creations, and access key usage.
AWS STS: Used by roles to issue temporary credentials. STS endpoints are global (sts.amazonaws.com) but you can use regional endpoints to reduce latency.
AWS Organizations: SCPs are applied to accounts to enforce permission boundaries. They are evaluated before IAM policies.
Amazon S3: S3 bucket policies are resource-based policies that can grant cross-account access. IAM users from other accounts can access the bucket if the bucket policy allows and the user's identity-based policy also allows.
AWS KMS: Key policies control access to KMS keys. They work similarly to resource-based policies.
Exam-Relevant Details
Root User: The root user has full, unrestricted access. It is recommended to enable multi-factor authentication (MFA) on the root account, create an IAM admin user, and do not use root for daily tasks. The root user can perform some actions that IAM users cannot, such as closing the account, changing account settings, and creating IAM users (actually, IAM users can create other IAM users if they have the iam:CreateUser permission; root can always do it).
IAM Best Practices: The exam expects you to know the IAM best practices: use groups, assign least privilege, use roles for EC2, enable MFA, rotate access keys regularly, use conditions in policies, and use policy conditions like aws:SourceIp to restrict access by IP.
IAM Policies Evaluation: You must understand the difference between identity-based and resource-based policies. For cross-account access, both the identity-based policy of the requesting account and the resource-based policy of the resource account must allow the action.
IAM Roles for EC2: An EC2 instance can assume an IAM role by launching it with an instance profile. The instance profile contains the role. The AWS CLI on the instance automatically retrieves temporary credentials from the instance metadata service (IMDS). The default IMDS endpoint is http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name.
IAM Policy Conditions: Common conditions: aws:SourceIp (IP address), aws:RequestedRegion (region), aws:MultiFactorAuthPresent (MFA), aws:CurrentTime (time-based). These are used to implement security controls.
Common Exam Scenarios
Cross-account access: You need to allow a user from Account A to access an S3 bucket in Account B. You must create an IAM role in Account B that grants access to the bucket, and then allow the user in Account A to assume that role. Alternatively, use a resource-based policy (bucket policy) on the S3 bucket in Account B that grants access to the user in Account A. The exam will ask which approach to use based on the service (S3 supports resource-based policies; EC2 does not).
EC2 Role vs. Access Keys: Never store access keys on an EC2 instance; use an IAM role. The exam will test this as a best practice.
Permissions Boundaries: Used to limit the maximum permissions that can be granted to a user or role. For example, a developer can create roles for Lambda functions, but you can set a permissions boundary to ensure those roles cannot access DynamoDB tables.
IAM Policy Simulator: A tool to test and troubleshoot policies. The exam may ask you to use it to determine why a user is getting an access denied error.
Conclusion
IAM is the bedrock of AWS security. As a SysOps administrator, you will spend a significant amount of time managing IAM policies, roles, and users. The SOA-C02 exam tests both conceptual understanding and practical application. Master the policy evaluation logic, the differences between policy types, and the best practices for securing access.
Create an IAM User
To create an IAM user, you use the AWS Management Console, CLI, or API. In the console, navigate to IAM > Users > Add user. Provide a username (e.g., 'sysops-admin'). Select 'Programmatic access' and/or 'AWS Management Console access'. For console access, set a password (auto-generated or custom) and optionally require MFA. The user is created with no permissions by default. After creation, you receive an access key ID and secret access key (for programmatic access) or a console login URL. You must securely store these credentials. On the exam, remember that a new user has no permissions; you must attach a policy or add to a group.
Attach a Managed Policy
To grant permissions, you attach a policy. For example, to give the user read-only access to EC2, attach the AWS managed policy 'AmazonEC2ReadOnlyAccess'. In the console, go to Users > select the user > Permissions > Add permissions > Attach existing policies directly. Search for the policy and select it. The policy is a JSON document with statements. For instance, the policy contains: 'Effect': 'Allow', 'Action': 'ec2:Describe*', 'Resource': '*'. This allows all Describe actions on EC2. The policy is evaluated when the user makes API calls. The exam tests that you know how to attach policies and that managed policies are easier to manage than inline.
Create an IAM Group
Groups simplify permission management. Create a group named 'EC2Admins' and attach the 'AmazonEC2FullAccess' policy. Then add the user to the group. In the console, go to IAM > Groups > Create New Group. Name it, select policies, then create. To add users, select the group, go to Users, and add existing users. A user can belong to up to 10 groups. The group's permissions are inherited by all members. If you remove a user from the group, they lose those permissions. The exam expects you to use groups for managing permissions rather than attaching policies directly to users.
Create an IAM Role for EC2
To allow an EC2 instance to access AWS services, create an IAM role. In the console, go to IAM > Roles > Create role. Select 'AWS service' and choose 'EC2'. Then attach a policy, e.g., 'AmazonS3ReadOnlyAccess'. Name the role 'EC2-S3-ReadOnly'. After creation, you can launch an EC2 instance and assign this role by selecting the IAM role in the instance launch wizard (under 'Configure Instance Details' > 'IAM role'). The instance automatically obtains temporary credentials via the instance metadata service. The credentials are rotated automatically. This is more secure than storing access keys on the instance. The exam will test that you should always use roles for EC2.
Test Permissions with Policy Simulator
The IAM Policy Simulator helps troubleshoot permission issues. In the console, go to IAM > Policy Simulator. Select a user, group, or role and specify actions (e.g., s3:ListBucket) and resources. The simulator evaluates the policies and returns 'allowed' or 'denied' with the reason. For example, if a user is denied access to an S3 bucket, you can simulate to see which policy is causing the deny. The exam may present a scenario where a user cannot access a resource, and you need to use the simulator to identify the issue. The simulator respects all policy types, including SCPs and permissions boundaries.
In a typical enterprise, IAM is used to enforce least privilege across hundreds of users and thousands of resources. Consider a scenario where a company has multiple teams: developers, operations, and finance. Each team needs different levels of access. For example, developers need write access to S3 buckets for deployment artifacts, but only read access to production databases. Operations needs full access to EC2 and CloudWatch, but no access to billing. Finance needs read-only access to cost reports.
To manage this, the SysOps admin creates IAM groups: 'Developers', 'Operations', 'Finance'. Each group is attached to appropriate AWS managed policies and additional customer managed policies for fine-grained control. For instance, the Developers group gets 'AmazonS3FullAccess' but with a condition that restricts write access to specific buckets using aws:ResourceTag/Environment condition. The Operations group gets 'AmazonEC2FullAccess' and 'CloudWatchFullAccess'. The Finance group gets 'AWSBillingReadOnlyAccess'.
Another common scenario is using IAM roles for cross-account access. Suppose the company acquires another startup and needs to grant the startup's developers read-only access to a shared S3 bucket in the parent account. The SysOps admin creates an IAM role in the parent account with a trust policy that allows the startup's AWS account to assume the role. The role has an attached policy granting read-only access to the bucket. The startup's developers then assume the role using STS AssumeRole API. This avoids sharing access keys and provides granular control.
A third scenario is using IAM permissions boundaries to delegate permission management to team leads. For example, the central IT team creates a permissions boundary policy that allows only EC2 and S3 actions, but not IAM actions. They then allow team leads to create IAM roles for their applications, but those roles must have the permissions boundary attached. This ensures that even if a team lead creates a role with a permissive policy, the permissions boundary limits the maximum scope.
Misconfigurations often occur when policies are too permissive (e.g., using '*' for resources) or when users are accidentally granted admin access. Another common mistake is forgetting to attach a policy to a user, leading to access denied errors. The exam will test your ability to identify and fix these issues.
The SOA-C02 exam tests IAM under Objective 4.1 (Security) and also in other domains like Troubleshooting. Key exam areas:
Policy Evaluation Logic: You MUST know the order of evaluation: explicit deny overrides allow, default deny. The exam will present scenarios where a user has multiple policies and ask what the effective permission is. For example, if a user has an allow policy for s3:GetObject on bucket A, but a group policy denies s3:GetObject on all buckets, the result is deny.
IAM Roles vs. Resource-Based Policies: For cross-account access, the exam will ask which method to use. Remember: S3, SNS, SQS support resource-based policies; EC2, Lambda, RDS do not. For those services, you must use roles.
Permissions Boundaries: The exam loves to test that a permissions boundary does not grant permissions; it only sets the maximum. If a user has a policy that allows s3:ListBucket but the permissions boundary does not allow it, the action is denied.
SCPs and Root User: Common trick: SCPs apply to all IAM users and roles in an account, but NOT to the root user. The root user can bypass SCPs.
IAM Best Practices: The exam will ask about best practices: use groups, rotate keys, enable MFA, use roles for EC2, use conditions. Be prepared to select the 'most secure' option.
Common Wrong Answers:
Choosing 'Create an IAM user and share the access keys' instead of 'Create an IAM role' for cross-account access.
Thinking that attaching a policy to a group automatically creates a role (it does not).
Believing that SCPs can be used to restrict root user actions (they cannot).
Selecting 'Use inline policies instead of managed policies' when the question asks for ease of management (managed policies are easier).
Numbers to Memorize:
Maximum session duration for a role: 12 hours (default 1 hour).
Maximum number of access keys per user: 2.
Maximum number of groups a user can belong to: 10.
Maximum policy size: 6,144 characters (inline), 5,120 characters (managed).
Maximum number of managed policies per account: 1,024.
Edge Cases:
If a user is denied by an SCP, they cannot access the resource even if an IAM policy allows.
If a role is assumed, the original user's permissions are not used; the role's permissions apply.
A user can be a member of a group in a different account? No, groups are account-specific.
To eliminate wrong answers, apply the policy evaluation logic: look for explicit denies first. If there is any deny, the answer is deny. Also, consider whether the service supports resource-based policies.
IAM uses a default-deny model; explicit allow overrides default deny, explicit deny overrides any allow.
New IAM users have no permissions; you must attach policies or add to groups.
Use IAM roles for EC2 instances instead of storing access keys.
Cross-account access: use IAM roles for services that do not support resource-based policies (e.g., EC2, Lambda).
Permissions boundaries limit maximum permissions but do not grant them.
SCPs do not apply to the root user.
Maximum session duration for a role: 12 hours (default 1 hour).
A user can belong to up to 10 groups.
These come up on the exam all the time. Here's how to tell them apart.
IAM Role
Used by AWS services (EC2, Lambda) or external identities.
Provides temporary credentials via STS.
No long-term access keys.
Can be assumed by multiple entities.
Recommended for cross-account access.
IAM User
Represents a person or application with long-term access.
Has permanent credentials (password, access keys).
Can have up to two access keys.
Best for human users or applications that need static credentials.
Not recommended for cross-account access (use role instead).
Mistake
IAM users can be created with default permissions that allow limited access.
Correct
New IAM users have NO permissions at all. You must explicitly attach policies or add them to a group.
Mistake
A permissions boundary grants permissions to a user or role.
Correct
A permissions boundary only sets the maximum permissions that can be granted by an identity-based policy. It does not grant any permissions by itself. The user still needs an identity-based policy that allows actions within the boundary.
Mistake
Service Control Policies (SCPs) can restrict the root user of an account.
Correct
SCPs do not apply to the root user. The root user has full access regardless of SCPs. SCPs only affect IAM users and roles (including the root user? No, root is exempt).
Mistake
An IAM group is a true identity and can be used as a principal in a policy.
Correct
Groups are not identities; they are containers for users. You cannot use a group ARN as a principal in a resource-based policy. Only users and roles can be principals.
Mistake
When an EC2 instance assumes a role, the temporary credentials are stored permanently on the instance.
Correct
Temporary credentials are obtained from the instance metadata service and are rotated automatically. They are not stored permanently. The credentials expire (default 6 hours for EC2 roles) and are refreshed transparently by the AWS SDK.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An IAM user represents a person or service that needs long-term access and has permanent credentials (password, access keys). An IAM role is an identity that can be assumed by trusted entities (AWS services, users, or external identities) and provides temporary credentials via AWS STS. Roles do not have permanent credentials. Use users for human users or applications that need static credentials; use roles for EC2 instances, Lambda functions, or cross-account access.
You have two options: (1) Use a resource-based policy (S3 bucket policy) on the bucket in Account B that grants access to the user in Account A. (2) Use an IAM role in Account B that the user in Account A can assume. The bucket policy method is simpler and does not require the user to assume a role. However, if the service does not support resource-based policies (e.g., EC2), you must use a role. On the exam, S3 supports bucket policies, so either method works, but the bucket policy is often preferred for simplicity.
A permissions boundary is a managed policy that sets the maximum permissions that an identity-based policy can grant to a user or role. It does not grant permissions by itself; it only limits the scope. For example, you can create a permissions boundary that allows only EC2 and S3 actions. Then, when you create a role, you attach this boundary. Even if the role's identity-based policy allows IAM actions, the boundary denies them. Permissions boundaries are useful for delegating permission management to developers while maintaining security guardrails.
It is not recommended. Each application should have its own IAM user or role to follow the principle of least privilege and for auditing. If you use a single user, you cannot revoke permissions for one application without affecting others. Instead, create separate IAM users or roles for each application, and use groups to manage common permissions.
Policy changes take effect immediately. There is no propagation delay. When you update a policy, the new permissions are applied to all entities that have that policy attached. This is important for security: if you deny an action, the denial is effective instantly. However, existing sessions may still be valid if they have temporary credentials; the new policy applies to new requests.
Use a condition in the IAM policy with the `aws:SourceIp` condition key. For example: 'Condition': { 'IpAddress': { 'aws:SourceIp': '203.0.113.0/24' } }. This restricts the user to making requests only from that IP range. This is commonly used for administrative users who must connect from a corporate network.
Inline policies are directly embedded into a user, group, or role. They are not reusable and are deleted when the entity is deleted. Managed policies are standalone policies that can be attached to multiple entities. AWS provides managed policies (e.g., AdministratorAccess) and you can create customer managed policies. Managed policies are easier to manage and update because you can change the policy and the changes apply to all entities attached. Inline policies are useful for one-off permissions that should be tightly coupled to an entity.
You've just covered IAM for SysOps — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?