AWS IAM Attribute-Based Access Control with Tags | AWS Systems Architect Professional

Study guide

Technical reference and lesson notes

Purpose of This Lesson

This lesson explains how to implement Attribute-Based Access Control, or ABAC, in AWS using IAM principal tags, resource tags, and IAM policy conditions. The example uses an IAM user named Dave, an IAM group named DB admins, and two Amazon RDS databases tagged as production and development.

For the SAP-C02 exam, ABAC is important because AWS often expects you to choose scalable permission models for large environments. Instead of creating a separate IAM policy for every team, application, or environment, ABAC allows access decisions to be made dynamically based on tags.

Key Concepts

What Is Attribute-Based Access Control?

Attribute-Based Access Control is an authorization model where permissions are granted based on attributes.

In AWS, those attributes are usually tags.

Common ABAC attributes include:

User department
Project name
Environment
Cost center
Application name
Data classification
Team ownership

Example:

Principal tag:
department = DB admins

Resource tag:
environment = production

A policy can then say:

Allow DB admins to perform specific RDS actions only when the RDS database is tagged as production.

This makes access control more dynamic than traditional role-based access control.

ABAC Versus RBAC

RBAC and ABAC both control access, but they work differently.

Model	Access Based On	Example
RBAC	User’s role or group membership	User is in the `DB admins` group
ABAC	Tags or attributes on principals and resources	User has `department=DB admins` and resource has `environment=production`

RBAC works well when job roles are stable and easy to define.

ABAC works better when permissions need to scale across many users, teams, projects, and environments.

In this lesson, both models are used together:

RBAC: Dave is placed into the DB admins group.
ABAC: Dave’s access is controlled by tags and IAM policy conditions.

ABAC Design Pattern in the Lesson

The access design looks like this:

IAM User: Dave
Tag: department = DB admins
        ↓
IAM Group: DB admins
        ↓
Inline IAM Policy
        ↓
Amazon RDS Resources
prod DB tag: environment = production
dev DB tag: environment = development

The goal is to allow Dave to perform limited RDS administration actions only against the database that matches the policy condition.

Dave should be able to:

Describe RDS databases
Reboot the production database
Start the production database
Stop the production database

Dave should not be able to:

Reboot the development database, unless the policy condition is changed
Delete databases
Perform unrelated RDS actions
Administer IAM or other AWS services

IAM Principal Tags

A principal tag is a tag attached to an IAM principal.

IAM principals can include:

IAM users
IAM roles
Federated users
Assumed-role sessions

In the example, Dave is tagged as:

department = DB admins

This tag becomes part of the access decision.

The IAM policy condition checks whether the principal has the correct department tag before allowing the requested action.

This is powerful because the policy does not need to list Dave by name. It can apply to any principal with the correct tag.

Resource Tags

A resource tag is a tag attached to an AWS resource.

In the lesson, two Amazon RDS databases are created:

Database	Resource Tag
prod DB	`environment = production`
dev DB	`environment = development`

The IAM policy allows certain actions only when the RDS resource has the correct tag value.

For example, the policy can allow DB admins to reboot only databases tagged as production.

This supports a scalable access model where the tag on the resource helps determine who can manage it.

IAM Policy Conditions

IAM policy conditions are where ABAC becomes useful.

The policy can include a condition that evaluates:

The tag on the principal
The tag on the resource
The requested AWS action
Other context keys, such as source IP, MFA status, requested region, or organization ID

In this lesson, the condition checks for a specific principal tag and a specific RDS resource tag.

Conceptually, the policy logic is:

Allow these RDS actions:
- RebootDBInstance
- StartDBInstance
- StopDBInstance

Only if:
- Principal tag department = DB admins
- Resource tag environment = production

This means Dave can perform the allowed RDS actions against the production database but not the development database.

Why Describe Permissions Are Needed

The lesson includes a policy statement allowing describe actions such as:

rds:DescribeDBInstances
rds:DescribeDBClusters
rds:DescribeGlobalClusters

These are allowed on all resources.

This is important because users often need read/list/describe permissions to navigate the AWS console.

