AWS IAM: Identity and Access Management Policies
The layer that decides whether every other AWS call succeeds. {cards} flashcards on how six policy types collapse into a single allow-or-deny — evaluation logic, trust policies and STS, condition keys and ABAC, cross-account access, and the audit tooling that walks an over-permissive policy back to least privilege.
- flashcards
- 102
- flashcards
- per day
- ~10 min
- per day
- level
- Intermediate → Advanced
- level
- modules
- 6
- modules
What AWS Identity and Access Management actually asks of you
IAM is not a service you look up once — it is the decision engine every other AWS call passes through. A request starts implicitly denied, an Allow anywhere lifts that, and an explicit Deny anywhere ends the matter. The part that costs people an afternoon is what sits between those two rules: identity-based policies, resource-based policies, service control policies, resource control policies, permissions boundaries and session policies all take part in the same decision, and four of them can only ever take permissions away.
That is why a role holding AdministratorAccess can still fail to read a bucket, and why adding a policy is so often the wrong fix. These {modules} modules follow the decision rather than the console: how the types combine, what each one can and cannot grant, how AssumeRole needs both the trust policy and the caller’s own permission, how condition keys turn a broad grant into a narrow one, what changes the moment a second account is involved, and which signals justify deleting access instead of adding it.
Every card cites a specific page in the AWS documentation, because this surface moves — the managed-policy quota for a role, for one, is no longer the number most guides still print. Treat the linked docs as the source of truth, and verify any quota or default against them before you design around it. If you are working towards an exam rather than the day job, Solutions Architect Associate covers the trade-off tier and Cloud Practitioner the vocabulary beneath it.
IAM carries real weight on the exams: security is the single largest scored domain on Solutions Architect at 30 per cent, and 26 per cent on Developer. Which AWS certification should you choose? breaks down what each blueprint actually asks for.
6 modules, seed to bloom
Each module is a set of flashcards — 102 in total. Answer, review, and watch your knowledge grow from seed to full bloom.
Policy Evaluation Logic
How six policy types combine into one allow-or-deny decision
17 cardsPolicy Types & Structure
What each policy type can and cannot do, and how documents are built
17 cardsRoles, Trust Policies & STS
Assuming roles, temporary credentials and the two-sided permission they need
17 cardsCondition Keys & ABAC
Operators, request context keys and tag-based access control
17 cardsCross-Account & Federation
Reaching across account boundaries and trusting external identity providers
17 cardsAudit & Least Privilege
Finding excess access, proving who used what, and closing privilege escalation paths
17 cardsSample questions
A taste of the real flashcards. Pick an answer, then reveal the explanation.
Which policy types can only restrict permissions and never grant them?
- ASCPs, RCPs, permissions boundaries and session policies — all four are ceilings, not grants
- BSCPs and RCPs only — boundaries and session policies grant within their stated scope
- CPermissions boundaries and session policies only — organization policies do grant access
- DSession policies only — the other three add permissions when nothing else matches
Why is a Deny on aws:MultiFactorAuthPresent written with BoolIfExists rather than Bool?
- ASome requests omit the key — with plain Bool those calls escape the deny entirely
- BSome requests set it twice — BoolIfExists takes the last value rather than failing
- CSome requests use SAML — BoolIfExists reads the assertion instead of the context
- DSome requests are long-lived — BoolIfExists re-evaluates the key as the session ages
What problem does the ExternalId value in a third-party role trust policy solve?
- AThe confused deputy — it stops the vendor using your role on another customer's behalf
- BCredential theft — it acts as a shared secret that replaces the vendor's access keys
- CSession hijacking — it binds the session to the network the vendor connected from
- DPrivilege creep — it forces the vendor to re-request the role after each engagement
Why is the iam:PassRole permission a privilege escalation risk?
- AIt lets a principal hand a more privileged role to a service that will then run as it
- BIt lets a principal attach any managed policy to a role they already own
- CIt lets a principal assume a role without appearing in that role's trust policy
- DIt lets a principal raise their own permissions boundary to the account maximum
Learn it once, keep it for good
Answer a question
Each card is one practical concept with multiple options. Pick what you think is right.
Get the full answer
See the correct option plus a clear explanation, and a link to deeper docs when one is available.
Review at the right time
A spaced-repetition engine (SM-2 or FSRS) resurfaces each card just before you would forget it.
Why IAM is worth learning properly once
Predict the decision
Know how the six policy types resolve and you can reason out why a call failed, instead of bisecting policies in the console.
The keys least privilege runs on
Condition keys are where a grant is actually narrowed — organization scoping, confused-deputy protection, tag-based access, and the MFA condition that silently fails open.
Two-sided by default
Cross-account access needs an allow in both accounts. Most “it works in dev but not prod” tickets are one half of that pair missing.
Escalation paths named
iam:PassRole, delegated role creation without a boundary, a trust policy left open to an account root — the ways a modest permission becomes an administrator.
Common questions
Do I need this if I already did Cloud Practitioner or Solutions Architect? +
Those tracks cover IAM at the level of naming the pieces — users, groups, roles, managed versus inline policies. This one starts where they stop: the evaluation order, what a permissions boundary does when nothing else grants, how a session policy narrows an assumed role, and the condition keys that make a policy safe rather than merely correct.
Is this tied to a specific AWS certification? +
No. It follows the IAM surface engineers use day to day rather than an exam blueprint, though it overlaps heavily with the Design Secure Architectures domain of SAA-C03. Gnoseed is a study companion — it does not sell, proctor or guarantee any certification.
How current are the quotas and defaults? +
Every card links the AWS documentation page that states its fact, and the numbers were read off those pages rather than copied from prep sites — the managed-policy limit per role, for instance, has been raised since most write-ups were published. AWS keeps changing them, so check the linked page before you rely on a figure.
Does it cover IAM Identity Center? +
Only where it meets IAM proper: that assigning a permission set provisions a role in the target account, and why federated access is preferred to long-lived IAM users. Administering the Identity Center directory itself is out of scope.
Is it free? +
Yes, completely free with no registration. Progress is stored locally in your browser, and syncs across devices only if you choose to sign in.
Start with the module that would catch you out today
Most people are solid on policy syntax and shaky on evaluation order. Plant your first seed there — ten minutes a day, and the next denied call explains itself.