How to Run an IAM Policy Simulator: Step-by-Step Guide

Abstract

AWS IAM Policy Simulator is a testing tool that helps teams evaluate whether an IAM policy allows or denies specific AWS actions before those permissions are applied in production. 

Step-by-Step Guide to Running an IAM Policy Simulator

To run an IAM Policy Simulator test:

• Open the IAM Policy Simulator.
• Select the IAM user, group, or role you want to test.
• Choose the AWS service and actions to simulate.
• Add the relevant resource ARNs and request context.
• Review the allowed, explicitly denied, or implicitly denied results.
• Update the IAM policy and rerun the simulation until the access behavior matches your least-privilege design.

Reading raw JSON strings and hoping they work is not a security strategy. The AWS evaluation engine processes complex logic behind the scenes, meaning a tiny policy error can easily lock out your engineering teams or expose data. 

Over-permissioning remains one of the hardest cloud access problems to control because speed often wins over security guardrails. A Cloud Security Alliance report found that implementing least privilege for identities was the top cloud security priority for 44% of organizations. 

Instead of using trial-and-error edits in live environments, you can use AWS’ IAM Policy Simulator to verify static logic safely before committing changes to your codebase. In this article, we will show you how. 

What is the IAM Policy Simulator? 

The AWS IAM Policy Simulator lets you safely test and debug Identity and Access Management policies before applying them to your live cloud infrastructure. It acts as a sandboxed testing ground, evaluating your JSON policy strings against specific API actions to provide an immediate, clear verdict: “allowed” or “denied”.

By simulating AWS authorization logic, the simulator allows your DevOps and security teams to verify that permissions grant the precise level of access required for a job. You can input specific AWS services, actions, and Amazon Resource Names (ARNs) to ensure your foundational configurations enforce IAM best practices without risking live data or interrupting critical engineering workflows.

However, the simulator does have specific boundaries. The simulator is strongest for testing identity-based policies and permissions boundaries. The simulator can evaluate some resource-based policies, but support is limited. In the console, AWS supports resource-based policies for Amazon S3, Amazon SQS, Amazon SNS, and unlocked Amazon Glacier vaults. It does not support S3 ACLs, locked Glacier vaults, or full production-context evaluation for every AWS service.

However, it does not support resource-based policy simulation for IAM roles, does not evaluate SCPs with conditions, does not support resource control policies, and cannot fully reproduce live production context or cross-account behavior.

When should you use an IAM Policy Simulator? 

1. Before deploying new or updated IAM policies

You don’t want to find out a policy is broken after it’s live. Run a simulation whenever you finish drafting new JSON strings. It acts as a staging environment, showing you exactly how the permissions behave so you can catch accidental access gaps before committing changes to your codebase. 

2. Troubleshooting “Access Denied” errors

AWS permission errors are notoriously frustrating to untangle because a failed request can involve identity policies, resource ARNs, condition keys, permissions boundaries, or session context.

Test the IAM role’s attached policies, action, resource ARN, and condition context involved in the failed request. Keep in mind that the simulator may not fully reproduce every runtime factor in an assumed-role session.

3. Reducing over-permissioning

We’ve all inherited that policy. The one with *:* buried three levels deep because someone was under the gun and just needed it to work. Cloud policies easily accumulate messy wildcards when teams need a quick fix during a deployment. Stripping away access blindly is a massive risk to production pipelines, and using the simulator lets you map out tighter restrictions. 

4. Conducting least-privilege reviews

Recognizing a policy has too much access is easy, but trimming it back without knocking critical systems offline is the main operational problem. Security audits insist on tighter rules, yet the fear of breaking active integrations causes endless delays, and the IAM Policy Simulator breaks this deadlock. 

Security audits insist on tighter rules, yet the fear of breaking active integrations causes endless delays. Pairing IAM Policy Simulator with AWS Access Analyzer best practices can help teams identify risky permissions, validate policy changes, and move toward least privilege with more confidence.

For teams working toward a zero trust framework, IAM Policy Simulator helps validate whether proposed least-privilege changes will reduce access without breaking active integrations.

5. Validating production changes or sensitive access requests

Before granting high-risk permissions such as sts:AssumeRole or delete actions, simulate the request to confirm the policy allows only the intended access.

