Exams / SCS-C03 / Study guide / Attribute-based and role-based access control (tags, session tags)
Attribute-based and role-based access control (tags, session tags): SCS-C03 study notes and practice questions
What to know about Attribute-based and role-based access control (tags, session tags) for the SCS-C03 exam, from the Identity and Access Management domain (20% of the exam guide), then 1 free question to test it. Part of the SCS-C03 study guide.
These questions describe an organization with many teams, projects or departments and a need to keep each group inside its own resources without a separate role per group. The answer is usually tag-based: write one policy with a condition that matches the principal’s tag to the resource’s tag, and make sure both sides are tagged correctly.
The facts that decide answers
Condition keys compare tags: aws:PrincipalTag/<key> for the caller, aws:ResourceTag/<key> for the resource, and aws:RequestTag/<key> for tags supplied in the request. aws:TagKeys checks which tag keys a request uses.
Policy variables such as ${aws:PrincipalTag/team} let a single policy say “this team’s resources only.”
Principal tags come from IAM users and roles. Session tags are passed when a role is assumed, with --tags in the CLI or with the Tags parameter in the API, or they come from the federated assertion.
Identity Center attributes for access control map attributes from the identity source, such as department or cost center, into session tags.
Transitive session tags pass through role chaining when they are marked transitive.
sts:TagSession must be allowed for a session to carry tags. Without it, AssumeRole with tags fails.
Resources must carry the tags. An untagged resource matches no ABAC condition.
sts:SourceIdentity is for audit, not access. It identifies the person behind a role session and is separate from session tags.
How to choose
Scenario wording
Pick
Each team reaches only its own resources, with one shared policy
ABAC with a ${aws:PrincipalTag/team} policy variable matching aws:ResourceTag
Access by department from the corporate directory
Identity Center attributes for access control, mapped to session tags
Users must not change tags to gain access
Deny tag-editing actions on the access-control tag key with aws:TagKeys
Tags must survive a role chain
Transitive session tags
A few teams with stable membership
Separate permission sets per team, which is simpler
Audit must name the individual behind a shared role
sts:SourceIdentity
Common traps
Forgetting sts:TagSession in the trust policy, so AssumeRole with session tags fails.
Forgetting to tag resources, so the ABAC condition matches nothing.
Letting users edit the tag that drives access. If a user can change their team tag or the resource’s team tag, the control fails.
Using session tags as the audit identity. Use sts:SourceIdentity for that.
Choosing ABAC for a small, fixed set of teams. Separate roles or permission sets are easier to explain and audit.
Assuming every service supports tag conditions. Check the service’s condition keys before relying on them.
A research hospital runs a shared data platform with one S3 bucket, research-data, that holds a prefix for each department, such as research-data/cardiology/. Researchers sign in through a SAML identity provider, which sends a Department attribute for each person.
The data office wants one shared analyst role for all researchers, so that it does not maintain a role for each department. A researcher must be able to read only their own department's prefix, and adding a new department must need no policy edits.
Which solution meets these requirements?
Choose one answer.
AA. Create one role for each department, with a policy that allows only its prefix. Have the identity provider map each researcher to the role for their department, and add a role whenever a new department joins.
BB. Map the Department attribute to the role session name, and add a bucket policy statement for each department that allows only sessions with that name to read its prefix.
CC. Pass the Department attribute as a session tag, and allow sts:TagSession in the role trust policy. Allow reads on research-data/${aws:PrincipalTag/Department}/* in the role policy.
DD. Create one S3 access point for each department prefix, and give the shared role access to every access point. The access point names carry the department, so access follows each prefix.
Show the answer and explanation
Answer: C
A. Wrong: This works, but it creates a role for each department and a new role for every new department. The data office asked for one shared role, so this option misses the stated requirement.
B. Wrong: Session names can carry the department, but each department needs its own bucket policy statement. Adding a department then needs a policy edit, which the data office wants to avoid.
C. Right: Correct. The identity provider attribute becomes a session tag, and IAM fills it into the resource ARN on every request, so each researcher reaches only their own prefix. A new department works without a policy edit, and the trust policy must allow session tagging. Learn more: Passing session tags in AWS STS (opens in a new tab)
D. Wrong: Access points do not check a person's department, so the shared role could read through every access point. Each new department would also need a new access point and policy.
Explanation
Attribute-based access control passes the department from the identity provider as a session tag, and a policy variable puts that tag into the allowed prefix on every request. One shared role then works for every department with no policy edits. Per-department roles, per-department statements and access points each fail a stated requirement.
Want more on Attribute-based and role-based access control (tags, session tags)? The 5 full-length practice sets have 6 more Attribute-based and role-based access control (tags, session tags) questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Attribute-based and role-based access control (tags, session tags)