AWS IAM Role-Based Access Control Using Groups

Purpose of This Lesson

This lesson explains how Role-Based Access Control, or RBAC, can be implemented in AWS using IAM groups and managed policies.

For the SAP-C02 exam, this matters because AWS frequently tests identity design, least privilege, access delegation, and permission troubleshooting. You need to understand how users receive permissions through groups, how AWS managed policies can be attached to those groups, and why permissions granted for one job function do not automatically grant access to unrelated AWS services.

In this example, a Billing Admins group is created, an AWS managed billing policy is attached, and a user named Joann is added to that group. Joann can access billing-related information but cannot access unrelated services like IAM or EC2.

Key Concepts

Role-Based Access Control in AWS

Role-Based Access Control is an access control model where permissions are assigned based on a user’s job function.

Instead of assigning permissions directly to each individual user, you create a group that represents a job role, attach permissions to that group, and then place users into the group.

Example job-function groups could include:

• Billing Admins
• Developers
• Database Admins
• Security Auditors
• Network Administrators
• Read-Only Users
• Operations Engineers

In this lesson, the job function is billing administration.

The design pattern is:

1. Create an IAM group called Billing Admins.
2. Attach a billing-related AWS managed policy to the group.
3. Add users who need billing access to the group.
4. Those users inherit the permissions from the group.

This is a cleaner and more scalable approach than assigning policies directly to every user.

IAM Groups

An IAM group is a container for IAM users.

Groups are useful when multiple users need the same set of permissions. Instead of managing each user individually, you manage the group membership.

For example:

IAM Group	Attached Policy	Users
Billing Admins	AWS managed billing policy	Joann, FinanceUser1, FinanceUser2
Developers	Custom developer policy	DevUser1, DevUser2
ReadOnly	Read-only policy	Auditors, Helpdesk

When a user is added to a group, the user receives the permissions attached to that group.

Important IAM group points:

• IAM groups can contain IAM users.
• IAM groups cannot contain IAM roles.
• IAM groups cannot contain other groups.
• IAM groups are not principals in resource-based policies.
• IAM groups are used to simplify permission assignment.

AWS Managed Policies

AWS managed policies are policies created and maintained by AWS.

In the lesson, the group is assigned an AWS managed policy related to billing. AWS provides several managed policies for common job functions, such as billing, read-only access, administrator access, and support-related access.

AWS managed policies are convenient because they are prebuilt and maintained by AWS, but they may be broader than what you would create yourself.

For production environments, a common approach is:

• Use AWS managed policies for quick testing, labs, and baseline access.
• Use customer-managed policies when you need tighter control.
• Use least privilege when designing access for real workloads.
• Review managed policies before assigning them broadly.

How Permissions Are Applied Through Groups

In the example, Joann is added to the Billing Admins group.

The permissions flow looks like this:

IAM User: Joann
        ↓
IAM Group: Billing Admins
        ↓
Attached Policy: Billing permissions
        ↓
Effective Access: Billing-related AWS console/API permissions

Joann does not receive IAM or EC2 permissions unless another policy grants those permissions.

This demonstrates an important IAM principle:

A user only receives permissions that are explicitly allowed by an applicable identity-based policy, unless another policy type restricts or denies access.

By default, AWS starts with an implicit deny. Access must be explicitly allowed.

Least Privilege

This lesson is a practical example of least privilege.

Joann needs access to billing information, so she is placed into a group that grants billing permissions. She is not given access to IAM, EC2, S3, RDS, or other services because those are not required for her job function.

For the SAP-C02 exam, always look for answers that grant only the permissions needed for the task.

A billing user should not need:

• Full administrator access
• IAM administrator access
• EC2 administrator access
• Broad read/write access to unrelated services
• Root account access

The better answer is usually to create or use a group, role, or permission set aligned to the job function.

IAM Users Versus IAM Identity Center

The lesson demonstrates IAM users and IAM groups directly in IAM. This is useful for learning the concept, but in modern AWS environments, AWS generally recommends using AWS IAM Identity Center for workforce access.

IAM users are still important to understand for the exam and for legacy environments, but for enterprise identity design, IAM Identity Center is usually preferred.

