Documentation · Scoping a role

Where AWS honours the condition

Where the key is confirmed

AWS’s own Service Authorization Reference is a floor here, not a ceiling: it is authoritative about the services it explicitly names and silent about the rest, and AWS documents tag-based authorization for services this reference says nothing about, Lambda among them. 17 of 157 checked services explicitly name aws:ResourceTag on their tagging action - the confirmed count, not the working count.

Services with no verdict

The reference states nothing either way for these - S3, IAM and RDS among them. Check them against AWS’s own IAM documentation and test the policy directly; this is not a list of services where scoping fails, only a list this particular reference doesn’t cover.

Types that carry no tags

A marker needs somewhere to live, and a type with no tags argument has nowhere to put one.

345 of the 1027 admitted AWS resource types take no tags argument at all. Most untaggable, by service: EC2 29 of 95, S3 14 of 16, ApiGateway 11 of 19, Cognito 10 of 12, IAM 8 of 17, SSO 8 of 10.

A condition on either marker key is unmatched on those, so a grant covering them is wider than its condition. live/MARKERS.md has the full per-service table.

An object declared as a block inside another resource is not a resource at all: an EC2 instance’s root_block_device is a real volume, but the marker goes on the instance’s tags only, so no marker condition matches the volume.

Types tagged after the create

Some taggable types cannot take tags in their create call, aws_route53_zone among them. choudoufu creates them unmarked and tags them straight afterwards (#1084), so an aws:RequestTag condition never sees their create, and an aws:ResourceTag one never sees that tag write. live/MARKERS.md has the grant they need instead.

What a run itself needs

The provider plugin makes the resource calls, with the AWS provider’s usual permissions. The fork’s own short call surface, and the tagging action each service’s marker stamping calls, are in Reference.

The rosters on this page are rendered from live/iam-reference.json, generated by tools/iamref-gen from AWS’s published reference.