Without describe permissions, the user may have permission to perform an action but may not be able to view the resources in the console properly.

For exam scenarios, remember this distinction:

Permission Type	Purpose
Describe/List permissions	Allows visibility into resources
Start/Stop/Reboot permissions	Allows operational actions
Delete permissions	Allows destructive actions

A least-privilege policy often grants broad read visibility but tightly restricts write or administrative actions.

Amazon RDS Actions Used in the Example

The example focuses on operational RDS actions:

RDS Action	Purpose
`rds:DescribeDBInstances`	View RDS DB instances
`rds:DescribeDBClusters`	View RDS clusters
`rds:DescribeGlobalClusters`	View global RDS clusters
`rds:RebootDBInstance`	Reboot a DB instance
`rds:StartDBInstance`	Start a stopped DB instance
`rds:StopDBInstance`	Stop a running DB instance

The policy does not allow delete actions.

That is why Dave can reboot a permitted database but cannot delete it.

Testing ABAC Behavior

The test confirms that ABAC is working:

Test	Result	Reason
Dave reboots production RDS database	Allowed	Resource tag matches `environment=production`
Dave reboots development RDS database	Denied	Resource tag does not match policy condition
Policy condition is changed to development	Dave can reboot development database	Policy now matches `environment=development`
Dave attempts to delete a database	Denied	Delete action is not allowed in the policy

This is an important exam concept: access is not only about who the user is. It is also about the requested action, the resource, and whether policy conditions match.

Inline Policies Versus Managed Policies

The lesson uses an inline policy attached to the DB admins group.

An inline policy is embedded directly into a single IAM identity, such as a user, group, or role.

Policy Type	Description	Best Use
AWS managed policy	Created and maintained by AWS	Common job functions, quick setup
Customer managed policy	Created and managed by you	Reusable custom permissions
Inline policy	Embedded in one identity	One-off tightly scoped permissions

For production environments, customer managed policies are usually easier to reuse and audit than inline policies.

Inline policies can be useful for a tightly coupled permission that should not be reused elsewhere.

ABAC and Least Privilege

ABAC supports least privilege because access can be limited by both identity and resource attributes.

In the lesson, Dave is not given blanket RDS administrator access. Instead, he receives permission to perform only specific operational actions and only against matching tagged resources.

This is better than granting:

Full RDS access
Full administrator access
Access to every database
Access to every environment
Delete permissions when only reboot/start/stop are needed

For SAP-C02, expect scenarios where AWS wants a scalable least-privilege model. ABAC is often a strong answer when access must scale across many projects, teams, or environments.

Exam-Relevant Takeaways

For the SAP-C02 exam, remember:

ABAC uses attributes, usually tags, to make authorization decisions.
Principal tags can be attached to IAM users, roles, or federated sessions.
Resource tags can be attached to AWS resources such as RDS databases.
IAM policy conditions compare tags and other request context values.
ABAC is useful when permissions need to scale across many teams, projects, or environments.
RBAC and ABAC can be combined.
IAM groups can organize users, while ABAC conditions refine what those users can access.
Describe/List permissions are often needed for console visibility.
Allowing rds:RebootDBInstance does not allow rds:DeleteDBInstance.
Access is denied when the tag condition does not match.
Changing the policy condition can change which tagged resources are accessible.
ABAC depends heavily on consistent tagging.
Poor tag governance can break access control or accidentally grant access.
ABAC is most effective when tag keys and values are standardized across the organization.

Architecture Decision Guide

Scenario	Best AWS Choice	Why
DB admins need to reboot only production RDS databases	ABAC using principal tags and RDS resource tags	Allows access only when tag conditions match
Finance users need billing access	RBAC with billing group or IAM Identity Center permission set	Access maps cleanly to a job function
Developers need access only to resources tagged with their project	ABAC	Scales better than creating many project-specific policies
A small team has simple fixed roles	RBAC with IAM groups or Identity Center groups	Easier to understand and manage
A large enterprise has many accounts, teams, and projects	IAM Identity Center plus ABAC/tag-based permissions	Supports centralized and scalable access
A workload on EC2 needs access to AWS services	IAM role attached to an instance profile	Avoids long-lived access keys
A user needs temporary elevated access	IAM role or IAM Identity Center permission set	Better than permanent permissions
A user needs to view RDS resources in the console	Add appropriate Describe/List permissions	Console visibility often requires read permissions
A user can reboot production but not development	Check resource tags and policy conditions	ABAC depends on matching tag values
A user should not delete databases	Do not include delete actions in the policy	Least privilege requires action-level control

