Study guide
Technical reference and lesson notes
Purpose of This Lesson
This lesson explains two important access control models in AWS Identity and Access Management: Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC).
For the AWS Certified Solutions Architect – Professional SAP-C02 exam, this matters because many scenario questions involve designing secure, scalable, and manageable permission models across teams, accounts, workloads, and environments. You need to understand when to assign permissions based on job function and when to use tags and policy conditions for more dynamic access control.
Key Concepts
Role-Based Access Control in AWS
Role-Based Access Control, or RBAC, grants permissions based on a user’s role or job function.
In AWS, RBAC is commonly implemented by creating IAM groups, IAM roles, or identity provider groups that represent business functions such as:
- Administrators
- Developers
- Operations engineers
- Billing administrators
- Security auditors
- Database administrators
Users are placed into the group that matches their job responsibility. Permissions policies are then attached to the group or role. The user receives permissions because they are a member of that role-based container.
For example:
| User | Group | Permission Scope |
|---|---|---|
| Andrea | Operations | Operational access needed to manage workloads |
| Lee | Development | Developer-level permissions for application resources |
| Joanne | Billing Admins | Billing and cost management permissions |
The goal is to avoid assigning permissions directly to every user. Instead, permissions are managed centrally through groups or roles.
RBAC and the Principle of Least Privilege
RBAC supports the principle of least privilege, which means users should receive only the permissions required to perform their job.
For example, a developer should not automatically receive billing permissions. A billing administrator should not automatically receive access to modify production databases. An operations engineer should not automatically receive broad administrator access unless the role requires it.
This is important for the SAP-C02 exam because AWS often expects secure designs that reduce excessive permissions and centralize identity governance.
AWS Managed Job Function Policies
AWS provides several AWS managed policies that are designed around common job functions. These are known as job function policies.
Examples include policies for roles such as:
- Administrator
- Billing
- Data Scientist
- Security Auditor
- System Administrator
These policies can be useful when you need a quick starting point for common job roles. They are managed by AWS and contain predefined permissions aligned to typical responsibilities.
However, for production environments, AWS managed policies should usually be reviewed carefully. They may grant more permissions than your organization actually needs.
When RBAC Works Well
RBAC works best when access requirements are relatively stable and align clearly with job roles.
Common use cases include:
| Scenario | Why RBAC Works |
|---|---|
| A billing team needs billing console access | Permissions map cleanly to a business function |
| A security audit team needs read-only security visibility | The team has a predictable access pattern |
| Developers need access to development resources | Role-based grouping keeps access simple |
| Operations needs access to manage infrastructure | Permissions can be attached to an operations role |
RBAC is simple to understand, simple to audit, and widely used in enterprise environments.
Limitations of RBAC
RBAC can become difficult to manage at scale when permissions vary by project, application, department, environment, account, or resource ownership.
For example, imagine a large company with:
- Multiple departments
- Multiple AWS accounts
- Development, test, staging, and production environments
- Many applications
- Many database teams
- Different access rules for different resources
If every access combination requires a separate group or role, RBAC can lead to role sprawl.
You may end up with groups like:
- DevTeamApp1ProdReadOnly
- DevTeamApp1DevAdmin
- DBAdminsProdStartStop
- DBAdminsDevFullAccess
- SecurityAuditProdOnly
This becomes harder to manage, audit, and scale.
Attribute-Based Access Control in AWS
Attribute-Based Access Control, or ABAC, grants permissions based on attributes.
In AWS, those attributes are commonly implemented using tags.
Tags are key-value pairs that can be attached to AWS identities and AWS resources.
Example principal tag on an IAM user or role:
| Key | Value |
|---|---|
| department | DBAdmins |
Example resource tag on an Amazon RDS database:
| Key | Value |
|---|---|
| environment | production |
With ABAC, an IAM policy can allow or deny access based on whether the principal’s tags and the resource’s tags match specific conditions.
ABAC with IAM Policy Conditions
ABAC relies heavily on IAM policy condition keys.
Important condition key examples include:
| Condition Key | Meaning |
|---|---|
aws:PrincipalTag | Evaluates a tag attached to the IAM principal |
aws:ResourceTag | Evaluates a tag attached to the AWS resource |
StringEquals | Requires the compared values to match exactly |
A policy could allow a database administrator to perform specific actions only when:
- The user or role has a principal tag of
department = DBAdmins - The target RDS database has a resource tag of
environment = production
This allows permissions to be controlled dynamically based on metadata rather than hardcoding every resource ARN into every policy.
Example ABAC Scenario
Assume an IAM user named Dave belongs to a DBAdmins group.
Dave has this principal tag:
| Key | Value |
|---|---|
| department | DBAdmins |
There are two Amazon RDS databases:
| Database | Environment Tag |
|---|---|
| RDS Database 1 | production |
| RDS Database 2 | development |
The IAM permissions policy allows the following RDS actions:
rds:RebootDBInstancerds:StartDBInstancerds:StopDBInstance
However, the policy only allows those actions when the resource tag equals environment = production.
Result:
| Action | Result | Reason |
|---|---|---|
| Dave reboots production RDS database | Allowed | Principal tag and resource tag meet the policy condition |
| Dave stops development RDS database | Denied | Resource tag does not match environment = production |
This is the core value of ABAC: access can change based on tags instead of constantly rewriting IAM policies.
RBAC vs ABAC
RBAC and ABAC are not mutually exclusive. In many real AWS environments, they are used together.
| Access Model | Based On | Best For |
|---|---|---|
| RBAC | Job role, group, or function | Stable job-based permissions |
| ABAC | Tags and attributes | Dynamic, scalable, resource-specific permissions |
RBAC answers the question:
“Which job function does this person have?”
ABAC answers the question:
“Do this principal’s attributes match the attributes required to access this resource?”
Security Considerations for ABAC
ABAC is powerful, but it depends on accurate and controlled tagging.
If users can freely modify tags on themselves or resources, they may be able to escalate privileges.
For example, if a user can tag themselves as department = DBAdmins, they might gain access to database administration actions.
Because of this, ABAC designs must control:
- Who can assign principal tags
- Who can tag AWS resources
- Which tag keys are allowed
- Which tag values are permitted
- Whether tags are enforced during resource creation
- Whether Service Control Policies should restrict tag manipulation
For SAP-C02, remember that ABAC is scalable, but only when paired with strong governance around tagging.
Operational Considerations
ABAC works best when an organization has a mature tagging strategy.
Important operational requirements include:
- Standardized tag names
- Standardized tag values
- Tag enforcement through automation or policy
- Monitoring for untagged or incorrectly tagged resources
- Clear ownership of tag governance
- Integration with IAM Identity Center or an external identity provider where appropriate
Poor tagging can break access or unintentionally grant access.
Exam-Relevant Takeaways
For SAP-C02, remember these points:
RBAC assigns permissions based on job roles, groups, or functions. It is simple, common, and effective for predictable access patterns.
ABAC assigns permissions based on attributes, usually tags. It is more scalable for complex environments where access depends on department, project, application, cost center, environment, or ownership.
IAM policy conditions are central to ABAC. Tags on principals and resources can be evaluated using condition keys such as aws:PrincipalTag and aws:ResourceTag.
RBAC is easier to understand and audit, but it can lead to role sprawl in large environments.
ABAC reduces the need to create large numbers of separate roles or policies, but it requires strong tag governance.
AWS managed job function policies can be useful starting points, but they should be reviewed before being used in production.
The principle of least privilege applies to both RBAC and ABAC.
Architecture Decision Guide
| Scenario | Best AWS Choice | Why |
|---|---|---|
| Small team with clearly defined job functions | RBAC | Simple to implement using IAM groups, roles, and job-based policies |
| Billing users need billing-only access | RBAC with AWS managed job function policy as a starting point | Billing access aligns well to a predefined job function |
| Large organization with many projects and environments | ABAC | Tags allow permissions to scale without creating excessive roles |
| Access should depend on whether a resource is tagged as production | ABAC | IAM conditions can evaluate resource tags |
| Developers should only access resources for their own project | ABAC | Project tags can be used to match identities to resources |
| Security auditors need broad read-only access | RBAC | Audit permissions usually map well to a stable job function |
| Database admins can start, stop, or reboot only production databases | ABAC | Resource tags can restrict actions to production-tagged RDS instances |
| Organization wants to reduce role sprawl | ABAC | Attribute-driven permissions reduce the number of unique roles and policies |
Common Exam Traps
Trap 1: Thinking RBAC and ABAC Are Mutually Exclusive
They can be combined. A user may assume a role based on RBAC, and then that role may use ABAC conditions to limit access to tagged resources.
Trap 2: Assuming Tags Automatically Control Access
Tags do nothing by themselves. They only affect access when IAM policies use tag-based condition keys.
Trap 3: Forgetting Tag Governance
ABAC is only secure if tag assignment is controlled. If users can change tags freely, they may be able to grant themselves unauthorized access.
Trap 4: Using AWS Managed Policies Without Review
AWS managed job function policies are convenient, but they may not perfectly match an organization’s least-privilege requirements.
Trap 5: Creating Too Many Roles Instead of Using Tags
In large environments, creating a new role for every department, application, environment, and permission combination can become unmanageable. ABAC may be the better design.
Trap 6: Confusing IAM Groups and IAM Roles
IAM groups are collections of IAM users. IAM roles are assumable identities that can be used by users, services, applications, or federated identities. Both can participate in role-based designs, but they are not the same thing.
Real-World Engineer Notes
In a real AWS environment, RBAC is often the starting point because it is familiar to infrastructure and security teams. It maps well to enterprise concepts like Active Directory groups, Entra ID groups, job titles, and operational responsibilities.
ABAC becomes more attractive as the environment grows. Once teams manage many AWS accounts, workloads, and environments, tag-based access can reduce administrative overhead.
For example, instead of creating separate IAM roles for every application team, you can tag identities and resources with values such as:
departmentprojectapplicationenvironmentcost-centerdata-classification
Then IAM policies can allow access only when the required tags match.
The biggest real-world challenge is governance. If tagging is inconsistent, ABAC becomes unreliable. You need a clear tagging standard and controls to prevent unauthorized tag changes.
In production, ABAC should usually be supported by:
- AWS Organizations
- Service Control Policies
- IAM permission boundaries
- Tag policies
- CloudTrail monitoring
- AWS Config rules
- Resource creation guardrails
- Identity provider attribute mapping
For troubleshooting, always check both sides of the access decision:
- Does the principal have the correct tag?
- Does the resource have the correct tag?
- Does the IAM policy reference the correct tag keys and values?
- Is there an explicit deny from another policy type?
- Is the action supported with the condition key being used?
ABAC is flexible, but a missing or misspelled tag can cause access denied errors that are not obvious at first glance.
Quick Reference Summary
RBAC grants access based on role or job function.
ABAC grants access based on attributes, usually tags.
RBAC is easier to implement and audit for stable job roles.
ABAC scales better across large environments with many projects, resources, and environments.
AWS managed job function policies can help with RBAC but should be reviewed before production use.
ABAC uses IAM policy conditions such as aws:PrincipalTag and aws:ResourceTag.
Tags must be governed carefully because incorrect or unauthorized tags can affect access.
Least privilege is the goal for both RBAC and ABAC.
Flashcards
Q: What does RBAC stand for?
A: Role-Based Access Control.
Q: What does ABAC stand for?
A: Attribute-Based Access Control.
Q: What is the main idea behind RBAC?
A: Permissions are assigned based on a user’s job role or function.
Q: What is the main idea behind ABAC in AWS?
A: Permissions are controlled using attributes, commonly tags, attached to principals and resources.
Q: What AWS feature is commonly used to implement ABAC?
A: Tags combined with IAM policy conditions.
Q: What does aws:PrincipalTag evaluate?
A: A tag attached to the IAM principal, such as a user or role.
Q: What does aws:ResourceTag evaluate?
A: A tag attached to the AWS resource being accessed.
Q: Why can RBAC become difficult to manage at scale?
A: It can lead to role sprawl when many combinations of departments, projects, environments, and permissions are needed.
Q: Why is ABAC useful in large AWS environments?
A: It allows access decisions to be made dynamically based on tags, reducing the need for many separate roles and policies.
Q: What is the principle of least privilege?
A: Granting only the permissions required to perform a specific job or task.
Q: Are AWS managed job function policies always least privilege for your environment?
A: No. They are useful starting points but should be reviewed and customized as needed.
Q: What is a major security risk with ABAC?
A: If users can modify tags improperly, they may be able to gain unauthorized access.
Q: In ABAC, what happens if the required resource tag does not match the policy condition?
A: Access is denied unless another applicable policy allows it without that condition and no explicit deny exists.
Q: Can RBAC and ABAC be used together?
A: Yes. Many AWS environments use role-based assignments with tag-based conditions.
Practice Questions
Question 1:
A company wants to give its billing team access to AWS billing features. The team’s responsibilities are stable and clearly defined. The company wants the simplest access model to start with. Which approach is most appropriate?
A. Create a unique IAM policy for every individual billing user
B. Use RBAC by placing billing users into a billing-focused group or role and attaching appropriate billing permissions
C. Use ABAC with randomly assigned tags on billing resources
D. Give all billing users AdministratorAccess
Correct Answer:
B
Explanation:
Billing access maps well to a job function, making RBAC a good fit. AWS managed job function policies may be useful as a starting point, but permissions should still be reviewed.
Question 2:
A company has many application teams and wants developers to access only resources tagged with their assigned project name. The company wants to avoid creating separate IAM roles for every project and environment combination. Which model is best suited for this requirement?
A. RBAC only
B. ABAC using principal tags and resource tags
C. Root account access with MFA
D. One shared IAM user for each application team
Correct Answer:
B
Explanation:
ABAC is designed for dynamic access control based on attributes. Matching principal tags to resource tags can reduce role sprawl in large environments.
Question 3:
An IAM user has a principal tag of department = DBAdmins. An IAM policy allows rds:StartDBInstance only when the target RDS database has the tag environment = production. The user attempts to start an RDS database tagged environment = development. What happens?
A. The action is allowed because the user is in the DBAdmins department
B. The action is denied because the resource tag does not match the policy condition
C. The action is allowed because RDS ignores tags for access control
D. The action is allowed if the user is using the AWS Management Console
Correct Answer:
B
Explanation:
The policy condition requires the RDS database to have the matching resource tag. Since the database is tagged as development instead of production, the condition is not satisfied.
Question 4:
A solutions architect is designing an ABAC model for a large AWS environment. Which control is most important to prevent privilege escalation?
A. Allow all users to update their own IAM principal tags
B. Allow developers to change resource tags on production systems
C. Restrict who can create, modify, or delete access-related tags
D. Store all IAM policies in Amazon S3
Correct Answer:
C
Explanation:
ABAC depends on trusted attributes. If users can change tags that control access, they may be able to escalate privileges.
Question 5:
Which statement best describes the relationship between RBAC and least privilege?
A. RBAC automatically guarantees least privilege
B. RBAC can support least privilege when roles are carefully designed with only the permissions needed for each job function
C. RBAC requires all users to have administrator access
D. RBAC is only used for AWS root users
Correct Answer:
B
Explanation:
RBAC supports least privilege by assigning permissions based on job responsibilities, but the policies must still be designed carefully.