A production deploy job uses OIDC to assume a cloud role. Which combination best limits which workflow runs may obtain that privileged cloud access?
Select an answer to reveal the explanation.
Short Explanation and Infographic
OIDC needs id-token: write, production should sit behind environment protections, and the cloud must enforce sub/aud. Skipping JWT checks or sprinkling root keys into PR jobs is indefensible.
Full explanation below image
Full Explanation
Defense in depth for cloud deploy from Actions: (1) grant id-token: write so the job can mint a GitHub OIDC JWT, (2) bind the job to a GitHub Environment with required reviewers/wait timers/deployment branches, (3) configure the cloud identity provider/role trust to accept only expected issuer, audience, and subject claims (repo, ref, environment). contents: read alone does not issue OIDC tokens. Long-lived root keys in GITHUB_ENV on PRs invert the security model. Fork PRs should not receive privileged cloud federation. Prefer official cloud login actions that implement the OIDC dance correctly.