Press enter or click to view image in full size

A hands-on exercise in enforcing permissions correctly by attaching an existing IAM policy to a specific user — where access control actually becomes effective.

3 min read3 hours ago

–

Introduction

Day 19 of the KodeKloud AWS Challenge focused on a deceptively simple but critical task: attaching an existing IAM policy to an existing IAM user.

An IAM policy sitting unused does nothing. An IAM user without policies can’t do anything.

Real AWS security happens only when the two are correctly connected. This task reinforced how permissions are actually applied in production — not assumed.

Concept Explanation: IAM Users + IAM Policies (How Access Really Works)

In AWS IAM, access control is a two-part system:

• IAM User → represents who is making the request
• IAM Policy → defines what actions are allowed or denied

Until a policy is attached (directly or indirectly), a user has zero permissions.

Get Kishor Bhairat’s stories in your inbox

Join Medium for free to get updates from this writer.

AWS evaluates permissions by:

• Identifying the principal (IAM user)
• Collecting all attached policies
• Evaluating allowed vs denied actions
• Enforcing the final decision

No attachment = no access. Wrong attachment = wrong access.

Why This Matters in Real Environments

In production AWS accounts:

• Policies are often pre-created and reviewed
• Users are onboarded by attaching approved policies
• Access changes are tracked and auditable

This separation ensures:

• Security teams control what policies exist
• Admins control who gets which access
• Engineers don’t accidentally over-permission users

This is basic IAM hygiene — and audits expect it.

Prerequisites / Gotchas

Before attaching a policy, a few things must be true:

• The IAM user must already exist
• The IAM policy must already exist
• You need IAM permissions to attach policies
• IAM changes are eventually consistent
• Multiple attached policies result in combined permissions
• Explicit Deny always overrides Allow

Attaching policies blindly is how privilege creep starts.

Hands-On Task: What I Did

The task requirements were clear:

• IAM user: iamuser_kirsty
• IAM policy: iampolicy_kirsty

Execution steps:

• Logged in to the AWS Management Console
• Navigated to IAM → Users
• Selected the user iamuser_kirsty
• Opened the Permissions tab
• Chose Add permissions

Press enter or click to view image in full size

• Selected Attach policies directly
• Located and selected iampolicy_kirsty
• Reviewed and attached the policy

Press enter or click to view image in full size

• Verified the policy appeared under the user’s permissions

Press enter or click to view image in full size

This is exactly how controlled access is granted in real AWS accounts.

What I Learned / Key Takeaways

• IAM policies are useless until attached
• Users gain power only through explicit permission assignment
• Direct attachment works, but groups scale better
• Auditable access depends on clean attachments
• Least privilege starts with intentional policy usage

This task reinforces discipline — not complexity.

Conclusion

Attaching an IAM policy to a user is where theory becomes enforcement.

This challenge highlighted that AWS security is not about creating users or writing policies — it’s about connecting the right permissions to the right identities at the right time.

Clean IAM design prevents outages, audit failures, and security incidents.

On to the next challenge — where permission models get even more layered.

Call to Action

If you’re learning AWS or DevOps through hands-on challenges and real IAM workflows, follow the journey. This series focuses on practical skills that actually translate to production.