At the end of section one you ran aws sts get-caller-identity and AWS answered. Behind that answer, and behind every other call, sits AWS Identity and Access Management (IAM). It answers one question billions of times a day: is this principal allowed to do this action on this resource, right now? Lantern’s old server had one answer for everything: whoever had the SSH key could do anything. This lesson gives you the vocabulary to do better.
Every request to AWS, from the console, the CLI or code, carries four things:
\nservice:Operation, such as s3:GetObject or dynamodb:PutItem.ARNs follow the pattern arn:partition:service:region:account-id:resource. Some parts are empty when they don’t apply:
arn:aws:iam::111122223333:user/amara\narn:aws:s3:::lantern-posters/2026/street-food-festival.jpg\narn:aws:dynamodb:eu-west-1:111122223333:table/lantern-rsvpsIAM is global, so the user ARN has no Region. S3 bucket names are unique across all of AWS, so an S3 ARN has neither Region nor account. DynamoDB tables are regional and belong to an account, so their ARN has both. You will write ARNs constantly in the next lesson.
\nUsers are long-term identities for one person or, in older setups, one application. A user can have a console password and up to two access keys. Users are the oldest part of IAM, and in section one you created exactly one, your admin.
\nGroups are collections of users. You attach policies to a group, and every member gets them. Lantern creates Admins, Developers and Billing, so that when a volunteer joins or leaves, you change one membership instead of hunting through individual permissions. Groups are not principals: you can’t sign in as a group or name one in a bucket policy.
Roles are identities with permissions but no long-term credentials. A trusted principal assumes a role, and AWS Security Token Service (STS) hands back temporary credentials that expire. A role’s trust policy says who may assume it: a Lambda function, an EC2 instance, a user in another account, or people signed in through IAM Identity Center. Roles are how code gets permissions without secrets, and lesson three of this section builds on them.
\naws iam create-group --group-name Developers\naws iam attach-group-policy --group-name Developers \\\n --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess\naws iam add-user-to-group --group-name Developers --user-name samA policy is a JSON document of statements that allow or deny actions on resources. Where it is attached changes how it reads:
\nReadOnlyAccess), customer managed policies you write and reuse, or inline policies embedded in a single identity.Within one account, a request is allowed if either kind of policy allows it and nothing denies it. Across accounts, both sides must allow it.
\nThe evaluation rule fits on an index card, and it explains nearly every AccessDenied error you will ever see.
\nDeny, the answer is no. Nothing can override it.Allow, the answer is yes.Larger setups add further layers that can only narrow what is allowed, such as service control policies from AWS Organizations and permissions boundaries on individual users and roles. The rule above still holds; those layers add more places a deny can come from.
\nYou can ask IAM to evaluate a request without making it:
\naws iam simulate-principal-policy \\\n --policy-source-arn arn:aws:iam::111122223333:user/sam \\\n --action-names s3:DeleteBucket \\\n --resource-arns arn:aws:s3:::lantern-posters \\\n --query \"EvaluationResults[].EvalDecision\"The answer is allowed, explicitDeny or implicitDeny, which tells you not only whether but why.
You can now read who is asking and how the decision is made. Next you write the policies themselves, line by line.
\n","toc":[{"id":"sec-1","text":"Anatomy of a request","level":2},{"id":"sec-2","text":"The identities","level":2},{"id":"sec-3","text":"Where policies live","level":2},{"id":"sec-4","text":"How IAM decides","level":2}],"takeaways":["Every AWS request carries a principal, an action, a resource ARN and a context, and IAM evaluates all four before anything happens.","Users are long-term identities, groups are a way to give users the same policies, and roles are identities with no long-term credentials that trusted principals assume for temporary credentials.","Identity-based policies attach to users, groups and roles; resource-based policies, such as S3 bucket policies, attach to the resource and name a principal.","Everything is denied by default, an explicit allow is needed to permit a request, and an explicit deny anywhere always wins."],"further":[{"title":"IAM identities (users, user groups, and roles)","url":"https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html"},{"title":"Policy evaluation logic","url":"https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html"},{"title":"IAM identifiers (ARNs)","url":"https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-identifiers.html"}],"quiz":[{"q":"Lantern’s developer Sam has no policies that mention DynamoDB. Sam runs aws dynamodb scan --table-name lantern-rsvps. What happens?
A policy allows s3:* on Lantern’s posters bucket for the Developers group, and a second policy explicitly denies s3:DeleteBucket for the same group. A developer tries to delete the bucket. What happens?
s3:* is more powerful than a single action.","why":"Wildcards only widen what an allow matches. They never outrank a deny."}],"answer":0},{"q":"Which statement about IAM roles is accurate?
","options":[{"text":"A role has its own password, which you share with the team that uses it.","why":"Roles have no password and no long-term access keys. That is their main security advantage."},{"text":"A role is a type of group, so you add users to it.","why":"Groups contain users; roles do not. A principal assumes a role and gets that role’s permissions for a session."},{"text":"A role is assumed by a trusted principal, which receives temporary credentials that expire.","why":"Correct. The role’s trust policy says who may assume it, and AWS STS issues credentials that expire after the session duration."},{"text":"A role can only be used by AWS services, never by people.","why":"People assume roles all the time, for example through IAM Identity Center or when switching roles in the console."}],"answer":2}],"exercise":{"kind":"choice","multiple":true,"options":["sam-get","sam-delete","sam-scan","role-get","group-principal"],"correct":["sam-get","role-get"],"title":"Allowed or denied?","prompt":"All of this happens in Lantern’s single AWS account.
\ns3:GetObject and s3:DeleteObject on arn:aws:s3:::lantern-posters/*.s3:DeleteObject to every principal, and allows s3:GetObject to the role lantern-thumbnailer.Select every request that AWS allows.
\n","hints":["Run each request through the order: explicit deny anywhere? then any allow? then default deny.","Inside one account, an allow in either an identity-based or a resource-based policy is enough, as long as nothing denies.","Two requests are allowed. One is allowed by the bucket policy alone."],"explanation":"Sam’s GetObject matches the group’s allow and nothing denies it, so it succeeds. Sam’s DeleteObject is also allowed by the group policy, but the bucket policy’s explicit deny wins. Sam’s DynamoDB scan matches no allow anywhere, so the default deny stands. The thumbnailer role has no identity policies, but the bucket policy names it as a principal and allows GetObject; within one account that resource-based allow is enough. Finally, groups are not principals, so a bucket policy cannot name the Developers group at all; you would grant the group through its identity-based policy instead.
s3://lantern-posters/2026/street-food-festival.jpg with aws s3 cp.","why":"Allowed. The group policy allows s3:GetObject on objects in the bucket and no policy denies it."},"sam-delete":{"text":"Sam deletes an old poster with aws s3 rm.","why":"Denied. The group allows it, but the bucket policy’s explicit deny applies to every principal and an explicit deny always wins."},"sam-scan":{"text":"Sam scans the lantern-rsvps DynamoDB table.","why":"Denied. Nothing allows any DynamoDB action for Sam, so this is an implicit deny."},"role-get":{"text":"A Lambda function running as lantern-thumbnailer reads a poster.","why":"Allowed. The bucket policy is a resource-based policy that names the role and allows the read; within one account that is enough."},"group-principal":{"text":"The bucket policy is edited to allow s3:PutObject with the Developers group as the principal, and Sam then uploads a poster.","why":"Denied, and the policy edit itself fails validation. Groups are not principals, so a resource-based policy cannot name one."}}},"words":806,"readMinutes":4}