IAM Policy

An IAM policy is a JSON document that explicitly defines what actions are allowed or denied on which resources, forming the actual permission logic that IAM roles, users, and groups are granted in order to control access within a cloud environment.

Structure of a Policy

A typical IAM policy consists of one or more statements, each specifying an Effect (Allow or Deny), an Action (which specific API operations the statement applies to, like s3:GetObject or ec2:TerminateInstances), a Resource (which specific resources the statement applies to, often specified by Amazon Resource Name, or a wildcard for broader scope), and optionally a Condition (additional constraints, like requiring the request to come from a specific IP range or requiring multi-factor authentication).

Policy Types

Identity-based policies are attached directly to an IAM user, group, or role, defining what that identity is allowed to do. Resource-based policies are attached to the resource itself (like an S3 bucket policy or a Lambda function’s resource policy) and define who is allowed to access that specific resource, regardless of what identity-based policies that accessor might also have. When both types apply to a given request, the request must be allowed by at least one applicable policy and not explicitly denied by any — an explicit Deny in any policy always overrides an Allow elsewhere, a rule worth remembering when debugging unexpected access denials.

The Principle of Least Privilege

Writing IAM policies well is fundamentally about applying the principle of least privilege — granting only the specific permissions an identity actually needs to do its job, rather than broad permissions “just in case.” Overly permissive policies (a common shortcut during development, using wildcard actions and resources) are one of the most common root causes of cloud security incidents, since a single compromised credential with broad permissions can cause far more damage than one scoped tightly to only what’s necessary.

Policy Simulation and Testing

Because policy behavior can be subtle — especially when identity-based and resource-based policies interact, or when permission boundaries and service control policies add additional layers of restriction — cloud providers offer policy simulation tools that let administrators test what a given policy would actually allow before deploying it to production. This kind of dry-run testing is particularly valuable given how easy it is to write a policy that looks correct but has an unintended gap or overly broad grant, and it’s a recommended step in any workflow that involves writing or modifying IAM policies for production systems, rather than relying solely on manual review of the JSON.