An AI agent running in GitHub Actions needs to push artifacts to an AWS S3 bucket. A developer proposes storing AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY as GitHub Actions secrets. A security architect recommends using GitHub Actions OIDC instead. What is the primary security advantage of the OIDC approach over stored AWS credentials?

The correct answer is the statement that, with OIDC, no long-lived AWS credentials are ever stored — the workflow exchanges a short-lived OIDC token for temporary AWS credentials that expire automatically, and a leaked OIDC token cannot be used outside its specific workflow run context.

GitHub Actions OIDC integration with AWS works by configuring AWS IAM to trust GitHub's OIDC provider. When the workflow runs, it obtains a signed OIDC token from GitHub, identifying the specific repo, branch, and workflow, and presents it to AWS STS's AssumeRoleWithWebIdentity endpoint. AWS verifies the token's signature against GitHub's public key and issues temporary credentials — access key, secret key, and session token — that expire after a short duration, typically 1 hour.

The primary security advantage is the elimination of long-lived credentials: there are no AWS access keys stored anywhere — not in GitHub Secrets, not in configuration files, not anywhere. The OIDC token itself is short-lived and tied to the specific workflow run via the run_id claim, making it valid only within that execution context.

If an AWS access key stored in GitHub Secrets is leaked through a log, a compromised runner, or a misconfigured workflow, the leaked key provides indefinite AWS access until manually rotated. Rotation requires detecting the leak, generating new keys, updating the secret, and revoking the old key — all manual steps.

With OIDC, a leaked OIDC token is only valid for the current workflow run, typically minutes, and the resulting AWS temporary credentials expire automatically within the configured session duration.

The encrypted-at-rest claim is incorrect because GitHub Secrets encrypts secrets at rest using strong encryption. The comparison is not about encryption at rest — it is about the duration and revocability of the credentials.

The faster-latency claim is incorrect because OIDC adds an additional token exchange step, obtaining the OIDC token and calling STS, and is slightly slower than direct IAM authentication. The advantage is security, not performance.

The claim that AWS access keys stored in GitHub Secrets cannot be used with GitHub Actions runners is incorrect because AWS access keys can be used in GitHub Actions via environment variables — many workflows use this approach. The recommended approach is OIDC, not because keys cannot be used, but because OIDC is more secure.