AWS Access
What the CloudFormation stack creates
One IAM role, and the GitHub identity provider only if you ask for it. Nothing else is created and nothing existing is modified.
The resources
| Resource | Created |
|---|---|
| One IAM role | Always. Named per account, so it cannot collide across customers |
| The GitHub Actions OIDC identity provider | Only if you tick the box, because the account may already have one |
That is the complete list. No bucket, no function, no log group, no network resource, no scheduled job. Nothing already in your account is altered.
Why the template never owns the identity provider unconditionally
The provider is an account-level singleton shared with every other GitHub Actions workflow you run.
A stack that creates it unconditionally fails against any account that already federates GitHub. Worse, a stack that owns it deletes somebody else's infrastructure when it is rolled back or removed. Both of those happened, which is why the provider is referenced by identifier rather than managed, and why the choice is yours.
What is attached to the role
Two AWS managed policies, SecurityAudit and ViewOnlyAccess, which are the scanner's documented baseline. Then four inline grants, one per collector, listing exactly the calls those collectors make. Then the denials.
See What the role can read and What is explicitly denied.
Parameters you set
The engagement expiry is the one that matters. It is stamped into the trust policy and into a deny rule, so it is enforced by AWS rather than remembered by anybody.
The role name and maximum session duration are parameters too, with defaults that the assessment workflow expects. Changing the role name is possible and has consequences: GovIntel derives the role identifier from your account number precisely because the name is fixed.