Comparison:

Access Model	Typical Use
IAM Users and Groups	Legacy users, small environments, labs, service-specific scenarios
IAM Identity Center	Centralized workforce access, federation, multi-account access
IAM Roles	Temporary access, service-to-service access, cross-account access
Service Roles	AWS services accessing other AWS resources on your behalf

For SAP-C02, understand both models.

IAM groups are a classic RBAC mechanism inside one AWS account. IAM Identity Center extends this idea across AWS Organizations and multiple accounts using users, groups, and permission sets.

Billing Access Is Separate From Other AWS Services

After Joann logs in, she can access billing information but cannot access IAM or EC2.

This is expected.

Billing permissions do not include general account administration permissions.

For example:

Service Area	Joann’s Access
Billing Dashboard	Allowed
Bills / Cost Details	Allowed, depending on policy
IAM Users / Groups / Roles	Denied
EC2 Instances	Denied
Account-wide admin actions	Denied

This is a key exam concept: permissions are scoped to specific AWS API actions and services.

Granting access to one job function does not imply access to everything else.

Permission Troubleshooting

When Joann tries to access IAM or EC2, she receives authorization errors.

That is not a configuration failure. It means IAM is working as designed.

If a user cannot access a service, check:

1. Is there an identity-based policy allowing the action?
2. Is the user in the expected group?
3. Is the correct policy attached to the group?
4. Is there an explicit deny?
5. Is there a permissions boundary limiting the user?
6. Is there an SCP in AWS Organizations restricting access?
7. Is the resource policy allowing or denying access?
8. Does billing access require account-level billing access settings to be enabled?

For billing access specifically, AWS accounts may require IAM access to billing to be activated before IAM users can access billing information.

RBAC Versus ABAC

This lesson focuses on RBAC.

RBAC assigns permissions based on job roles.

ABAC, or Attribute-Based Access Control, assigns permissions based on attributes, usually tags.

Model	How Access Is Granted	Example
RBAC	Based on role or group membership	Billing users go into Billing Admins group
ABAC	Based on attributes/tags	Users with Department=Finance can access resources tagged Department=Finance

RBAC is usually simpler to understand and easier to start with.

ABAC can scale better in large environments where permissions need to follow resource tags, departments, projects, or environments.

Exam-Relevant Takeaways

For the SAP-C02 exam, remember these points:

• IAM groups are used to assign permissions to multiple IAM users.
• Users inherit permissions from the groups they belong to.
• AWS managed policies are created and maintained by AWS.
• Job-function policies can be useful, but may be broader than a custom least-privilege policy.
• Adding a user to a billing group does not grant access to IAM, EC2, or unrelated services.
• AWS permissions are based on API actions.
• Access is denied by default unless explicitly allowed.
• Explicit deny always overrides allow.
• IAM groups cannot contain IAM roles or other groups.
• IAM groups are not used as principals in resource-based policies.
• For enterprise workforce access, IAM Identity Center is usually preferred over long-lived IAM users.
• For multi-account access, use AWS Organizations with IAM Identity Center and permission sets rather than manually creating IAM users in each account.
• Billing access may require both IAM permissions and account-level billing access configuration.

Architecture Decision Guide

Scenario	Best AWS Choice	Why
A small team needs billing console access in one AWS account	IAM group with billing policy	Simple RBAC model for one account
A finance department needs billing access across many AWS accounts	IAM Identity Center permission set assigned to a finance group	Scales better across AWS Organizations
A user needs temporary access to perform administrative work	IAM role	Roles use temporary credentials and are better than long-lived user credentials
An EC2 application needs to access S3	IAM role attached through an instance profile	Avoids storing access keys on the instance
Multiple users need the same permissions	IAM group or IAM Identity Center group	Centralized permission assignment
Permissions need to vary based on project, department, or environment tags	ABAC using tags	More scalable for dynamic access control
A user only needs to view billing data	Billing-focused policy	Follows least privilege
A user needs full account administration	Administrator policy or administrative permission set	Only appropriate for trusted administrators
A company wants centralized workforce identity with SSO	IAM Identity Center	Better for enterprise access management
A user cannot access EC2 after being placed in a billing group	Add an EC2-specific policy only if needed	Billing permissions do not include EC2 permissions

