Lesson 1 of 30

IAM & Security Fundamentals

Q: How would you set up permissions for a Lambda function that needs to read files from one specific S3 bucket?

A strong answer covers: Create an execution role with a policy scoped to exactly the needed action (e.g. s3:GetObject) and exactly the needed resource (that one bucket's ARN), not a wildcard; Explain the principle of least privilege — grant only what's needed, not broad permissions 'to be safe'; Understand that a role provides temporary credentials the function assumes, not a hardcoded long-lived key.

Every AWS security incident that makes the news traces back to the same root cause: a permission that was broader than it needed to be. IAM is the system for making sure that never has to be true.

13 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

One IAM policy attached to a role grants `s3:*` on all buckets. A second policy attached to the same role explicitly denies `s3:DeleteObject`. Can that role delete an object?

No — an explicit Deny always overrides an Allow granted anywhere elseYes — the broader s3:* grant takes precedence since it's more permissiveIt depends on which policy was attached to the role more recently

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on IAM & Security Fundamentals

What interviewers actually ask about this, and what a strong answer has to cover.

How would you set up permissions for a Lambda function that needs to read files from one specific S3 bucket?

A strong answer covers

Create an execution role with a policy scoped to exactly the needed action (e.g. s3:GetObject) and exactly the needed resource (that one bucket's ARN), not a wildcard
Explain the principle of least privilege — grant only what's needed, not broad permissions 'to be safe'
Understand that a role provides temporary credentials the function assumes, not a hardcoded long-lived key

Likely follow-ups

If one policy grants full S3 access and another explicitly denies delete, what actually happens if the function tries to delete an object?
The IAM policy looks correct but access still fails — what else, on the resource side, might be blocking it?

Practice these with the AI interviewer →

The plain-language idea

IAM (Identity and Access Management) answers one question for every single action taken in an AWS account: is this specific identity allowed to do this specific thing to this specific resource, right now? Three pieces make that decision:

Identities — a user (a person), a role (a temporary identity anything can assume — an EC2 instance, a Lambda function, another AWS account), or a group (a named set of users sharing permissions).
Policies — JSON documents that grant or deny specific actions on specific resources. s3:GetObject on arn:aws:s3:::my-bucket/* means "allowed to read objects from this one bucket," nothing more.
The evaluation itself — by default, everything is denied. A policy has to explicitly allow an action, and an explicit Deny anywhere always wins over an Allow, no matter how many policies grant it elsewhere.

See it in a real thing: a Lambda function's execution role

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::user-uploads/*"
    }
  ]
}

IAM evaluation: deny by default, Deny always winsStep 1 of 3

A fresh role with zero policies attached — the default is deny. It can do nothing yet.

This policy, attached to a Lambda function's execution role, lets that function read objects from exactly one bucket — not write to it, not list other buckets, not touch anything else in the account. If that function's code has a bug or gets compromised, the blast radius is capped at "can read files from user-uploads," not "can do anything the AWS account can do." That capping is the entire point, and it's called the principle of least privilege: grant exactly what's needed to do the job, nothing kept "just in case."

What people usually miss

Watch out

An explicit Deny always wins, even over an explicit Allow somewhere else. If one policy grants s3:* and a different policy attached to the same identity denies s3:DeleteObject, the delete is still denied — there's no "most specific policy wins" resolution, deny is just absolute.
The default is deny, not allow. An identity with zero attached policies can do nothing — permissions are additive grants against a deny-everything baseline, never a subtractive list of things removed from an allow-everything baseline.
Wildcard resources ("Resource": "*") are a real, common security smell, not a convenience shortcut. A policy allowing s3:GetObject on * can read every object in every bucket the account owns — scoping resources to specific ARNs is what makes least privilege actually mean something instead of being a policy in name only.
IAM policies and resource policies are two different attachment points that both have to agree. An S3 bucket policy (attached to the bucket) and an IAM policy (attached to the identity) are evaluated together — an identity can have full S3 permissions in its IAM policy and still be blocked if the bucket's own policy doesn't allow that identity, and vice versa.

Why this matters in interviews

"How would you make sure a Lambda function can only touch what it actually needs?" is a real, common question that tests whether a candidate reaches for least-privilege reasoning by default or grants broad permissions "to be safe" — which is precisely backwards, since broad permissions are what turn a small bug into a large incident.