So let's imagine we have a group called 'DevTeam' for developers, and we attach a policy at the group level. In that case, the policy will get applied to every single member of the group, so all the users (d1,d2,d3) inside DevTeam will get access and inherit this policy. Now, if you have an another group called 'TestTeam' with a different policy, users inside TestTeam (t1,t2,t3) will have a different policy than the group of DevTeam. If there is a Business user(b1), it has the possibility not to belong to a group, and we have the possibility to create what's called an inline policy which has a policy that's only attached to a user. So that user could or could not belong to a group you can have inline policies for whatever user you want. And finally, if some of the users (d3) from DevTeam and (t1) from TestTeam also belong to the OpsTeam - you can attach a policy for those users to the Opsteam as well, so user d3,t1 will also inherit that policy from the opsteam apart from other policy.

Policy structure:

An IAM policy structure, consists of a version number, so usually it's 2012-10-17, this is the policy language version. And then more statements, statements can be one or multiple ones, and a statement has some very important parts. So the Sid is a statement ID, which is an identifier for the statement, which is optional as well, so on the right hand side is the number one. The effect of the policy itself, so it is whether or not the statement allows or denies access to certain API, so in the right hand side, this says allow, but you can see deny as well. The principle consists of which accounts, user or role which, to which this policy will be applied to. Action is the list of API calls that will be either denied or allowed based on the effect. And the resource is a list of resources, to which the actions will be applied to. So in this example, it is a bucket, but it could be many different things. And finally in, there's a condition to which when this statement should be applied or not, and it is optional.

Policy examples: docs.aws.amazon.com/IAM/latest/UserGuide/ac..

Types of policy:

• Identity-based policies – attached to users, groups, or roles.
• Resource-based policies – attached to a resource; define permissions for a principal accessing the resource.
• IAM permissions boundaries – set the maximum permissions an identity-based policy can grant an IAM entity.
• AWS Organizations service control policies (SCP) – specify the maximum permissions for an organization or OU.
• Session policies – used with AssumeRole* API actions.

Evaluation logic: docs.aws.amazon.com/IAM/latest/UserGuide/re.. Determination Rules

1. By default, all requests are implicitly denied (though the root user has full access)
2. An explicit allow in an identity-based or resource-based policy overrides this default
3. If a permissions boundary, Organizations SCP, or session policy is present, it might override the allow with an implicit deny
4. An explicit deny in any policy overrides any allows

IAM Policy Simulator:

With the IAM policy simulator, you can test and troubleshoot identity-based policies, IAM permissions boundaries, Organizations service control policies (SCPs), and resource-based policies. Please find the full details in the link : docs.aws.amazon.com/IAM/latest/UserGuide/ac..