Common Exam Traps

Trap 1: Assuming Group Membership Grants Broad Account Access

A user added to a Billing Admins group only receives the permissions attached to that group.

They do not automatically receive access to IAM, EC2, S3, RDS, or other AWS services.

Trap 2: Choosing AdministratorAccess When Billing Access Is Enough

If the scenario says a finance user needs to view or manage billing information, do not choose full administrator access unless the question explicitly requires full administrative control.

The better answer is usually a billing-specific policy or permission set.

Trap 3: Confusing IAM Groups With IAM Roles

IAM groups and IAM roles are not the same.

IAM groups are used to organize IAM users.

IAM roles are assumed by trusted principals and provide temporary credentials.

Use groups for organizing user permissions. Use roles for temporary access, service access, and cross-account access.

Trap 4: Using IAM Users for Enterprise Multi-Account Access

In a multi-account AWS Organizations environment, do not manually create IAM users in every AWS account.

Use IAM Identity Center with permission sets assigned to users and groups.

Trap 5: Forgetting the Default Deny Model

AWS does not allow access just because a user exists.

By default, access is denied. A policy must explicitly allow the requested action.

Trap 6: Ignoring Explicit Deny

Even if a user has an allow through a group policy, an explicit deny from another applicable policy wins.

This could come from:

• Identity-based policy
• Permissions boundary
• Service control policy
• Resource-based policy
• Session policy

Trap 7: Assuming Billing Permissions Work Without Account-Level Billing Access

Billing access can require more than just an IAM policy. In some cases, the account must allow IAM users and roles to access billing information.

For exam purposes, understand that billing access can involve both IAM permissions and account billing settings.

Real-World Engineer Notes

In a real AWS environment, RBAC should map to business functions, not individual people.

For example, instead of creating a custom policy for every finance user, create a finance-related group or IAM Identity Center group and assign permissions there. When users join or leave the finance team, you update group membership rather than rewriting policies.

For small environments or labs, IAM groups are easy and effective. For enterprise environments, especially with multiple AWS accounts, IAM Identity Center is usually the better design because it centralizes identity, supports federation, and reduces the need for long-lived IAM users.

From an operations perspective, you should document:

• Which groups exist
• What each group is allowed to do
• Which policies are attached
• Who owns approval for group membership
• Whether policies are AWS managed or customer managed
• Whether permissions are reviewed regularly

For security, avoid giving users full administrator access when they only need billing, reporting, or read-only visibility. Billing data may still be sensitive, so finance-related access should be reviewed and logged like any other privileged access.

CloudTrail can help audit API activity. For billing and cost-management work, also consider using AWS Budgets, Cost Explorer, Cost and Usage Reports, and account-level governance controls.

In a mature environment, you would likely combine:

• IAM Identity Center for workforce access
• AWS Organizations for account structure
• SCPs for guardrails
• IAM roles for workload and cross-account access
• Customer-managed policies for least privilege
• CloudTrail and Access Analyzer for monitoring and review

Quick Reference Summary

RBAC in AWS assigns permissions based on job function.

In IAM, this can be implemented by creating a group, attaching a policy to the group, and adding users to the group.

A Billing Admins group with a billing policy gives users billing-related access, but not access to IAM, EC2, or unrelated services.

Access in AWS is denied by default. Users only receive permissions through applicable policies, and explicit deny always overrides allow.

IAM groups are useful for organizing IAM users in a single account. For modern enterprise and multi-account access, IAM Identity Center with permission sets is usually the preferred design.

Flashcards

Q: What is Role-Based Access Control in AWS?
A: RBAC is an access control model where permissions are assigned based on job function, often by placing users into groups that have specific policies attached.

Q: How does an IAM user receive permissions from an IAM group?
A: The user inherits the permissions from policies attached to any IAM group they are a member of.

Q: Does adding a user to a Billing Admins group grant access to EC2?
A: No. The user only receives the permissions allowed by the policies attached to the group.