Common Exam Traps

Trap 1: Confusing RBAC and ABAC

RBAC is based on roles or groups.

ABAC is based on attributes such as tags.

A question that focuses on dynamic access based on project, department, or environment tags is usually pointing toward ABAC.

Trap 2: Forgetting That Tags Must Match Exactly

If the policy expects:

environment = production

but the resource is tagged:

Environment = Production

or:

environment = prod

the condition may not match.

Tag consistency matters.

Trap 3: Granting Full RDS Access When Only Reboot Is Required

If the requirement is to reboot, start, or stop RDS databases, do not grant full RDS administrator access.

Choose the least-privilege policy with specific RDS actions.

Trap 4: Forgetting Describe Permissions

A user may need describe/list permissions to see resources in the AWS console.

If an answer includes only write actions but no visibility permissions, it may not support practical console use.

Trap 5: Assuming Reboot Permission Allows Delete

Permissions are action-specific.

Allowing rds:RebootDBInstance does not imply rds:DeleteDBInstance.

Each API action must be explicitly allowed.

Trap 6: Ignoring Tag Governance

ABAC can become risky if tags are inconsistent or if users can modify their own tags or resource tags.

For secure ABAC, control who can create, update, or delete authorization-related tags.

Trap 7: Using IAM Users Everywhere

IAM users are useful for learning and some legacy cases, but modern workforce access is usually better handled through IAM Identity Center and federation.

For multi-account enterprise environments, avoid creating separate IAM users in each account.

Trap 8: Assuming Group Membership Alone Controls Access

In this example, group membership provides the policy, but the actual authorization decision also depends on tags.

Dave is in the DB admins group, but he still cannot reboot the development database until the policy condition matches the development tag.

Real-World Engineer Notes

In real AWS environments, ABAC is powerful but requires discipline.

The technical policy is only one part of the design. The real operational challenge is tag governance.

Before relying on ABAC, an organization should define:

Approved tag keys
Approved tag values
Who can apply tags
Who can modify tags
Which tags are security-sensitive
How tag compliance is audited
What happens when resources are missing required tags

For example, if environment is used for access control, then not everyone should be allowed to change a database from:

environment = development

to:

environment = production

That could unintentionally grant access.

In production, you would likely combine ABAC with:

IAM Identity Center
AWS Organizations
Service control policies
Permissions boundaries
Tag policies
CloudTrail logging
AWS Config rules
Infrastructure as Code
Change control

From a troubleshooting standpoint, ABAC failures often come down to one of these issues:

Principal missing the expected tag
Resource missing the expected tag
Tag key or value typo
Policy condition mismatch
Action not included in the policy
Resource ARN not covered by the policy
Explicit deny from another policy
SCP blocking the action
User attempting an action not allowed, such as delete

For cloud engineers, ABAC is especially useful in environments where teams manage shared AWS accounts but should only touch their own workloads. It can reduce policy sprawl, but only if tagging is standardized and enforced.

Quick Reference Summary

ABAC grants access based on attributes, usually tags.

In AWS, ABAC commonly compares IAM principal tags with AWS resource tags using IAM policy conditions.

In this example, Dave has the principal tag:

department = DB admins

The production RDS database has the resource tag:

environment = production

The IAM policy allows Dave to reboot, start, and stop RDS databases only when the tag condition matches.

Dave can reboot the production database but cannot reboot the development database unless the policy condition is changed.

Dave cannot delete either database because delete permissions are not included.

For SAP-C02, remember that ABAC is a scalable authorization pattern, but it depends on strong tag governance and least-privilege policy design.

