GH-200 - Secure and optimize automation (15% of the exam) - Section 5.3

Configure granular GITHUB_TOKEN permissions and use OIDC token federation to remove long-lived cloud secrets.

Configure granular GITHUB_TOKEN permissions at the workflow and job level using the permissions key. Use OIDC id-token federation to exchange a short-lived token for cloud provider credentials, eliminating the need for long-lived secrets.

GITHUB_TOKENpermissionsOIDCid-token federation

Practice question for this objective

Free sampleSecure and optimize automationhard

A deployment job needs to authenticate to AWS and assume an IAM role using GitHub's OIDC provider so that no long-lived AWS access keys are stored as repository secrets. The job already calls aws-actions/configure-aws-credentials with role-to-assume. The run fails because the workflow cannot obtain an OIDC token. Which addition to the workflow is required for the job to request that token?

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@<sha>
        with:
          role-to-assume: arn:aws:iam::111122223333:role/deploy
          aws-region: ap-southeast-2

AStore the role ARN as an encrypted repository secret and reference it through secrets in the with block, because OIDC still needs the target role supplied as a protected secret rather than as plain text.
BAdd an actions/setup-node step before the credentials step, because the OIDC token is issued by the Node toolchain that setup-node installs onto the GitHub-hosted runner for the job.
CAdd permissions with id-token: write to the deploy job, because that scope authorises the job to request a signed OIDC token from GitHub which the credentials action then exchanges for temporary AWS credentials. Correct
DAdd permissions with contents: write to the deploy job, because the OIDC token is written into the workspace as a file and the job needs repository write access to persist it before the exchange.

Grant the id-token: write permission so a job can request a GitHub OIDC token and exchange it for short-lived cloud credentials. Federating into a cloud provider with OIDC requires the workflow to obtain a signed token from GitHub's OIDC endpoint, and that request is gated by the id-token: write permission. Without it the runner cannot mint the token, so the credentials action has nothing to exchange with AWS STS. The role ARN is not a secret, setup steps for language runtimes are unrelated, and contents: write governs repository contents rather than token issuance.

Why A is wrong: Tempting because secrets feel mandatory for cloud auth, but the role ARN is not sensitive and the failure is the missing token request, so storing the ARN as a secret does not let the runner mint an OIDC token.

Why B is wrong: Tempting because many jobs begin with a setup step, but setup-node provisions a language runtime and has nothing to do with OIDC token issuance, so adding it leaves the token request unauthorised.

Why C is correct: The id-token: write permission lets the job fetch a signed JSON Web Token from GitHub's OIDC provider, and the credentials action exchanges that token with AWS STS for short-lived credentials, removing the need for stored keys.

Why D is wrong: Tempting because contents: write sounds like it covers writing a token, but the OIDC token is requested from GitHub's endpoint rather than written to the repository, and contents scope does not authorise the id-token request.

See more GH-200 practice questions, answers explained.

Exam traps in Secure and optimize automation

Answers that look right on this material and are not. Each one is a distractor from a different question in the GH-200 bank for this domain.

The same cloud access key the team is retiring is still stored as a repository secret so the credentials action can fall back to it whenever the token request happens to fail.
Why it is wrong: Tempting as a safety net, but keeping the key defeats the goal of removing long-lived credentials and is not required for the federated exchange, which relies solely on the short-lived token.
Add a job-level permissions block to the build job granting contents: read and checks: write, and trust that listing two scopes leaves the repository default untouched for any other job added later.
Why it is wrong: Tempting because a job-level block does scope that job correctly, but it governs only the build job, so any future job without its own block still inherits the broad repository default rather than the restricted set.
Replace the repository secret with an organisation secret holding the same client secret, because organisation secrets are rotated automatically by GitHub and are masked in logs, removing the manual rotation burden.
Why it is wrong: Tempting because organisation secrets reduce duplication, but GitHub does not rotate their values for you and the long-lived client secret still exists, so the manual rotation and expiry problem remains unsolved.

Examworthy is not affiliated with or endorsed by GitHub. Original, blueprint-aligned practice material only.