Before you start: IAM Policy Simulator prerequisites

Required IAM permissions to use the simulator

If you use the IAM Policy Simulator console, you can test policies that are not yet attached to a user, group, or role by typing or copying the policy into the simulator. These test policies are used only for the simulation and are not saved to your AWS account.

To test policies that are already attached to IAM users, groups, or roles, your AWS identity needs permission to retrieve those identities and their policies. AWS documents this as a set of IAM Get* and List* permissions, such as:

• iam:GetPolicy
• iam:GetPolicyVersion
• iam:GetUserPolicy
• iam:GetRolePolicy
• iam:ListAttachedUserPolicies
• iam:ListAttachedRolePolicies

and related user, group, or role listing permissions.

If you include a resource-based policy in the simulation, you also need permission to retrieve that resource policy. For example, testing an Amazon S3 bucket policy requires s3:GetBucketPolicy.

API and CLI permissions

If you run simulations through the AWS CLI or API, you need simulator-specific IAM permissions.

To simulate an unattached policy passed directly as a JSON string, your identity needs:

• iam:GetContextKeysForCustomPolicy
• iam:SimulateCustomPolicy

To simulate policies attached to IAM users, groups, roles, or resources, your identity needs:

• iam:GetContextKeysForPrincipalPolicy
• iam:SimulatePrincipalPolicy

This distinction matters because console-based simulations and API-based simulations are authorized differently. In the console, the key requirement is usually whether your identity can retrieve the policies and resources you want to test. In the CLI or API, AWS requires explicit simulator actions to run those simulations.

Identifying your testing target

The simulator operates in two distinct modes depending on your objective. You need to decide whether you are testing an active principal, such as a user, group, role, service account, or identity used by AI agent infrastructure, or evaluating an isolated, unattached custom policy.

Resource ARNs

By default, the simulator evaluates actions against a wildcard resource (*). If your IAM policies use granular resource restrictions, testing with a wildcard will return misleading results. You must gather the exact Amazon Resource Names (ARNs) for the assets you want to test, such as specific S3 bucket or object ARNs, DynamoDB table paths, or EC2 instance identifiers, to ensure the evaluation logic matches reality.

Condition keys and request context values

If the policy you want to test contains a Condition block, the simulation engine requires external context to evaluate the logic. You need to identify the specific condition keys used in the policy, such as aws:PrincipalTag, aws:SourceIp, or aws:CurrentTime. The simulator will prompt you to manually input these context values so it can accurately calculate whether the condition evaluates to true or false.

Why you should test in a non-production workflow first

The simulator does not perform the API action or modify live resources. Still, teams should validate policy changes through a non-production change workflow before attaching updated policies to production identities.

How to run an IAM Policy Simulator test in AWS

Source.

Step 1: Open the IAM Policy Simulator

To begin testing, navigate to the AWS IAM Policy Simulator console in your browser. You can access it directly at policysim.aws.amazon.com or via the link in the IAM dashboard of the AWS Management Console. 

Ensure you are logged in to the right AWS account that contains the permissions or principals you intend to evaluate. 

Step 2: Select the IAM user, group, or role to test

Once the simulator interface loads, focus on the left-hand panel to isolate your evaluation target. You will see a structured list categorized by Users, Groups, Roles, and Policies. 

Select the specific checkbox next to the entity whose access rights you need to check. Choosing an active principal automatically pulls all currently attached identity-based policies into the simulator window, allowing you to examine the combined impact with current existing rules.

Step 3: Choose the AWS service and actions to simulate

Select your resource type from the Service menu, then wait for the secondary drop-down to display the matching API actions. 

Avoid testing broad action sets by default. Wildcard testing can hide whether the policy supports the exact least-privilege action you need.

Step 4: Add resource ARNs and request context

Swap out the default wildcard symbol for the exact Amazon Resource Name (ARN) of the asset you are targeting.

For policies that rely on conditional logic, the simulator will display input boxes for the required context keys. You have to fill these in manually. If you don’t enter a valid IP string for aws:SourceIp or a specific tag string for aws:PrincipalTag, the evaluation engine won’t be able to calculate the logic accurately.

