EP02: AWS Identity & Access Management (IAM) Deep Dive (Part2)
In my Last EP01, we covered the foundations of IAM—users, roles, policies, and STS. This week, we’re stepping into the advanced side of IAM!
Hi—this is Pranjali 👋, welcome to episode 02 of my DevOps Notes. Each week, I share insights, hands-on experiments, and useful tools from my DevOps & Cloud journey. My goal is simple: → help you learn faster, avoid mistakes, and grow as a DevOps professional.
Thanks for reading! If you are enjoying the Newsletter, please feel free to share it.
📚What I'm Reading this Week
"Lately, I’ve been more active on Substack, and this week I spent time reading and exploring some great newsletters. Here are a few articles I came across:"
🔐 Advanced IAM — The Next Layer of Security
When your AWS environment grows beyond a single account or a few developers, IAM must evolve. The key tools that make this possible are:
Permission Boundaries → Guardrails for IAM entities
Service Control Policies (SCPs) → Org-wide restrictions
IAM Conditions → Context-aware policies
IAM Access Analyzer → Risk detection
AWS Identity Center (SSO) → Centralized access
Let’s break them down 👇
🎯 Permission Boundaries — Guardrails for IAM
Analogy: A permission boundary is like a safety net for developers.
Even if someone tries to grant themselves AdminAccess, the boundary ensures they stay within limits.
📌 Why it matters: Prevents privilege escalation.
Example: Limit developers to S3 + DynamoDB only
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*",
"dynamodb:*"
],
"Resource": "*"
}
]
}
🏛️ Service Control Policies (SCPs) — Org-Wide Guardrails
SCPs are the laws of your AWS Organization. They don’t give permissions, but they set limits across all accounts.
📌 Why it matters: Enforce compliance across teams and accounts.
Example: Block EC2 outside ap-south-1
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ec2:*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": "ap-south-1"
}
}
}
]
}
🕵️ IAM Access Analyzer — Find Hidden Risks
Access Analyzer is AWS’s security auditor.
It continuously checks for external access paths to sensitive resources.
✅ Detects unintended access to:
S3 Buckets
IAM Roles
KMS Keys
Lambda Layers
📌 Why it matters: Prevents “oops, we left a bucket public” scenarios.
🌐 AWS Identity Center (SSO) — Simplify Multi-Account Access
When you have 10+ AWS accounts, managing IAM users becomes a nightmare.
Identity Center (formerly SSO) solves this:
One login → Multiple AWS accounts
Integrates with Okta, AD, Google Workspace
Assigns roles per account automatically
📌 Why it matters: Secure, scalable, and easier for users.
💬 Quote of the Week
“Good IAM isn’t about locking everything down.
It’s about giving the right people the right access—no more, no less.”
📌 Key Takeaways
Permission Boundaries = Guardrails for users/roles.
SCPs = Organization-wide laws.
Conditions = Context-aware control.
Access Analyzer = Finds hidden risks.
Identity Center = Simplifies multi-account access.
👉 Mastering these advanced features helps you scale securely without slowing down development.
💡 Interview Corner – IAM Special
Here are some scenario-based IAM questions for you to practice this week:
Cross-Account Access:
Your EC2 in Account A needs access to an S3 bucket in Account B. You cannot share access keys.
👉 How would you design IAM roles and policies for this?Least Privilege:
A developer only needs to runaws s3 lson a single bucket.
👉 What should the IAM policy look like?IAM vs Resource Policy:
You’ve attached an IAM policy granting S3 access, but still the user gets “Access Denied”.
👉 What could be missing?Temporary Credentials:
Your organization requires all AWS CLI access to use short-lived credentials instead of long-term keys.
👉 Which IAM feature would you use, and how would you enforce it?Service Accounts in Kubernetes (EKS):
Your pods running in EKS need to read secrets from AWS Secrets Manager securely without embedding keys.
👉 How would you set up IAM for this?
📬 Get in Touch
What’s been your trickiest IAM challenge—policies, cross-account roles, or key management? Reply and let me know, I’d love to feature your stories in the next issue.
If you enjoyed this, please drop ❤️ and share, and if you want to work with me or want to sponsor the newsletter, please email me at pranjalikomal5@gmail.com
See you at the next one! Until then → build secure, build smart.
— Pranjali, DevOps & Cloud Consultant ☁️
Thanks for reading! If you have not subscribed yet, you can subscribe here.