DOP-C02 Practice Question 9: GitHub Actions OIDC Federation
AWS Certified DevOps Engineer – Professional (DOP-C02) · Test 1 · question 9 of 10
An external CI system (GitHub Actions) currently deploys to AWS using an IAM user's long-lived access keys stored as repository secrets. A security review demands that no long-lived AWS credentials exist anywhere outside AWS, that the deployment identity be usable only by workflows running from the main branch of one specific repository, and that credentials expire automatically. Rotating a secret on a schedule is not acceptable.
What should the team implement?
Show answer and explanation
Answer:
OIDC federation removes stored AWS credentials entirely. You register the CI provider's token issuer as an IAM OIDC identity provider, then create a role whose trust policy allows sts:AssumeRoleWithWebIdentity for that provider. The workflow presents a short-lived signed token minted by the CI system, and STS returns temporary credentials that expire on their own, satisfying both the "no long-lived credentials" and "expire automatically" constraints with nothing to rotate. The scoping requirement is met by conditions on the token's claims: aud (StringEquals) pins the audience, and sub (StringEquals on the exact string, not StringLike with a wildcard) pins the identity to one repository and one ref (GitHub documents the branch form of the claim as repo:ORG-NAME/REPO-NAME:ref:refs/heads/BRANCH-NAME). A sub condition written loosely, or omitted, is the classic misconfiguration here, because it would let any repository in any organization assume the role.
Option A still has long-lived AWS keys, merely moved; worse, it needs a *second* long-lived credential (the bootstrap user) to fetch the first, and rotation on a schedule is explicitly ruled out by the stem.
Option C is the wrong federation pattern. sts:AssumeRole with an ExternalId is the confused-deputy defence for a third-party AWS *account* acting on your behalf; it presumes the caller already holds AWS credentials, which is what we are trying to eliminate. Trusting the root principal of another account is also far too broad, and the ExternalId becomes yet another long-lived shared secret in the repository.
Option D keeps IAM users, so long-lived access keys remain. Access Analyzer reports unused access after the fact rather than preventing misuse, and the account password policy governs console passwords for IAM users; it has no effect on programmatic access keys at all.
References: Create an OpenID Connect (OIDC) identity provider in IAM; OpenID Connect reference (GitHub Docs)