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 and Infographic
OIDC to AWS/Azure/GCP is 'prove this job is really from repo X in env Y,' 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 below image
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. Option A is insufficient and unstable. Option B is trivial to spoof in a YAML string. Option D is dangerous. Prefer environment-scoped secrets/roles, deny default pass on all repos, and rotate away long-lived cloud keys after migration to OIDC.