Replace GitHub Actions long-lived keys with an OIDC identity provider and IAM role

SAP-C02 By islever Editorial Last updated

Prescribe security controls. Determine opportunities for modernization and enhancements. Design a multi-account AWS environment.

Short answer

B Create an IAM OIDC identity provider for GitHub and have the pipeline assume a role via sts:AssumeRoleWithWebIdentity.

Question

A company is using GitHub Actions to run a CI/CD pipeline that accesses resources on AWS. The company has an IAM user that uses a secret key in the pipeline to authenticate to AWS. An existing IAM role with an attached policy grants the required permissions to deploy resources. The company’s security team implements a new requirement that pipelines can no longer use long-lived secret keys. A solutions architect must replace the secret key with a short-lived solution. Which solution will meet these requirements with the LEAST operational overhead?
  1. Create an IAM SAML 2.0 identity provider (IdP) in AWS Identity and Access Management (IAM). Create a new IAM role with the appropriate trust policy that allows the sts:AssumeRole API call. Attach the existing IAM policy to the new IAM role. Update GitHub to use SAML authentication for the pipeline.
  2. Create an IAM OpenID Connect (OIDC) identity provider (IdP) in AWS Identity and Access Management (IAM). Create a new IAM role with the appropriate trust policy that allows the sts:AssumeRoleWithWebIdentity API call from the GitHub OIDC IdP. Update GitHub to assume the role for the pipeline. Correct Answer
  3. Create an Amazon Cognito identity pool. Configure the authentication provider to use GitHub. Create a new IAM role with the appropriate trust policy that allows the sts:AssumeRoleWithWebIdentity API call from the GitHub authentication provider. Configure the pipeline to use Cognito as its authentication provider.
  4. Create a trust anchor to AWS Private Certificate Authority. Generate a client certificate to use with AWS IAM Roles Anywhere. Create a new IAM role with the appropriate trust policy that allows the sts:AssumeRole API call. Attach the existing IAM policy to the new IAM role. Configure the pipeline to use the credential helper tool and to reference the client certificate public key to assume the new IAM role.

Key Takeaways

GitHub Actions presents a signed OIDC token identifying the repository, workflow, and branch, so IAM can trust that token through an OIDC identity provider and the sts:AssumeRoleWithWebIdentity call issues short-lived credentials scoped to that run, with no stored secret anywhere.

A company runs CI/CD pipelines with GitHub Actions that authenticate to AWS using an IAM user secret key. Security now requires that pipelines stop using long-lived secret keys, and an existing IAM role already holds the needed deployment permissions.

Common mistake: Choosing SAML. GitHub Actions is built around OIDC federation for CI/CD and does not use the older SAML protocol for pipeline authentication, so an IAM SAML identity provider would never be invoked by the pipeline. IAM Roles Anywhere is likewise designed for hosts with no AWS identity, not for a cloud-native CI/CD service.

Expert Analysis

Why the Answer Is Correct

GitHub Actions can supply a signed OpenID Connect identity token that asserts the repository, workflow, and branch. Creating an IAM OIDC identity provider for GitHub and a role whose trust policy permits the sts:AssumeRoleWithWebIdentity call for that provider means the pipeline exchanges the token for short-lived credentials scoped to a single run, and the existing permissions policy is attached to that role so deployment behaviour is unchanged. Because no credential is stored in the repository or pipeline secrets, the long-lived key requirement is satisfied and there is nothing to rotate or leak.

Why the Other Options Are Wrong

A: GitHub Actions does not use SAML to authenticate pipelines, so an IAM SAML identity provider would sit unused and the pipeline would still need a stored credential to call AssumeRole. C: An Amazon Cognito identity pool configured for GitHub is a heavier construction that adds a user identity layer the pipeline does not need, since the workload is machine-to-machine federation rather than end-user sign-in, so it fails the least operational overhead requirement. D: IAM Roles Anywhere with a private CA trust anchor is for on-premises hosts, workstations, or devices that have no AWS identity of their own, and it requires running a credential helper process and distributing client certificates, which is far more operational work than OIDC federation.

Community Comment Notes

The community voted 100 to 0 for B, and the top-voted comment gave the three reasons succinctly: GitHub does not support the aging SAML protocol, GitHub does support OIDC, and the Cognito and Roles Anywhere options are heavily overengineered for this use case. Another commenter independently ruled out A and D on the basis of the sts:AssumeRole call and confirmed B has the least operational overhead.

Official Reference

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html

This link opens the official vendor documentation in a new tab.

Community Votes

B
100%

100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 3 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 3

  1. Dgix 👍 8 Answered B
    A is incorrect because GitHub doesn't support the aging SAML protocol. B is correct because GitHub does support OIDC. C is hysterically overengineered for this use case. D even more so.
  2. AzureDP900 👍 2
    Option B involves creating an IAM OpenID Connect (OIDC) identity provider in AWS Identity and Access Management (IAM). This will allow the company to use GitHub OIDC authentication, which provides a short-lived token for authentication. The solution also creates a new IAM role with the appropriate trust policy that allows the sts:AssumeRoleWithWebIdentity API call from the GitHub OIDC IdP. This ensures that the pipeline can assume the necessary permissions without using long-lived secret keys.
  3. VerRi 👍 1 Answered B
    A and D are out because of sts:AssumeRole. B with the least operational overhead.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Modernize centralized firewall appliances with a Gateway Load Balancer and Auto Scaling

S-grade

Use Lambda over a CloudWatch Logs stream to count unique users per client

S-grade

Serve global game assets with Route 53 latency records and health checks

S-grade

Reach a cross-account S3 data lake through a gateway endpoint and an access point bucket policy

S-grade

Practice All SAP-C02 Questions

Access 85 questions with complete answers and detailed explanations.

View Full SAP-C02 Practice Test →

← Back to SAP-C02 Study Guide