Introduction & Context
The Problem This Lab Solves
Most AWS breaches do not originate from broken encryption or sophisticated exploits. They originate from credentials that had more access than they needed, were long-lived, and were never audited. IAM is the control plane for everything in AWS. If your IAM design is wrong, no other security control compensates for it.
This lab places you in the role of a cloud engineer at a company building a document processing pipeline. The system has two categories of actors: human operators who need to manage infrastructure, and EC2 instances that need to read and write specific S3 buckets as part of automated processing. Your job is to design an IAM model that gives every actor exactly what it needs — nothing more.
By the end of this lab you will have:
- An IAM group with a scoped policy granting read-only access to a specific S3 bucket
- An IAM user assigned to that group and tested against what they can and cannot do
- An IAM role that an EC2 instance can assume, granting write access to a separate processing bucket
- An EC2 instance using that role via instance profile, verified by querying the metadata service and running AWS CLI commands from within the instance
- Policy Simulator validation confirming allowed and denied actions before deployment
The measurable end result is a system where every identity has a documented reason for each permission it holds, and where attempts to exceed those permissions fail explicitly and predictably.
In this section, I confirmed:
0 of 3 completed