Identity and Access Management (IAM) controls who can do what to which cloud resources. For data engineers, IAM is a daily operational requirement. Every Lambda function reading from S3, every Glue job writing to Redshift, every Airflow task calling an API needs correct IAM permissions. Too few permissions and the pipeline fails with `AccessDeniedException`; too many and a compromised pipeline can exfiltrate or destroy data across the entire cloud account. Getting IAM right separates a secure production system from a liability.
AWS IAM has four core components: Users (individual human identities with long-term credentials), Groups (collections of users sharing policies), Roles (temporary identities assumed by services or humans), and Policies (JSON documents defining allowed and denied actions). In modern data engineering, long-term IAM User access keys are largely replaced by IAM Roles — a Glue job assumes an execution role granting specific permissions for the job run, with temporary credentials rotated automatically. This eliminates the security risk of storing long-term access keys in code or environment variables.