Managed vs inline policies in AWS - CLI Comparison

Introduction

When you control who can do what in your cloud account, you use policies. Managed policies are reusable and shared, while inline policies are attached directly to one user or role. This helps organize permissions clearly and safely.

When you want to give the same permissions to many users or roles without repeating the policy each time.

When you need a quick, one-off permission set for a single user or role that won't be reused.

When you want to update permissions in one place and have all users using that policy get the update automatically.

When you want to keep permissions tightly bound to a specific user or role for security reasons.

When you want to track exactly which permissions belong to which user or role without sharing.

Commands

This command creates a managed policy named ExampleManagedPolicy that allows listing all S3 buckets. Managed policies can be attached to multiple users or roles.

Terminal

aws iam create-policy --policy-name ExampleManagedPolicy --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"s3:ListBucket","Resource":"*"}]}'

Expected Output

{"Policy":{"PolicyName":"ExampleManagedPolicy","Arn":"arn:aws:iam::123456789012:policy/ExampleManagedPolicy","DefaultVersionId":"v1","AttachmentCount":0,"IsAttachable":true,"CreateDate":"2024-06-01T12:00:00Z","UpdateDate":"2024-06-01T12:00:00Z"}}

→

--policy-name - Sets the name of the managed policy.

→

--policy-document - Defines the permissions in JSON format.

This command attaches the managed policy to a user named example-user, giving them the permissions defined in the managed policy.

Terminal

aws iam attach-user-policy --user-name example-user --policy-arn arn:aws:iam::123456789012:policy/ExampleManagedPolicy

Expected Output

No output (command runs silently)

→

--user-name - Specifies the user to attach the policy to.

→

--policy-arn - Specifies the ARN of the managed policy to attach.

This command creates an inline policy named ExampleInlinePolicy directly attached to example-user, allowing them to get objects from a specific S3 bucket.

Terminal

aws iam put-user-policy --user-name example-user --policy-name ExampleInlinePolicy --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"s3:GetObject","Resource":"arn:aws:s3:::example-bucket/*"}]}'

Expected Output

No output (command runs silently)

→

--user-name - Specifies the user to attach the inline policy to.

→

--policy-name - Names the inline policy.

→

--policy-document - Defines the permissions in JSON format.

This command lists all inline policies attached to example-user, showing the names of inline policies directly attached.

Terminal

aws iam list-user-policies --user-name example-user

Expected Output

{"PolicyNames":["ExampleInlinePolicy"]}

→

--user-name - Specifies the user whose inline policies to list.

This command lists all managed policies attached to example-user, showing the ARNs and names of managed policies.

Terminal

aws iam list-attached-user-policies --user-name example-user

Expected Output

{"AttachedPolicies":[{"PolicyName":"ExampleManagedPolicy","PolicyArn":"arn:aws:iam::123456789012:policy/ExampleManagedPolicy"}]}

→

--user-name - Specifies the user whose managed policies to list.

Key Concept

If you remember nothing else from this pattern, remember: managed policies are reusable and shared, while inline policies are unique and attached directly to one user or role.

Common Mistakes

Trying to reuse inline policies by attaching them to multiple users.

Inline policies cannot be shared; they belong only to one user or role.

Use managed policies when you want to share permissions across multiple users or roles.

Updating a managed policy but forgetting that users have inline policies with conflicting permissions.

Inline policies are separate and do not update automatically with managed policies, causing permission conflicts.

Keep permissions consistent by using managed policies for shared permissions and inline policies only for unique cases.

Deleting a user without removing inline policies first.

Inline policies are deleted automatically with the user, but managed policies remain and can cause confusion if not detached.

Detach managed policies before deleting users and know that inline policies are removed with the user.

Summary

Create managed policies to reuse permission sets across many users or roles.

Attach managed policies to users or roles to grant shared permissions.

Use inline policies for one-off, user-specific permissions that won't be reused.

List inline and managed policies separately to understand user permissions clearly.

Practice

1. Which statement best describes an AWS managed policy?

easy

A. A policy that cannot be changed once created.

B. A policy embedded directly into a single user, group, or role.

C. A reusable permission set that can be attached to multiple users, groups, or roles.

D. A policy that only applies to AWS services, not users.

Solution

1. Step 1: Understand managed policy characteristics

   Managed policies are standalone and reusable permission sets in AWS.

2. Step 2: Compare with inline policies

   Inline policies are embedded directly into one user, group, or role, unlike managed policies.

3. Final Answer:

   A reusable permission set that can be attached to multiple users, groups, or roles. -> Option C

