When configuring cloud provider access from GitHub Actions using OIDC, what should cloud IAM trust policies typically validate?
Select an answer to reveal the explanation.
Short Explanation
OIDC to AWS/Azure/GCP is 'prove this job is really from the right repo and environment,' not 'trust any job that says deploy.' Put those claims in the cloud trust policy. If you skip claim checks, any workflow in a compromised repo might mint cloud credentials. Pair with environment protection rules for prod.
Full Explanation
The correct answer is validating OIDC token claims such as repository, environment, and organizational identity. Cloud roles should trust GitHub's OIDC issuer and constrain sub/claims so only intended workflows assume the role. Validating only the repository owner's personal email address is insufficient and unstable. Validating only that the workflow file contains the word 'deploy' is trivial to spoof in a YAML string. Requiring that the runner has unlimited sudo without claims checks is dangerous. Prefer environment-scoped secrets/roles, deny default pass on all repos, and rotate away long-lived cloud keys after migration to OIDC.