AWS IAM Advanced Access Control: RBAC, ABAC, and Policy Evaluation

Purpose of This Lesson

This lesson explains how AWS Identity and Access Management (IAM) uses role-based access control (RBAC) and attribute-based access control (ABAC). It also develops the policy-reading skills needed to determine which actions are allowed, which resources are affected, and how conditions or explicit denies restrict access.

The focus is especially relevant to AWS Certified CloudOps Engineer Associate (SOA-C03) scenarios involving least privilege, IAM policy interpretation, tags, resource policies, and conditional access.

Key Concepts

Role-Based Access Control (RBAC)

RBAC assigns permissions according to a user’s job role. Users are placed into groups such as administrators, developers, operations staff, or billing administrators, and policies are attached to those groups.

A user inherits the permissions associated with the groups to which they belong. The policies may be AWS managed policies or customer-managed policies created for the organization’s requirements.

RBAC supports least privilege by giving each job function only the permissions needed to perform its work.

Attribute-Based Access Control (ABAC)

ABAC makes authorization decisions using attributes, commonly tags. In AWS, tags can be attached to IAM identities and AWS resources, and policy conditions can require those tag values to match.

For example:

• An IAM user can have the tag department=DBAdmins.
• An RDS database can have the tag environment=production.
• A policy can allow selected RDS actions only when both required attributes match.

ABAC is useful when access should follow resource or identity characteristics rather than a fixed list of users or groups.

Identity-Based and Resource-Based Policies

Identity-based policies are attached to IAM users, groups, or roles. They define what actions the identity may perform on specified resources.

Resource-based policies are attached directly to resources. An Amazon S3 bucket policy is a common example. Resource policies include a Principal element that identifies the user, role, or account receiving access.

A policy directly attached to an identity does not need to specify that identity as a principal. The presence of a Principal element is therefore an important clue that the statement is resource-based.

IAM Policy Reading and Conditional Access

An IAM policy statement should be read by identifying its main elements:

