ABAC and RBAC

Lesson 1 of 4 in Designing and Reviewing Access.

Two ways to decide who may touch what, and the exam wants to know when each one wins.

RBAC decides by job function. An auditor role, a database administrator role, a release engineer role — each with its own policy naming the resources it may reach. It is the familiar model, it is what IAM Identity Center permission sets express naturally, and it is the right answer whenever the functions are few and genuinely different.

ABAC decides by attribute match. One statement compares an attribute of the caller with an attribute of the resource, and the comparison does the work:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "SameProjectOnly",
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "aws:ResourceTag/project": "${aws:PrincipalTag/project}"
      }
    }
  }]
}

That document never needs editing again. A new project appears, resources get tagged project=atlas, engineers arrive with project=atlas on their sessions, and access works — no new policy, no new role, no change request. That is the property the exam is testing when a stem says "without modifying policies as new teams are onboarded".

The cost is that ABAC moves the security decision into your tagging discipline, which means three things must be true before it is safe.

The three preconditions for safe ABAC.

1. Principals cannot set their own governing tags. If an engineer can retag themselves — or retag a resource — project=payments, the comparison is self-service. In practice: deny iam:TagRole, iam:TagUser, and sts:TagSession for the governing keys to everyone except the identity pipeline, and control the resource side with aws:RequestTag and aws:TagKeys on create and tag actions:

{
  "Sid": "TagOnCreateMustMatchMyProject",
  "Effect": "Allow",
  "Action": ["ec2:CreateTags", "s3:PutBucketTagging"],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:RequestTag/project": "${aws:PrincipalTag/project}"
    },
    "ForAllValues:StringEquals": {
      "aws:TagKeys": ["project", "owner", "costcenter"]
    }
  }
}

[aws:RequestTag/project](/certifications/glossary?term=request-tag) forces the value being set to equal the caller's own project; aws:TagKeys with ForAllValues restricts which keys may be set at all. (Remember that ForAllValues is vacuously true when no tags are supplied — so pair it with a separate requirement that the tag be present if untagged creation must fail.)

2. The attribute arrives reliably. For federated identities the tag comes from a session tag: a SAML assertion attribute, an OIDC claim, or Identity Center's attributes for access control. For role-based workloads it can be a role tag. Either way, a principal with no project tag matches nothing and can do nothing under an ABAC statement — correct, but it means identity provisioning is now part of the access path.

3. Untagged resources are handled deliberately. A resource with no project tag matches no principal, so ABAC fails closed on it — which sounds good until a migration leaves a thousand untagged objects nobody can reach. Decide in advance: a tagging gate on creation, a Config rule flagging untagged resources, or an explicit break-glass role.

The honest answer for most estates is both. RBAC for the coarse duty — "this person is an engineer, not an auditor" — expressed as an Identity Center permission set, with ABAC conditions inside it for the per-project scope. The exam accepts that framing and often tests it as "which combination".

Key terms: ABAC (attribute-based access control), RBAC (role-based access control), aws:RequestTag / aws:TagKeys, Session tag, Transitive session tag, Permission set

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.