5.2.1. IAM Policies, RBAC, and Attribute-Based Access
💡 First Principle: Role-Based Access Control (RBAC) assigns permissions to roles, and users assume roles — "all data engineers get the DataEngineer role." Attribute-Based Access Control (ABAC) grants permissions based on tags — "any principal tagged department=finance can access any resource tagged department=finance." ABAC scales better when you have many resources and teams, because adding a new resource with the right tag automatically grants access to the right people.
RBAC implementation: Create IAM roles for each job function (DataEngineer, DataAnalyst, DataAdmin). Attach policies that grant minimum necessary permissions. Users assume the appropriate role. This is the traditional model and works well for small-to-medium organizations.
ABAC implementation (v1.1): Tag IAM principals and resources with matching attributes. Policies use condition keys (aws:PrincipalTag/department, aws:ResourceTag/department) to grant access when tags match. When a new dataset is created with department=marketing tag, marketing team members automatically gain access — no policy updates needed.
Tag-based access control is increasingly important in the exam. Lake Formation uses LF-Tags (Lake Formation Tags) to manage permissions at scale — instead of granting access to each table individually, you tag tables and grant access by tag.
Least privilege principle: Every IAM entity should have only the permissions needed for its task. The exam tests this through "which policy is most restrictive while still allowing the required access" questions. Overly broad policies (e.g., s3:* on *) are always wrong answers. IAM Access Analyzer helps here: external-access analysis reads resource-based policies (S3 buckets, KMS keys, IAM role trust policies, SQS queues, Lambda functions, Secrets Manager secrets and more) and reports any that grant access to principals outside your account or organization, and unused-access analysis flags permissions that are never used. It shows who could reach a resource — CloudTrail records who did.
⚠️ Exam Trap: IAM policy evaluation order matters: explicit Deny → explicit Allow → implicit Deny. If a user has an Allow policy for S3 read AND a Deny policy for a specific bucket, the Deny wins. The exam may present scenarios where an expected Allow doesn't work because of a Deny in another policy (SCP, resource policy, permission boundary). An SCP never grants anything: it sets the maximum permissions for every principal in the accounts it covers, so if the SCP doesn't allow S3, no IAM Allow in that account can. And a Deny scoped by a Condition denies only what the condition matches — if a Deny meant for tagged objects blocks every object, suspect the condition logic. A negated operator such as StringNotEquals, or any ...IfExists operator, evaluates true when the key is absent, and an untagged object has no s3:ExistingObjectTag/<key> at all, so the Deny matches every object. With a positive operator like StringEquals, a missing or mistyped key does the opposite: the condition is false and the Deny never applies.
Reflection Question: An organization has 50 data teams and 500 datasets. When a new team is created, administrators spend hours configuring access to relevant datasets. How does ABAC with tags simplify this?