Q: What is an AWS managed policy?
A: An AWS managed policy is a policy created and maintained by AWS for common use cases or job functions.

Q: Why are IAM groups useful?
A: They simplify permission management by allowing administrators to assign policies to a group instead of attaching policies directly to each user.

Q: Can IAM groups contain IAM roles?
A: No. IAM groups can contain IAM users, not roles or other groups.

Q: Can IAM groups be used as principals in resource-based policies?
A: No. IAM groups are not principals and cannot be specified as principals in resource-based policies.

Q: What is the default permission state in AWS?
A: Deny. Access must be explicitly allowed by a policy.

Q: What overrides an allowed permission in AWS?
A: An explicit deny always overrides an allow.

Q: What is the preferred AWS service for centralized workforce access across multiple AWS accounts?
A: AWS IAM Identity Center.

Q: When should you use IAM roles instead of IAM users?
A: Use IAM roles for temporary access, service-to-service access, cross-account access, and federated access.

Q: Why might an IAM user with a billing policy still be unable to access billing information?
A: The account may require IAM access to billing to be enabled, or another policy type may be denying access.

Q: What is the main difference between RBAC and ABAC?
A: RBAC grants access based on job role or group membership, while ABAC grants access based on attributes such as tags.

Q: Why is AdministratorAccess usually the wrong answer for a billing-only user?
A: It violates least privilege by granting far more permissions than required.

Q: What should you check if a user receives access denied errors in AWS?
A: Check group membership, attached policies, explicit denies, permissions boundaries, SCPs, resource policies, and whether the required action is explicitly allowed.

Practice Questions

Question 1:
A finance employee needs access to view and manage billing information in a single AWS account. The employee does not need access to EC2, IAM, S3, or RDS. What is the best approach?

A. Attach the AdministratorAccess policy directly to the user
B. Create an IAM group for billing users, attach a billing-related policy, and add the user to the group
C. Create an EC2 role and attach it to the user
D. Give the user root account credentials

Correct Answer:
B

Explanation:
The best design is to use RBAC by creating a group for the billing job function and assigning only the permissions required for billing. AdministratorAccess and root credentials violate least privilege.

---

Question 2:
A user is added to an IAM group with a billing policy attached. The user logs in and receives access denied errors when opening the EC2 console. What is the most likely reason?

A. IAM groups do not grant permissions
B. Billing permissions do not include EC2 permissions
C. AWS managed policies cannot be attached to groups
D. The user must use the root account to access EC2

Correct Answer:
B

Explanation:
The user only receives the permissions attached to the group. A billing policy does not grant EC2 access unless EC2 actions are explicitly allowed by another applicable policy.

---

Question 3:
A company has multiple AWS accounts managed through AWS Organizations. The company wants centralized workforce access using existing corporate identities. Which solution is most appropriate?

A. Create separate IAM users in every AWS account
B. Use IAM Identity Center with groups and permission sets
C. Share the root account password with administrators
D. Create one IAM group in the management account and use it for all accounts

Correct Answer:
B

Explanation:
IAM Identity Center is the preferred service for centralized workforce access across multiple AWS accounts. It integrates with identity providers and assigns access using permission sets.

---

Question 4:
Which statement about IAM groups is correct?

A. IAM groups can contain IAM users, IAM roles, and other groups
B. IAM groups can be used as principals in S3 bucket policies
C. IAM groups are used to assign permissions to collections of IAM users
D. IAM groups automatically provide temporary credentials

Correct Answer:
C

Explanation:
IAM groups are containers for IAM users and simplify permission assignment. They cannot contain roles or other groups, are not principals in resource-based policies, and do not provide temporary credentials.

---

Question 5:
A user has an allow policy through group membership, but the user is still denied access to an AWS service. What could explain this?

A. AWS always denies group-based permissions
B. An explicit deny or permissions boundary may be restricting access
C. AWS managed policies only work for root users
D. IAM users cannot access the AWS Management Console

Correct Answer:
B

Explanation:
AWS policy evaluation considers multiple policy types. An explicit deny always overrides an allow, and permissions boundaries or SCPs can limit effective permissions.