In AWS IAM, what is the difference between an AWS managed policy, a customer managed policy and an inline policy, and how do you choose between them?
answer
- same JSON, different lifecycle
- one of the three has no ARN
- only one kind can be rolled back
- who owns the document decides who edits it
- policies that widen without your diff
basics
~20 sManaged policies are standalone objects with an ARN that attach to many principals and keep prior versions; AWS managed ones are maintained by AWS and usually too broad. Inline policies are embedded in a single principal, have no ARN, and are deleted with it.
solid answer
~50 sA **managed policy** is a first-class IAM object with its own ARN, attachable to many users, groups and roles, and versioned so you can roll back an edit. **AWS managed** policies are written and updated by AWS: convenient starting points such as `AWSLambdaBasicExecutionRole`, but broad by design and able to gain permissions when AWS adds actions to them, so they are poor production least-privilege. **Customer managed** policies are your own reusable units — the default choice for anything shared, because they are versioned, addressable by ARN from infrastructure code, and reportable across the account. An **inline** policy is embedded inside one principal, has no ARN, cannot be reused, keeps no version history, and is deleted when the principal is. Use inline deliberately when the permission must never outlive or be attached beyond that one principal, and use customer managed policies for everything else.
go deeper
Know that a managed policy is a reusable object with an ARN while an inline policy is embedded in a single user or role and disappears with it.
Explain the practical consequences — versioning and rollback, attachment limits, central reporting — and why AWS managed policies are usually too broad for workload roles.
Show the operational judgment: AWS managed policies can widen when AWS adds actions, so state where you accept that and where you insist on a policy you author and diff.
Own the account-wide convention — what may be attached in production, how policies are factored across the size and attachment limits, and how drift toward inline copies is prevented.
## Three things with one grammar All three are the same JSON document. The difference is entirely about **where the document lives and what lifecycle it has**. **AWS managed policies** are created and owned by AWS, visible in every account, identified by ARNs under `arn:aws:iam::aws:policy/...`. You attach them; you cannot edit them. AWS updates them — adding actions when a service ships new APIs, and occasionally publishing a new policy rather than widening an old one. **Customer managed policies** are the same kind of object but owned by you, under `arn:aws:iam::<account-id>:policy/...`. You create, edit, version and delete them, and attach them to as many principals as you like. **Inline policies** are not standalone objects at all. The document is stored *inside* a user, group or role, has a name but no ARN, and exists only for that principal. ## What managed policies buy you **Reuse.** One document, many principals. Change it once, and every attached principal is affected — which is both the benefit and the thing to be careful about during review. **Versioning.** Editing a customer managed policy creates a new version while keeping a limited number of previous ones (five, as of 2025), with one marked default. That gives you a genuine rollback for a policy edit that broke production, which inline policies do not have. **Addressability.** An ARN means infrastructure code, audit tooling and the console can all refer to the same object, and you can answer "who has this policy" with a single API call rather than walking every principal. **Limits.** A managed policy document has a character limit (6,144 as of 2025), and each principal can have a bounded number of managed policies attached — ten by default, raisable on request. Large permission sets therefore have to be factored into several policies, which is usually a good thing anyway. ## What inline policies are actually for The defining property is **lifecycle coupling**: delete the role and the policy goes with it, guaranteeing no orphaned permission document survives. That matters where a permission is genuinely specific to one principal and should never be attachable to another — a role with a one-off privileged grant, or generated per-tenant roles where reuse would be a bug. Inline policies also count against a separate size budget on the principal rather than the managed-policy attachment count, which occasionally matters at the edges. The cost is real: no version history, no ARN, no central reporting, and awkward review — you have to enumerate principals to find them. Accounts that lean on inline policies tend to accumulate copy-pasted near-duplicates that drift apart. ## Why AWS managed policies are a trap in production They are written to be broadly useful, which is the opposite of least privilege. `AmazonS3FullAccess` grants every S3 action on every bucket in the account. Broad read-only policies grant list and describe across services you never intended to expose, and a read-only grant is not harmless when the readable data includes configuration or metadata worth having. The subtler problem is that they change. When AWS adds an action to a service, it may add it to the corresponding managed policy, so a principal's effective permissions can widen without any change on your side and without appearing in your infrastructure diff. For a workload role, that is not acceptable in a regulated or high-value account. The honest middle ground most teams land on: AWS managed policies for the narrow, boilerplate service-integration grants where AWS's definition genuinely is the right one — the basic Lambda logging role being the classic — and customer managed policies, written from the actions the workload demonstrably calls, for everything the application itself does. ## A practical decision rule - Will more than one principal need this permission set, now or plausibly later? → customer managed. - Do you want an audit trail and a rollback for edits? → customer managed. - Must this permission die with exactly this principal and never be reusable? → inline. - Is this a well-known AWS integration grant with a purpose-built narrow AWS policy? → AWS managed is acceptable. - Is it an AWS managed policy whose name contains `FullAccess`? → almost certainly not for a workload role.
- Why is an AWS managed policy a risk even when it looks correctly scoped today?Because AWS maintains it. When a service ships new actions, AWS may add them to the policy, so every attached principal gains permissions with no change in your repository and nothing in your infrastructure diff to review. For workload roles, author a customer managed policy you control and can diff.
- When would you deliberately choose an inline policy?When the permission must be inseparable from one principal — a one-off privileged grant on a break-glass role, or per-tenant roles where reuse would itself be the bug. The inline document is deleted with the principal, so it cannot be orphaned or accidentally attached elsewhere. Accept that you give up versioning and central reporting.
- What do you do when a role needs more permissions than the managed-policy attachment limit allows?First consolidate: the usual cause is many small near-duplicate policies rather than genuine breadth. Merge them into fewer, coherently scoped customer managed policies, respecting the per-document character limit. If the role really does span that much, question whether it should be split into several roles instead of requesting a quota increase.
saying these in an interview costs you the question
- Attaches AmazonS3FullAccess to a workload role
- Thinks inline policies can be attached to several roles
- Believes AWS managed policies never change
- Expects version rollback on an inline policy
- Treats read-only managed policies as risk-free