Review an AWS federation trust boundary.

A fictional GitHub.com repository uses immutable subject claims. Its production job references the production environment; approved deployment policy allows only reviewed main changes after environment approval. The AWS account has the GitHub OIDC provider configured. The role permissions are already restricted to the intended deployment resources; this exercise reviews who may assume that role. This federation will replace a shared deployment key that is still active during the transition. IDs below are fictional.

The proposed AWS IAM trust policy is:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:sample-team@100001/*"
        }
      }
    }
  ]
}

All three sanitized claim fixtures have issuer https://token.actions.githubusercontent.com and audience sts.amazonaws.com. They omit signatures and other JWT fields; no bearer token is provided. Environment protections are configured separately from IAM.

Use these observed subjects rather than guessing a branch-based subject. Also explain what prevents a feature branch in the same repository from entering the production environment.