4. Quick Check:

   Managed policy = reusable permission set [OK]

Hint: Managed = reusable; Inline = embedded [OK]

Common Mistakes:

• Confusing inline policies as reusable
• Thinking managed policies are fixed and unchangeable
• Assuming managed policies apply only to services

2. Which of the following is the correct way to attach an inline policy to a user in AWS IAM?

easy

A. AttachPolicy(userName, policyArn)

B. PutUserPolicy(userName, policyName, policyDocument)

C. AttachUserPolicy(userName, policyName)

D. CreateInlinePolicy(policyDocument)

Solution

1. Step 1: Identify AWS IAM API for inline policies

   The correct API to attach an inline policy to a user is PutUserPolicy, which requires user name, policy name, and policy document.

2. Step 2: Eliminate incorrect options

   AttachPolicy and AttachUserPolicy are not valid AWS IAM API calls for inline policies. CreateInlinePolicy is not a valid standalone call.

3. Final Answer:

   PutUserPolicy(userName, policyName, policyDocument) -> Option B

4. Quick Check:

   Inline policy attachment uses PutUserPolicy [OK]

Hint: Inline policies use PutUserPolicy API [OK]

Common Mistakes:

• Using AttachPolicy which is for managed policies
• Confusing policy ARN with inline policy document
• Trying to create inline policy without specifying user

3. Given the following scenario: A user has both an inline policy allowing S3 read access and a managed policy denying S3 access. What is the effective permission for S3 access?

medium

A. The user cannot read S3 because explicit deny in managed policy overrides allow.

B. The user cannot read S3 because inline policies are ignored when managed policies exist.

C. The user can read S3 because managed policies are ignored if inline policies exist.

D. The user can read S3 because inline policies override managed policies.

Solution

1. Step 1: Understand AWS policy evaluation logic

   AWS evaluates all policies together. Explicit deny in any policy overrides any allow.

2. Step 2: Apply to scenario

   The managed policy denies S3 access explicitly, so even though inline policy allows it, deny takes precedence.

3. Final Answer:

   The user cannot read S3 because explicit deny in managed policy overrides allow. -> Option A

4. Quick Check:

   Explicit deny always overrides allow [OK]

Hint: Explicit deny beats allow, regardless of policy type [OK]

Common Mistakes:

• Thinking inline policies override managed policies
• Assuming allow always wins
• Ignoring explicit deny rules

4. You created an inline policy for a role but it is not granting the expected permissions. What is the most likely cause?

medium

A. The inline policy JSON syntax is invalid.

B. The role already has a managed policy attached with higher priority.

C. Inline policies cannot be attached to roles.

D. The inline policy name conflicts with an existing managed policy.

Solution

1. Step 1: Verify inline policy attachment rules

   Inline policies can be attached to roles, so Inline policies cannot be attached to roles. is incorrect.

2. Step 2: Check common issues with inline policies

   Invalid JSON syntax in the inline policy will prevent permissions from applying correctly.

3. Step 3: Understand policy priority

   Managed and inline policies are evaluated together; no priority overrides permissions except explicit deny.

4. Final Answer:

   The inline policy JSON syntax is invalid. -> Option A

5. Quick Check:

   Invalid JSON breaks policy effect [OK]

Hint: Check JSON syntax first for inline policy issues [OK]

Common Mistakes:

• Assuming inline policies can't attach to roles
• Thinking managed policies override inline by priority
• Confusing policy names causing conflicts

5. You manage a team where multiple users need the same permissions to access DynamoDB. You also have one user who needs a unique permission set. What is the best approach to assign policies?

hard

A. Use only managed policies for all users, including the unique one.

B. Create inline policies for all users to keep permissions separate.

C. Attach the same inline policy to all users and add extra inline policies for the unique user.

D. Create a managed policy for the common permissions and attach it to all users; create an inline policy for the unique user.

Solution

1. Step 1: Identify best practice for shared permissions

   Managed policies are reusable and ideal for common permissions shared by multiple users.

2. Step 2: Handle unique permissions

   Inline policies are best for unique, one-off permissions tied to a single user.

3. Step 3: Combine approaches for efficiency and clarity

   Use managed policy for the team and inline policy for the unique user to avoid duplication and ease management.

4. Final Answer:

   Create a managed policy for the common permissions and attach it to all users; create an inline policy for the unique user. -> Option D

5. Quick Check:

   Managed for shared, inline for unique [OK]

Hint: Managed for many users, inline for one user [OK]

Common Mistakes:

• Using inline policies for all users causing duplication
• Using only managed policies losing unique control
• Attaching same inline policy to multiple users