Evidence · 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 minority of admitted types take no tags argument at all. A condition on either marker key is unmatched on those, so a grant covering them is wider than its condition.

Being identifiable without a tag and being governable by one are different properties, and an IAM condition needs the second. live/MARKERS.md carries the generated count and the per-service breakdown.

What a run itself needs

choudoufu makes few AWS calls of its own. Resource reads, writes and lists go through the provider plugin, so those are the AWS provider’s permissions, exactly as any OpenTofu run. Reference lists the fork’s own call surface per stage, which is short and fixed.

Marker stamping calls the tagging action for the resource’s own service. A role that can create a resource can usually already tag it, which matters when a policy is scoped tightly.

The rosters on this page are rendered from live/iam-reference.json, generated by tools/iamref-gen from AWS’s published reference. That artifact is authoritative about the condition keys it names and silent about the ones it omits.