Step 5: Review allowed, denied, and implicitly denied results

Hit Run Simulation to push your parameters through the AWS evaluation logic. The simulator spits out a clear status flag for every action: a green Allowed marker, a red Explicitly Denied marker, or a grey Implicitly Denied marker.

If something blocks your traffic, expand that specific result row to see why. The tool points directly to the statement name and line number responsible for the final decision. 

Step 6: Update the IAM policy and rerun the simulation

Unexpected blocks or weird access paths mean your JSON needs work. If you are using a raw custom string in the simulator window, you can actually edit the code directly inside the textbox. Hit the refresh trigger to test the new logic instantly.

For active, attached identity policies, open a separate tab to make your edits inside the standard IAM console. Save the update, head back to your simulator tab, and trigger a clean run. Repeat this loop until the evaluation results match your design.

Common IAM Policy Simulator results and what they mean 

Simulation Result	Operational Reality
Allowed	An active Allow statement matches your principal, action, and target resource. Traffic passes.
Explicit deny	A hard Deny statement dropped in somewhere. It kills the request immediately, ignoring any allows.
Implicit deny	Default IAM behavior. No applicable policy explicitly allowed the action, so AWS denies the request.
Missing context values	Your policy uses a Condition block, but you didn’t pass the mock data needed to test it. Fill out the variable boxes.
Resource mismatch	The resource ARN you typed into the test setup doesn’t line up with the scope written in the policy JSON.

Example: Testing whether a role can access a specific S3 bucket

Policy simulation helps the team validate what access should be allowed. But for production access, validation is only the first step. Whether the request comes from a developer, service account, or AI agent, teams still need a way to grant access just in time, scope it to the task, and revoke it automatically when the work is done.

Let’s look at an example. A developer needs temporary read access to objects in a production S3 bucket. For teams reviewing S3 security, this is a common least-privilege scenario: allow s3:GetObject without granting broader s3:* permissions or write/delete access.

Before attaching the policy, the team tests the draft in IAM Policy Simulator using the exact S3 object ARN. They simulate s3:GetObject, s3:PutObject, and s3:DeleteObject to confirm that read access is allowed while unauthorized actions remain implicitly denied.

This validates the policy logic before deployment, but it doesn’t manage the lifecycle of the access. Once the policy is attached, the permission remains available until someone removes it. That is where standing access becomes the larger operational risk.

Table 2: IAM Policy Simulator vs Cloud-Native Access Management

IAM Policy Simulator helps you…	Cloud-native privileged access management helps you…
Test whether an IAM policy allows or denies a specific action	Enforce access only when it’s needed
Validate static IAM policy logic before deployment	Create scoped privileges dynamically at request time
Identify missing allows, explicit denies, or resource mismatches	Revoke access automatically when the task is complete
Check whether a policy supports least privilege	Reduce standing access, privilege sprawl, and over-permissioning
Troubleshoot access issues before changing live policies	Maintain audit trails showing who accessed what, when, why, and for how long
Confirm that a role can access a specific resource	Control runtime access across cloud infrastructure, databases, Kubernetes, and agentic identities

Move From Policy Testing to Runtime Access Control

IAM Policy Simulator helps teams validate what an AWS policy should allow or deny before changes reach production. That matters, especially when a small policy mistake can create excessive access, block engineering work, or leave sensitive resources exposed.

But simulation only tests static policy logic. It doesn’t enforce access at runtime, revoke permissions after the task is complete, or prevent human users, service accounts, copilots, or AI agents from inheriting standing privileges.

That’s where Apono extends the value of policy validation. Apono helps teams eliminate standing access with just-in-time and just-enough permissions, dynamic privilege creation, automated revocation, and full audit trails across cloud infrastructure, databases, Kubernetes, and agentic identities.

In AWS environments, Apono Privileged Cloud helps teams move beyond static IAM role management by creating scoped access on request and automatically revoking it when the session ends. For teams adopting AI agents, Apono Agent Privilege Guard provides task-based privilege controls to prevent agents from inheriting standing admin access.

Reduce IAM risk before it becomes exposure. See how Apono helps teams eliminate standing privileges for engineers, cloud identities, and AI agents. Book a live demo.