Flashcards

Q: What does ABAC stand for?
A: Attribute-Based Access Control.

Q: What does ABAC commonly use in AWS to make access decisions?
A: Tags, such as principal tags and resource tags.

Q: What is a principal tag?
A: A tag attached to an IAM principal, such as a user, role, or federated session.

Q: What is a resource tag?
A: A tag attached to an AWS resource, such as an RDS database.

Q: In the lesson example, what tag is attached to Dave?
A: department = DB admins.

Q: In the lesson example, what tag is attached to the production database?
A: environment = production.

Q: Why can Dave reboot the production database?
A: His principal tag and the production database’s resource tag satisfy the IAM policy condition.

Q: Why is Dave denied when trying to reboot the development database?
A: The development database has a different resource tag value, so the policy condition does not match.

Q: Does permission to reboot an RDS database also allow deleting it?
A: No. IAM permissions are action-specific.

Q: Why are describe permissions often included in IAM policies?
A: They allow users to view resources, especially in the AWS Management Console.

Q: What is a major operational requirement for ABAC?
A: Strong tag governance and consistent tagging standards.

Q: When is ABAC a good choice?
A: When access must scale dynamically across many users, projects, teams, or environments.

Q: How can RBAC and ABAC work together?
A: RBAC can assign a policy through group membership, while ABAC conditions refine access based on tags.

Q: What happens if a resource is missing the required tag?
A: The condition will not match, so access is denied unless another policy allows it.

Q: What is a common security risk with ABAC?
A: Allowing users to modify authorization-related tags can lead to privilege escalation.

Practice Questions

Question 1:
A company wants database administrators to reboot only Amazon RDS databases tagged as environment=production. The administrators should not be able to reboot development databases. Which design best meets this requirement?

A. Attach the AmazonRDSFullAccess policy to every database administrator
B. Create an IAM policy that allows reboot actions only when the RDS resource tag matches environment=production
C. Give the administrators root account access during maintenance windows
D. Create separate AWS accounts for every RDS database

Correct Answer:
B

Explanation:
ABAC is the best fit when access should be controlled based on resource tags. The policy should allow only the required RDS actions and include a condition requiring the production tag.

Question 2:
An IAM user has the principal tag department=DB admins. An IAM policy allows rds:RebootDBInstance only when the resource tag environment=production is present. The user attempts to reboot an RDS instance tagged environment=development. What happens?

A. The reboot succeeds because the user is a DB admin
B. The reboot succeeds because RDS does not support tag-based access
C. The reboot is denied because the resource tag does not match the policy condition
D. The reboot succeeds if the user can describe the database

Correct Answer:
C

Explanation:
ABAC depends on matching tag conditions. The user’s principal tag alone is not enough. The resource must also satisfy the condition.

Question 3:
A user can see RDS databases in the AWS console and can reboot one database, but cannot delete it. What is the most likely explanation?

A. The user has describe and reboot permissions, but not delete permissions
B. The AWS console does not support deleting RDS databases
C. The user must be in the root account to delete any RDS database
D. RDS databases cannot be deleted once created

Correct Answer:
A

Explanation:
IAM permissions are action-specific. A policy can allow describe and reboot actions without allowing delete actions.

Question 4:
A large organization wants to reduce the number of IAM policies required for project-based access. Users should manage only resources tagged with their project name. Which access control model is most appropriate?

A. RBAC only, with one IAM group per user
B. ABAC using principal and resource tags
C. Root account access with manual approval
D. One AWS account for each IAM user

Correct Answer:
B

Explanation:
ABAC is designed for scalable access control based on attributes such as project, department, application, or environment tags.

Question 5:
Which practice is most important when using tags for authorization in AWS?

A. Allow all developers to modify all resource tags
B. Use tags only for billing and never for security
C. Enforce consistent tag keys and values and restrict who can modify authorization-related tags
D. Avoid using IAM policy conditions

Correct Answer:
C

Explanation:
ABAC depends on reliable tags. If users can freely change security-sensitive tags, they may accidentally or intentionally gain unauthorized access.