This chapter dives deep into AWS IAM policies, specifically the difference between inline and managed policies — a critical topic for the CLF-C02 exam under Security Compliance (Objective 2.2). Understanding this distinction is essential because the exam tests your ability to choose the right policy type for different scenarios, and it accounts for roughly 15-20% of the Security domain questions. By the end of this chapter, you'll not only know the definitions but also the practical implications for security, management overhead, and compliance.
Jump to a section
Imagine you run a company with multiple offices. You have two ways to give employees access. The first is a traditional metal key that is unique to each door. If you need to change who can enter a room, you must physically replace the key for every employee who has it. That's an inline policy — it's directly attached to each person and must be updated individually. The second is a programmable key card system. You create a master list of access rules (e.g., 'all HR staff can enter the HR office') and assign that list to a group. When an employee joins HR, you simply give them a key card linked to that group. If the access rule changes, you update the master list once, and everyone's card automatically reflects the change. That's a managed policy — it's reusable, centrally updatable, and attached to groups or roles, not individuals. The mechanism: inline policies are embedded directly into the IAM user, group, or role and cannot be reused elsewhere; managed policies exist as standalone objects in AWS IAM that can be attached to multiple principals. This makes managed policies easier to maintain and audit at scale.
What Are IAM Policies and Why Do They Matter?
AWS Identity and Access Management (IAM) policies are JSON documents that define permissions — who can do what with which AWS resources. They are the backbone of security in AWS. Without policies, no principal (user, group, or role) can perform any action. Policies can be attached to IAM users, groups, or roles, and they can also be attached to resources (resource-based policies). The CLF-C02 exam focuses on identity-based policies, which are attached to IAM principals.
The Problem: Permission Management at Scale
Imagine you have 100 employees, each needing slightly different permissions. If you write a unique policy for each employee and attach it directly to their user account, you create a maintenance nightmare. When a permission needs to change — say, a new S3 bucket is added — you must update every individual policy. This is error-prone and time-consuming. AWS provides two solutions: inline policies and managed policies. The exam expects you to understand the trade-offs.
Inline Policies: The Direct Approach
An inline policy is a policy that is embedded directly into an IAM user, group, or role. It is not a standalone entity; it exists only as part of that principal. You can create an inline policy in the AWS Management Console by navigating to the user/group/role and adding a policy directly in the JSON editor. There is no separate ARN for an inline policy. Inline policies are useful when you need a strict one-to-one relationship between a principal and a set of permissions that should never be reused. For example, a service account that performs a unique function might have an inline policy that grants exactly the permissions it needs, and no other principal should ever have those exact permissions.
Key characteristics of inline policies: - They are part of the principal's definition; deleting the principal deletes the policy. - They cannot be shared or reused across multiple principals. - They are harder to audit because you must check each principal individually. - They are ideal for exceptional cases or temporary permissions.
Managed Policies: Reusable and Centralized
A managed policy is a standalone IAM policy object that you can attach to multiple IAM users, groups, or roles. AWS provides two types: AWS managed policies (created and maintained by AWS) and customer managed policies (created and managed by you). Managed policies have their own ARN, versioning, and can be updated independently of the principals they are attached to. When you update a managed policy, all principals attached to it automatically receive the new permissions.
Key characteristics of managed policies: - They are reusable; one policy can be attached to hundreds of principals. - They support versioning; you can roll back to a previous version if needed. - They are easier to audit; you can list all principals attached to a policy. - AWS managed policies are kept up-to-date by AWS as services evolve.
How Policies Are Evaluated
When a principal makes a request, AWS evaluates all applicable policies — both inline and managed — to determine whether to allow or deny the action. The evaluation logic is as follows:
By default, all requests are denied.
An explicit allow in any policy (inline or managed) overrides the default deny.
An explicit deny in any policy overrides any allow.
This means that if you have an inline policy that allows access to S3, but a managed policy attached to the same user denies access to S3, the deny wins. The exam tests this 'explicit deny' principle frequently.
Comparison to On-Premises: Role-Based Access Control (RBAC)
In an on-premises environment, you might manage permissions using Active Directory groups. Each group has a set of permissions, and users are added to groups. This is analogous to managed policies — you define permissions once and assign them to groups. Inline policies are like giving individual users unique permissions that are not tied to any group — a practice that is generally discouraged because it leads to 'permission sprawl' and makes auditing difficult. AWS encourages using managed policies and groups to align with the principle of least privilege at scale.
When to Use Inline vs Managed
Use managed policies when you need to apply the same permissions to multiple principals (e.g., all developers need access to the same development S3 bucket).
Use inline policies when you need a unique, one-off permission set that should not be reused (e.g., a specific contractor needs temporary access to a single resource).
Use AWS managed policies for common use cases like full administrator access (AdministratorAccess) or read-only access (ReadOnlyAccess). These are maintained by AWS and automatically updated as new services launch.
Use customer managed policies when you need to customize permissions beyond what AWS managed policies offer, but you still want reusability and versioning.
Pricing
IAM policies themselves are free. There is no charge for creating inline or managed policies, or for attaching them to principals. However, there are limits: you can have up to 1,500 customer managed policies per AWS account, and each policy can be up to 6,144 characters in length. Inline policies are limited to 2,048 characters per policy, and you can have up to 10 inline policies per user/group/role.
Step-by-Step Configuration
Creating a customer managed policy in the console: 1. Navigate to IAM > Policies > Create policy. 2. Choose the service (e.g., S3) and specify actions (e.g., ListBucket, GetObject). 3. Specify the resource ARN (e.g., arn:aws:s3:::example-bucket/*). 4. Review the policy and give it a name (e.g., MyS3ReadOnly). 5. After creation, you can attach it to users, groups, or roles.
Creating an inline policy: 1. Navigate to IAM > Users (or Groups or Roles) > Select the principal. 2. Go to the Permissions tab and click 'Add inline policy'. 3. Define the policy using the visual editor or JSON. 4. The policy is saved as part of that principal only.
Exam-Focused Details
The CLF-C02 exam expects you to know:
The difference between inline and managed policies.
That AWS managed policies are created and maintained by AWS.
That customer managed policies are reusable and versioned.
That inline policies are embedded and not reusable.
That you can attach both inline and managed policies to the same principal.
The evaluation logic: explicit deny overrides allow.
Common exam scenarios:
A company wants to ensure all developers have the same permissions. Which policy type? Managed.
A temporary contractor needs specific permissions that no one else should have. Which policy type? Inline.
You need to update a permission for 50 users. Which approach is easier? Update a managed policy.
Trap Patterns
Trap 1: The question asks which policy type is 'more secure' and the candidate picks inline because it's unique. Reality: Security is about least privilege and manageability. Inline policies can lead to unmanaged permissions and audit difficulties.
Trap 2: The candidate thinks managed policies cannot be edited. Reality: Customer managed policies can be edited and versioned; AWS managed policies can be copied to create custom versions.
Trap 3: The candidate confuses 'inline policy' with 'resource-based policy'. Inline policies are identity-based; resource-based policies are attached to resources like S3 buckets.
Trap 4: The candidate thinks that if a user has both an inline allow and a managed deny, the allow wins. Reality: Explicit deny always overrides allow.
Best Practices
Use managed policies for standard permissions; use inline policies only for exceptions.
Use groups to organize users and attach managed policies to groups rather than directly to users.
Regularly audit inline policies to ensure they are still needed.
Leverage AWS managed policies for common use cases to reduce maintenance.
Conclusion
Inline and managed policies serve different purposes. Managed policies promote reusability, centralized management, and easier auditing — aligning with AWS best practices. Inline policies are a necessary tool for one-off or temporary permissions but should be used sparingly. The CLF-C02 exam will test your understanding of these concepts through scenario-based questions. Master this distinction to secure your pass.
Identify the Permission Need
Before creating any policy, you must define the exact permissions required. For example, a developer needs to list objects in an S3 bucket and get objects, but not delete them. Write down the actions, resources, and conditions. This step is critical for least privilege. AWS recommends starting with AWS managed policies and then narrowing down. For the CLF-C02, remember that you should always grant the minimum permissions necessary.
Choose Inline or Managed
Decide based on reusability. If the permissions will be needed by multiple users (e.g., all developers), choose a managed policy. If the permissions are unique to one user (e.g., a temporary admin), choose an inline policy. The exam often presents a scenario where a company has many employees needing the same access — that's a clear signal for managed policies. Also consider future changes: managed policies are easier to update centrally.
Create the Policy in IAM
For a managed policy, go to IAM > Policies > Create policy. Use the visual editor or JSON. Specify the service (e.g., S3), actions (e.g., ListBucket, GetObject), and resources (e.g., arn:aws:s3:::example-bucket/*). For an inline policy, go to the specific user/group/role, select 'Add inline policy', and define the policy similarly. AWS will validate the JSON syntax. Note that managed policies have a size limit of 6,144 characters; inline policies have 2,048 characters.
Attach the Policy to Principal(s)
For managed policies, you can attach them to multiple users, groups, or roles by selecting the policy and choosing 'Attach'. For inline policies, they are automatically attached to the principal you created them for. You can attach multiple managed policies and inline policies to the same principal. The effective permissions are the union of all allows minus any denies. Remember: explicit deny overrides allow.
Test and Audit Permissions
After attaching policies, test access using the IAM Policy Simulator or by actually performing actions. For auditing, use IAM Access Analyzer to identify unused permissions. Managed policies make auditing easier because you can see all principals attached to a policy. Inline policies require checking each principal individually. The exam emphasizes that managed policies improve auditability and reduce the risk of permission sprawl.
Scenario 1: Enterprise Developer Access A large company has 200 developers who need read-only access to production logs stored in S3. The security team wants to ensure that permissions are consistent and easy to update. They create a customer managed policy called 'ProdLogsReadOnly' that grants s3:ListBucket and s3:GetObject on the specific log bucket. They attach this policy to an IAM group called 'Developers' and add all developers to that group. When a new developer joins, they are simply added to the group. When the log bucket changes, the policy is updated once. This approach uses managed policies and groups, following AWS best practices. Cost: no additional cost for policies. Misconfiguration: if the policy is too broad (e.g., allowing access to all S3 buckets), it could lead to data leaks.
Scenario 2: Temporary Contractor A contractor is hired for two weeks to migrate data from an on-premises server to an S3 bucket. They need full access to that specific bucket but nothing else. The security team creates an inline policy attached directly to the contractor's IAM user account. The policy grants s3:PutObject, s3:GetObject, s3:ListBucket, and s3:DeleteObject on the target bucket. After the contract ends, the user account is deleted, and the inline policy is automatically removed. This is a good use case for inline policies because the permissions are unique and temporary. Misconfiguration: if the inline policy is not deleted after the contractor leaves, it becomes a security risk.
Scenario 3: Compliance and Auditing A financial services company must comply with SOC 2 and needs to audit all IAM policies quarterly. They use AWS managed policies for standard roles (e.g., ReadOnlyAccess) and customer managed policies for custom roles. They avoid inline policies because they are harder to track. Using IAM Access Analyzer, they generate a report of all policies and their attachments. This centralized approach saves time during audits. Misconfiguration: if inline policies are used extensively, auditors may miss some permissions, leading to compliance failures.
What CLF-C02 Tests on This Objective Objective 2.2 (Security Compliance) tests your ability to differentiate between inline and managed policies. Expect scenario-based questions where you must choose the best policy type. The exam will also test the evaluation logic (explicit deny). Specific terms you need to know: 'inline policy', 'managed policy', 'customer managed policy', 'AWS managed policy', 'IAM group', 'explicit deny', 'least privilege'.
Common Wrong Answers and Why 1. 'Inline policies are more secure because they are unique.' Wrong. Security is about manageability and least privilege. Inline policies can lead to unmanaged permissions and are harder to audit. Managed policies promote consistency and easier review. 2. 'Managed policies cannot be edited.' Wrong. Customer managed policies can be edited and versioned. Only AWS managed policies cannot be edited directly, but you can copy them to create a custom version. 3. 'You should always use inline policies for users.' Wrong. AWS best practice is to use groups and managed policies. Inline policies should be reserved for exceptions. 4. 'If a user has an inline allow and a managed deny, the allow wins.' Wrong. Explicit deny always overrides any allow, regardless of policy type.
Tricky Distinctions - Inline vs Resource-based policies: Inline policies are identity-based (attached to a principal). Resource-based policies are attached to resources (e.g., S3 bucket policy). The exam may test this distinction. - AWS Managed vs Customer Managed: AWS managed policies are maintained by AWS and cannot be edited. Customer managed policies are under your control and support versioning. - Policy size limits: Inline: 2,048 characters; Managed: 6,144 characters. The exam may ask about limits.
Decision Rule for Multiple Choice - If the question asks about reusability or centralized management → choose managed. - If the question asks about a unique, one-time permission set → choose inline. - If the question asks about auditing or ease of updates → choose managed. - If the question mentions 'explicit deny' → remember that deny wins over allow.
Memorize: 'Managed for groups, inline for exceptions.'
Inline policies are embedded directly into an IAM principal and cannot be reused.
Managed policies are standalone objects that can be attached to multiple principals.
AWS managed policies are created and maintained by AWS; customer managed policies are custom and versioned.
Explicit deny in any policy overrides any allow, regardless of policy type.
Use managed policies for standard, reusable permissions; use inline policies for one-off or temporary permissions.
Managed policies improve auditability and reduce management overhead.
IAM groups combined with managed policies follow the principle of least privilege at scale.
Policy size limits: inline 2,048 chars, managed 6,144 chars.
These come up on the exam all the time. Here's how to tell them apart.
Inline Policy
Embedded directly in the IAM user, group, or role.
Cannot be reused across multiple principals.
No separate ARN; exists only as part of the principal.
Harder to audit; must check each principal individually.
Size limit: 2,048 characters.
Managed Policy
Standalone IAM object with its own ARN.
Reusable; can be attached to many principals.
Supports versioning (customer managed).
Easier to audit; can list all attached principals.
Size limit: 6,144 characters (customer managed).
Mistake
Inline policies are more secure because they are attached to a single user.
Correct
Security is not about uniqueness but about manageability and least privilege. Inline policies are harder to audit and can lead to permission sprawl. Managed policies allow centralized control and easier review.
Mistake
Managed policies cannot be modified after creation.
Correct
Customer managed policies can be modified and support versioning. Only AWS managed policies cannot be edited, but you can create a copy and edit the copy.
Mistake
You can only attach one type of policy to a user.
Correct
A user can have multiple inline policies and multiple managed policies attached simultaneously. The effective permissions are the union of all allows minus any denies.
Mistake
Inline policies are automatically deleted when the user is removed.
Correct
Yes, because inline policies are embedded in the user. When the user is deleted, the inline policy is also deleted. Managed policies remain as standalone objects.
Mistake
AWS managed policies are the best choice for all situations.
Correct
AWS managed policies are great for common use cases, but they may be too permissive for least privilege. Customer managed policies allow you to tailor permissions exactly.
An inline policy is embedded directly into an IAM user, group, or role and cannot be reused. A managed policy is a standalone object that can be attached to multiple principals. Managed policies support versioning and are easier to audit. Use managed policies for reusable permissions and inline policies for unique, one-off permissions.
Yes, you can attach multiple inline and managed policies to the same user. The effective permissions are the union of all allows minus any explicit denies. If there is a conflict, an explicit deny in any policy overrides an allow.
AWS managed policies are pre-built policies created and maintained by AWS. They cover common use cases like full admin access (AdministratorAccess) or read-only access (ReadOnlyAccess). You cannot edit them, but you can copy them to create custom policies. They are automatically updated as AWS services evolve.
Choose managed policies when you need to apply the same permissions to multiple principals, want centralized management, or need versioning. Choose inline policies when the permissions are unique to a single principal and should not be reused. AWS best practice is to use managed policies with IAM groups.
The inline policy is deleted along with the user because it is embedded in the user. Managed policies remain as standalone objects and can be attached to other principals. This is a key difference: inline policies are tied to the principal's lifecycle.
Yes. Inline policies have a maximum size of 2,048 characters. Customer managed policies have a maximum size of 6,144 characters. AWS managed policies also have size limits but are maintained by AWS. Exceeding these limits will cause an error when creating the policy.
AWS evaluates all policies (inline and managed) attached to the principal, as well as resource-based policies if applicable. The default is deny. An explicit allow in any policy overrides the default. An explicit deny in any policy overrides any allow. This is known as the 'explicit deny' principle.
You've just covered AWS IAM Policies — Inline vs Managed — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?