Study guide
Technical reference and lesson notes
Purpose of This Lesson
The AWS IAM Policy Simulator helps you determine whether an IAM user, group, or role is allowed to perform specific AWS API actions. It is particularly useful when permissions come from multiple sources, such as identity policies, group membership, inline policies, and permissions boundaries.
The simulator can also evaluate a policy before you attach it to an identity. This makes it useful for validating least-privilege designs and troubleshooting unexpected AccessDenied results without repeatedly changing production IAM policies.
Key Concepts
Existing Policies Mode
In existing policies mode, the simulator evaluates the policies currently associated with the selected IAM principal:
- IAM users
- IAM groups
- IAM roles
- Inline policies
- Managed policies associated with the principal or its groups
- Permissions boundaries, where applicable
The result represents the effective permissions for the selected context. For example, a user may have an inline policy allowing a few Amazon S3 and Amazon EC2 actions while all other tested actions are denied.
New Policy Mode
New policy mode provides a policy sandbox. You can enter or modify a policy and simulate its effect before attaching it to a user, group, or role.
This is useful for questions such as:
- Does the policy allow the intended API actions?
- Did removing an action create an unintended denial?
- Does the policy grant broader access than required?
- Does a proposed policy support a least-privilege design?
Selecting Actions
The simulator lets you select an AWS service and either test individual API actions or select all available actions for that service. Testing all actions can quickly reveal the scope of a policy, while testing specific actions is more practical when troubleshooting one failed operation.
For example, a policy might allow selected Amazon S3 actions such as retrieving objects or listing buckets, while denying unrelated S3 operations. The same identity could allow Amazon EC2 actions but deny Amazon EC2 Auto Scaling actions if no corresponding permissions exist.
Effective Permissions Are Aggregated
IAM permissions are evaluated across applicable policies rather than one policy in isolation. A user’s effective permissions may be influenced by:
- Policies attached directly to the user
- Policies inherited through groups
- Policies attached to a role being assumed
- Permissions boundaries
- Explicit deny statements
- Other policy controls relevant to the request context
An allow in one policy does not override an explicit deny. Permissions boundaries also limit the maximum permissions that an identity-based policy can grant; they do not independently grant permissions.
Exam-Relevant Takeaways
- The IAM Policy Simulator tests whether selected principals are allowed or denied specific AWS API actions.
- It supports IAM users, groups, and roles as simulation contexts.
- Existing policies mode evaluates policies already associated with the selected identity or group context.
- New policy mode allows a proposed policy to be tested before deployment.
- Testing all actions for a service is useful for discovering the actual permission scope of a policy.
- A policy that allows Amazon EC2 actions does not automatically allow Amazon EC2 Auto Scaling actions. IAM permissions are service- and action-specific.
- Least privilege is easier to validate by testing the exact API actions an application or operator needs.
- Effective access depends on the combined policy evaluation, not merely on the presence of one allow statement.
- Explicit denies take precedence over allows.
- A permissions boundary limits the maximum permissions available to an identity; it is not an access grant by itself.
Architecture Decision Guide
| Requirement | Recommended simulator approach | Why |
|---|---|---|
| Troubleshoot an existing user’s permissions | Select the user in existing policies mode and test the failing service action | Evaluates the policies currently associated with the identity and its context |
| Validate permissions inherited from a group | Select the relevant user or group and test the required actions | Helps expose the aggregate effect of direct and group-based policies |
| Test a role’s permissions | Select the IAM role and simulate the required actions | Verifies the role policy scope before relying on it for workloads or operations |
| Check a proposed policy before deployment | Use new policy mode and enter the policy document | Allows policy changes to be assessed without attaching them first |
| Review least-privilege scope | Test specific required actions, then optionally test all actions for the service | Confirms intended access and identifies excessive permissions |
| Evaluate a permissions boundary design | Include or simulate the boundary with the identity policy | Shows whether the boundary constrains the intended permissions |
| Investigate a broad access grant | Test all actions for the relevant service | Reveals permissions that may not be obvious from a quick policy review |
Common Exam Traps
- Confusing an allow with effective access: An identity policy can contain an allow, but a permissions boundary or explicit deny may still prevent access.
- Assuming service permissions are interchangeable: Amazon EC2 and Amazon EC2 Auto Scaling use different IAM actions. Allowing one does not grant access to the other.
- Testing only one policy: Reviewing a single policy document may miss permissions inherited from groups or restrictions imposed by a boundary.
- Using a permissions boundary as a grant: A boundary defines the maximum permissions an identity can receive. The identity still needs an applicable allow policy.
- Assuming a simulation proves an operation will succeed: The simulator evaluates IAM authorization. The real request may still fail because of resource policies, missing resources, invalid parameters, network conditions, encryption permissions, or service-specific requirements.
- Confusing a policy simulation with policy deployment: New policy mode evaluates a proposed document but does not attach or activate it.
- Relying only on broad action testing: Selecting every action can identify over-permissioning, but production policy design should normally use specific actions and resource constraints.
Real-World Engineer Notes
- Start with the exact failed API action rather than testing an entire service. This produces a clearer troubleshooting signal.
- Use the simulator during IAM policy development to compare a policy before and after removing unnecessary actions.
- When troubleshooting a real request, record the complete context: principal, action, resource ARN, region, account, and relevant condition keys.
- A successful simulation does not guarantee that the principal can complete the operation. For example, the resource may have a restrictive resource policy, or the operation may require additional permissions such as KMS access.
- Test both expected allows and expected denies. A least-privilege policy should permit the required workflow while rejecting unrelated actions.
- Separate administrative permissions from workload permissions. A role used by an application should not inherit broad permissions merely because an operator role requires them.
- If the simulator result does not match an observed request, inspect organization-level controls, resource policies, session policies, role trust relationships, and service-specific authorization behavior.
- Prefer managed policy versioning, infrastructure as code, and review workflows for production changes. The simulator is a validation aid, not a replacement for change control.
Quick Reference Summary
- Existing policies: Simulate the permissions currently associated with a user, group, or role.
- New policy: Test a policy document before attaching it.
- Test scope: Select individual actions or all actions for an AWS service.
- Effective access: Based on the combined IAM evaluation context.
- Explicit deny: Overrides an allow.
- Permissions boundary: Sets a maximum permission ceiling; it does not grant access.
- Best use: Validate least privilege and troubleshoot IAM authorization decisions.
Flashcards
1. What does the IAM Policy Simulator evaluate?
Whether a selected IAM user, group, or role is allowed or denied specific AWS API actions.
2. What is the difference between existing policies mode and new policy mode?
Existing policies mode evaluates policies already associated with the selected identity. New policy mode evaluates a policy document supplied for testing before deployment.
3. Which IAM principals can be selected as simulation contexts?
IAM users, groups, and roles.
4. Why might a user’s effective permissions differ from the policy attached directly to the user?
Permissions may also come from group membership, managed policies, boundaries, or other applicable policy controls.
5. Does allowing Amazon EC2 actions automatically allow Amazon EC2 Auto Scaling actions?
No. The services use separate IAM actions and must be authorized independently.
6. What takes precedence when an allow and explicit deny both apply?
The explicit deny.
7. Does a permissions boundary grant permissions?
No. It limits the maximum permissions that identity-based policies can grant.
8. When should all actions for a service be tested?
When reviewing the overall scope of a policy or looking for unexpected permissions. Specific actions are generally better for focused troubleshooting.
9. What is the main benefit of testing a new policy before attaching it?
You can validate intended permissions and identify unintended access or denials without changing the live identity configuration.
10. Does a successful IAM policy simulation guarantee that the AWS operation will succeed?
No. Other authorization layers, resource policies, encryption permissions, service requirements, or request details can still cause failure.
Practice Questions
Question 1
A security engineer creates an IAM policy that allows several ec2:* actions. The application must also create and modify Auto Scaling groups, but those requests return AccessDenied. What is the most likely explanation?
A. Amazon EC2 permissions automatically expire after instance creation.
B. Amazon EC2 Auto Scaling uses separate IAM actions that were not included in the policy.
C. Auto Scaling operations can only be authorized through a permissions boundary.
D. The IAM Policy Simulator cannot test service permissions.
Correct answer: B
Explanation: IAM permissions are action-specific. Permissions for Amazon EC2 do not automatically grant permissions for Amazon EC2 Auto Scaling. The required Auto Scaling actions must be explicitly authorized.
Question 2
An administrator wants to determine the effective permissions of an IAM user whose access comes from a direct inline policy and membership in several groups. Which approach is best?
A. Inspect only the inline policy attached directly to the user.
B. Use the IAM Policy Simulator in existing policies mode and select the user.
C. Use new policy mode with an empty policy.
D. Delete the group policies and test the user again.
Correct answer: B
Explanation: Existing policies mode evaluates the selected identity in its current policy context, helping reveal the aggregate permissions from direct and inherited policies.
Question 3
A team proposes an IAM policy for a production role. They want to verify that it allows object retrieval but does not allow bucket deletion before attaching it. What should they do?
A. Attach the policy and use CloudTrail to determine whether it is safe.
B. Use new policy mode, enter the proposed policy, and simulate the relevant S3 actions.
C. Attach the policy to an administrator because administrators bypass IAM evaluation.
D. Add s3:* temporarily and remove it after testing.
Correct answer: B
Explanation: New policy mode provides a sandbox for testing a proposed policy before deployment. The team can test the required object action and explicitly verify that bucket deletion is denied.
Question 4
An IAM role has an identity policy allowing an action, but a permissions boundary does not allow that action. What result should the architect expect?
A. The action is allowed because identity policies always override boundaries.
B. The action is allowed only for administrators.
C. The boundary limits the role’s effective permissions, so the action is not allowed.
D. The boundary grants the action if the identity policy contains an explicit allow.
Correct answer: C
Explanation: A permissions boundary defines the maximum permissions an identity can receive. An identity-based allow must be within that boundary to become effective.
Question 5
The IAM Policy Simulator shows that an action is allowed, but the actual API request still fails. Which conclusion is most accurate?
A. The simulator is always incorrect.
B. IAM authorization is only one part of the request’s success conditions.
C. An allowed simulation automatically creates the target resource.
D. The request must be retried until the policy takes effect.
Correct answer: B
Explanation: The simulator focuses on IAM authorization. The real operation may also depend on resource policies, KMS permissions, request parameters, service prerequisites, organization controls, or other runtime conditions.