AWS IAM
IAM (Identity and Access Management) authorizes every API call in your account. A principal (a user, role, or AWS service) wants to perform an action (s3:GetObject, ec2:RunInstances) on a resource; IAM evaluates the attached policies and returns allow or deny. Get IAM right and security gets easier; get it wrong and nothing else matters.
The model has been stable since 2010, but the surrounding tools — Identity Center, Access Analyzer, permission boundaries — have grown around it, and a modern design uses all of them.
Users, Groups, and Roles
A user is a long-lived identity with an optional password and access keys — modern guidance avoids creating IAM users for humans entirely. A group holds permissions for a set of users. A role is a temporary identity any allowed principal can assume, receiving short-lived credentials with no stored keys.
Roles are the workhorse of modern AWS security: EC2 instances, Lambda functions, ECS tasks, federated users, and cross-account access all use roles rather than long-lived keys.
Policies
Policies are JSON granting or denying permissions. Managed policies are standalone and reusable; inline policies embed in one identity. Identity-based policies attach to a principal; resource-based policies attach to a resource (S3 bucket, KMS key) and are the right tool for cross-account access.
Permission boundaries cap the maximum a user or role can have, for safe delegation. Service Control Policies (SCPs) in Organizations cap what any account can do regardless of IAM. Session policies scope down an assumed-role session.
Evaluation Logic and STS
Evaluation is simple but catches people: everything is implicitly denied by default; an explicit Deny anywhere always wins; an Allow must be granted somewhere. For cross-account access both the caller's policy and the target's resource policy must agree. Adding more allows never fixes an explicit deny — check for denies (often an SCP or boundary) first.
The Security Token Service (STS) hands out temporary credentials via AssumeRole (and SAML/web-identity variants for federation). The point is to keep long-term credentials out of as many places as possible — instances, functions, and CI jobs assume roles instead of holding keys.
Identity Center and Access Analyzer
IAM Identity Center is the modern answer for human access: users sign in through a portal, pick an account and permission set, and get a short-lived session — instead of creating IAM users in every account. For any new Organizations setup, it is the right starting point; IAM users remain only for service identities that genuinely need long-term keys.
IAM Access Analyzer finds resource policies that expose access externally, generates least-privilege policies from 90 days of CloudTrail activity, and flags unused users, roles, and permissions worth removing.
IAM — authorizing AWS API calls by principals (users, roles, services). The control plane of AWS itself.
Amazon Cognito — authenticating and authorizing your application's end users — sign-up, sign-in, JWTs.
Database auth — deciding which DB user reads which table — the database's own roles, below IAM.
- Trying to fix a permission error by attaching more allow policies when an explicit deny (often an SCP or permission boundary) is the real cause.
- Creating IAM users with long-lived access keys for humans instead of using Identity Center and roles — leaked keys are the most common AWS breach vector.
- Granting broad wildcard permissions instead of least privilege, so a compromised principal can do far more than its job needs.
- Using the root account for daily work instead of locking it down with hardware MFA and using it only for the few root-only tasks.
- Skipping cross-account resource policies and instead copying credentials between accounts.
- Ignoring Access Analyzer's unused-access findings, leaving stale principals and over-broad permissions accumulating for years.
- Use IAM Identity Center for human access; reserve IAM users for service accounts only.
- Use roles and temporary credentials wherever possible; never store long-lived keys on disk.
- Grant least privilege — start from nothing and add the specific actions needed.
- Use permission boundaries when delegating IAM creation and SCPs to enforce org-wide non-negotiables.
- Turn on MFA for the root account and every console user, and review the root account quarterly.
- Enable Access Analyzer and triage external-access and unused-access findings regularly.
Knowledge Check
A request is explicitly denied by an SCP. You attach an IAM allow policy for the action. What happens?
- Still denied — an explicit deny anywhere always wins, and adding allows cannot override it
- Allowed — the freshly attached IAM allow policy takes precedence and overrides the conflicting SCP deny
- Allowed, but only for the member account's root user, which sits above SCP restrictions
- The request is queued and held until the two conflicting policies are reconciled
What is the modern AWS recommendation for human access across many accounts?
- IAM Identity Center — portal sign-in to short-lived sessions, instead of IAM users per account
- A dedicated IAM user holding a long-lived set of access keys provisioned in every single account
- Sharing one set of root account credentials with the whole team for day-to-day work
- A single shared admin IAM user that every engineer assumes for daily tasks
Why are IAM roles preferred over IAM access keys for workloads?
- Roles issue short-lived temporary credentials with no long-lived keys to leak or rotate
- Roles are completely free to use whereas long-lived access keys are billed for every API call they make
- Roles skip the full policy evaluation step entirely, which makes their API calls noticeably faster
- Access keys are restricted and cannot call most of the AWS service APIs that roles can
For granting another AWS account access to your S3 bucket, which policy type is the right tool?
- A resource-based policy on the bucket naming the trusted external principal
- An inline identity policy attached directly to your own account's root user identity
- A permission boundary applied to the trusted external account's principals
- A session policy passed in at the time the external role is assumed
What does IAM Access Analyzer's policy generation feature do?
- Watches a role's CloudTrail activity over ~90 days and proposes a least-privilege policy based on what it actually used
- Automatically grants the role every single permission it has ever requested across its complete CloudTrail history to date
- Encrypts the role's attached policy documents at rest using a customer-managed KMS key
- Rotates the role's underlying access keys automatically on a fixed recurring schedule
You got correct