• Effect: Either Allow or Deny.
• Action: The API operations affected, such as s3:*, ec2:TerminateInstances, or selected DynamoDB actions.
• Resource: The ARN or ARNs to which the statement applies. A wildcard can represent all matching resources, while an S3 bucket ARN and an object ARN such as bucket-name/* refer to different resource scopes.
• Principal: The identity receiving access in a resource-based policy.
• Condition: Additional requirements that must be satisfied for the statement to apply.

A wildcard in an action can match multiple API operations. For example, Describe* matches actions beginning with Describe, while List* matches actions beginning with List. The exact resource and service requirements still matter; an action wildcard does not automatically make every operation valid.

Conditions Based on Region

A policy can allow EC2 actions only when a request meets a regional condition, such as a condition requiring the request region to be us-east-2. An otherwise permitted EC2 request in another region does not satisfy that condition.

The decisive point is that an Allow statement with a condition applies only when the condition evaluates to true.

Conditions Based on Source IP Address

A common restriction pattern is:

1. Allow an action, such as terminating EC2 instances.
2. Add a Deny for the same action when the request does not originate from one of the approved IP ranges.

The negative condition is important. The deny applies when the source IP is not in an approved range. Because an explicit deny overrides an allow, the action is blocked outside those ranges even if another policy grants the permission.

ABAC Example: RDS Access by Tags

Assume the following attributes:

• IAM user Dave has department=DBAdmins.
• An RDS instance has environment=production.
• Another RDS instance has environment=development.

A policy can allow actions such as rebooting, starting, and stopping RDS instances when the identity’s department tag matches DBAdmins and the target RDS resource’s environment tag is production.

Under those conditions:

• Dave can perform the permitted action on the production database because both identity and resource attributes match.
• Dave cannot perform the action on the development database because the resource tag does not satisfy the production requirement.

The action list and the condition must both be checked. A resource being in scope through a wildcard does not mean every tagged resource is authorized.

Exam- or Assessment-Relevant Takeaways

• RBAC groups users by job function and attaches permissions to those groups.
• ABAC uses attributes, commonly IAM and AWS resource tags, in policy conditions.
• RBAC and ABAC can be used together.
• Identity-based policies attach to users, groups, and roles.
• Resource-based policies attach to resources such as S3 buckets and include a Principal.
• An Allow applies only when its action, resource, and conditions match the request.
• A wildcard can broaden actions or resources, but conditions may still restrict access.
• An explicit Deny overrides an applicable Allow.
• When analyzing a policy, check the effect, action, resource, principal, and conditions rather than relying on the policy name.
• For a deny using a negative condition, verify precisely when the condition becomes true. In the IP-range example, the deny takes effect when the requester is outside the approved ranges.

Tool / Feature Decision Guide

Requirement	Prefer	Reason
Permissions should follow a stable job function	RBAC with IAM groups	Policies can be assigned to groups such as development or operations and inherited by members.
Access should depend on identity and resource characteristics	ABAC with tags and conditions	Authorization can follow attributes such as department or environment.
A policy should be attached to a user, group, or role	Identity-based policy	The identity is the policy attachment point.
A resource should grant access to a specified principal	Resource-based policy	The policy is attached to the resource and uses Principal.
A high-risk action must be limited to approved network locations	Allow plus an explicit conditional Deny	The deny blocks requests outside the approved IP ranges, even when an allow exists.
Different teams need different permissions	RBAC, potentially supplemented by ABAC	Groups provide the job-role baseline; attributes can add contextual restrictions.

Common Traps / Misconceptions

• Confusing a group with an attribute: A group-based permission assignment is RBAC. A tag-based condition is ABAC.
• Assuming a wildcard means unrestricted access: * may broaden actions or resources, but conditions and explicit denies still apply.
• Ignoring the resource ARN format: An S3 bucket ARN and the ARN for objects inside that bucket represent different scopes.
• Forgetting the Principal clue: A Principal is expected in a resource-based policy; identity-based policies are already attached to the identity.
• Treating an allow as unconditional: An allow with a region, tag, or other condition works only when that condition matches.
• Missing the effect of an explicit deny: An explicit deny wins over an allow.
• Misreading a negative condition: A deny based on “not in these IP ranges” blocks requests outside the listed ranges, not inside them.
• Assuming ABAC replaces RBAC: The two techniques can be combined. RBAC can establish broad job-role permissions while ABAC adds tag-based restrictions.

Real-World Engineer / Analyst Notes

• Start policy analysis with the requested API action and target resource. Then evaluate the conditions and applicable identity- and resource-based statements.
• Use least privilege as the design baseline: grant only the actions and resources required for the job.
• Tag naming and values must be consistent for ABAC to work predictably. A mismatched department or environment value prevents a condition-dependent allow from applying.
• Be especially careful with destructive actions such as ec2:TerminateInstances. Conditional denies can provide a safety boundary, but the condition logic must be verified carefully.
• When troubleshooting an access decision, distinguish “no applicable allow” from “an explicit deny.” The latter remains decisive even when another policy grants the action.
• For exam scenarios, translate policy syntax into a plain-language statement: who can perform which API action, against which resource, under which conditions?

Quick Reference Summary

• RBAC: Permissions are assigned through groups based on job role.
• ABAC: Permissions depend on attributes such as IAM and resource tags.
• Identity-based policy: Attached to a user, group, or role.
• Resource-based policy: Attached to a resource and includes a Principal.
• Effect: Allow grants access when all requirements match; Deny blocks access.
• Action: Identifies permitted or denied API operations.
• Resource: Identifies the affected ARN or resource scope.
• Condition: Adds requirements such as region, tag, or source IP.
• Explicit deny: Overrides an allow.
• Policy-analysis method: Identify the principal, action, resource, conditions, and effect, then determine whether the request satisfies every requirement.

Flashcards

Q: A company wants permissions to follow job functions such as development, operations, and billing administration. Which access-control approach is the natural starting point?
A: Use RBAC by placing users in job-based IAM groups and attaching the appropriate policies to those groups. Apply least privilege within each job function.

Q: When would ABAC be preferable to relying only on fixed IAM groups?
A: Use ABAC when access should depend on identity or resource attributes, such as a user’s department tag and a resource’s environment tag.

Q: Dave has department=DBAdmins, and an RDS instance has environment=production. A policy requires both values and allows rebooting. Can Dave reboot that instance?
A: Yes, assuming the action and resource otherwise match the statement, because both required tag conditions are satisfied.

Q: Dave meets the identity tag condition, but the RDS instance is tagged environment=development while the policy requires production. What is the result?
A: The conditional allow does not apply, so the action is not authorized by that statement.

Q: What is the key difference between an identity-based policy and a resource-based policy?
A: An identity-based policy is attached to a user, group, or role. A resource-based policy is attached to a resource and specifies the receiving identity with Principal.

Q: Why is an S3 bucket policy a resource-based policy?
A: It is attached to the S3 bucket and grants access to a specified principal, such as a user, through its Principal element.

Q: A policy contains Describe* in the action field. What does that indicate?
A: It matches API actions whose names begin with Describe, subject to the policy’s service, resource, and condition requirements.

Q: What should you infer when an EC2 allow requires the request region to be us-east-2?
A: The allow applies only to requests satisfying that regional condition; an otherwise similar request in another region does not qualify under that statement.

Q: Why might a policy both allow and deny ec2:TerminateInstances?
A: The allow establishes the baseline permission, while the explicit conditional deny restricts that permission, such as blocking requests outside approved IP ranges.

Q: A deny applies when the requester IP is not within two approved ranges. Which requests are blocked?
A: Requests originating outside both approved ranges are blocked. The explicit deny overrides an allow for those requests.

Q: What does a wildcard in a resource or action field mean, and what does it not mean?
A: It represents a broad matching scope, such as multiple actions or resources. It does not bypass conditions or explicit denies.

Q: What is the main least-privilege principle relevant to both RBAC and ABAC?
A: Grant only the permissions needed for the user’s job and the permitted context. Group membership or matching tags should not be treated as a reason to grant unnecessary actions.

Practice Questions

Question 1

An operations team should be able to manage resources required by its job, while developers should receive a different permission set. The permissions are not expected to vary based on resource tags. Which design best matches the requirement?

A. Put all users in one group and use a wildcard allow
B. Create job-based IAM groups with least-privilege policies
C. Use only resource-based policies with no principal restrictions
D. Require every request to originate from one IP address

Correct answer: B

Explanation: The requirement is organized around stable job functions, which is the RBAC model. Groups and role-specific policies provide separate permission sets.

Question 2

Dave has an IAM tag department=DBAdmins. An RDS policy allows StartDBInstance when the principal department tag equals DBAdmins and the target resource tag environment equals production. Dave attempts to start an RDS instance tagged environment=development. What happens under this statement?

A. The action is allowed because Dave’s tag matches
B. The action is allowed because the resource is an RDS instance
C. The action is not allowed by this statement because the resource tag does not match
D. The action is allowed only if Dave belongs to an operations group

Correct answer: C

Explanation: ABAC evaluates both required attributes. The identity tag matches, but the resource’s environment tag fails the production condition.

Question 3

An S3 policy is attached to a bucket and contains Principal set to a particular user along with an allow for putting objects. What type of policy is this?

A. Identity-based policy
B. Resource-based policy
C. Session policy only
D. Group membership policy

Correct answer: B

Explanation: The policy is attached to the S3 resource and identifies the permitted identity with Principal, which characterizes a resource-based policy.

Question 4

An IAM policy allows EC2 termination but explicitly denies the same action when the source IP is not in either of two approved ranges. A user with the allow permission sends the request from an unapproved address. What is the result?

A. The action succeeds because allow statements are evaluated first
B. The action succeeds because the user has the required IAM group
C. The action is denied because the explicit deny applies
D. The action is denied only if the resource is in another region

Correct answer: C

Explanation: The request satisfies the negative IP condition, so the explicit deny applies. An explicit deny overrides an allow.

WordPress Metadata

Suggested Slug:
aws-iam-rbac-abac-policy-evaluation

Meta Description:
Study AWS IAM role-based and attribute-based access control, identity and resource policies, policy elements, conditions, and deny-based restrictions for the SOA-C03 exam.

Tags:
AWS IAM, RBAC, ABAC, IAM policies, identity-based policies, resource-based policies, least privilege, AWS security, IAM conditions, SOA-C03