OIDC authentication for CI/CD in Terraform - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the main purpose of OIDC in CI/CD pipelines?

OpenID Connect (OIDC) is often used in CI/CD pipelines. What is its main purpose?

A To securely authenticate pipeline jobs without storing long-lived credentials

B To encrypt all data transferred between pipeline stages

C To manage version control of pipeline scripts

D To monitor pipeline performance metrics in real-time

💡 Hint

Think about how pipelines avoid using static secrets.

OIDC allows CI/CD jobs to authenticate dynamically using short-lived tokens, avoiding the need to store static credentials.

💻 Command Output

intermediate

What is the output of this Terraform snippet configuring OIDC provider?

Given this Terraform code snippet, what will be the value of aws_iam_openid_connect_provider.example.url after apply?

Terraform

resource "aws_iam_openid_connect_provider" "example" {
  url = "https://oidc.eks.us-west-2.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E"
  client_id_list = ["sts.amazonaws.com"]
  thumbprint_list = ["9e99a48a9960b14926bb7f3b02e22da0afd6e1e4"]
}

A 9e99a48a9960b14926bb7f3b02e22da0afd6e1e4

B https://oidc.eks.us-west-2.amazonaws.com/id/INVALID

C https://sts.amazonaws.com

D https://oidc.eks.us-west-2.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E

💡 Hint

Look at the url attribute in the resource.

The url attribute is set explicitly to the OIDC provider URL string.

❓ Configuration

advanced

Which Terraform block correctly configures a trust relationship for OIDC in an IAM role?

Choose the Terraform assume_role_policy JSON that correctly allows OIDC authentication from a specific provider.

A

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Principal": {"AWS": "*"},
    "Action": "sts:AssumeRole"
  }]
}

B

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Federated": "arn:aws:iam::123456789012:oidc-provider/invalid-provider"},
    "Action": "sts:AssumeRoleWithWebIdentity"
  }]
}

C

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Federated": "arn:aws:iam::123456789012:oidc-provider/oidc.eks.us-west-2.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E"},
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "oidc.eks.us-west-2.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E:sub": "system:serviceaccount:default:my-service-account"
      }
    }
  }]
}

D

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "ec2.amazonaws.com"},
    "Action": "sts:AssumeRole"
  }]
}

💡 Hint

Look for the correct Principal and Action for OIDC.

The trust policy must allow sts:AssumeRoleWithWebIdentity for the correct OIDC provider ARN and include conditions for the service account.

❓ Troubleshoot

advanced

Why does this GitHub Actions workflow fail to authenticate with AWS using OIDC?

Given this snippet from a GitHub Actions workflow, why does the AWS CLI command fail with 'AccessDenied'?

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubOIDCRole
          aws-region: us-west-2
      - name: Deploy
        run: aws s3 ls

A The workflow is missing the 'id-token: write' permission

B The IAM role's trust policy does not allow GitHub's OIDC provider

C The AWS region is incorrectly specified

D The AWS CLI command 'aws s3 ls' is invalid

💡 Hint

Check the IAM role trust policy for OIDC provider permissions.

If the IAM role's trust policy does not include GitHub's OIDC provider ARN, the role assumption will fail with AccessDenied.

🔀 Workflow

expert

Order the steps to enable OIDC authentication for a CI/CD pipeline deploying to AWS

Arrange these steps in the correct order to set up OIDC authentication for a CI/CD pipeline that deploys to AWS.

A 1,3,2,4

B 1,2,3,4

C 3,1,2,4

D 2,1,3,4

💡 Hint

Think about setting up AWS first, then configuring the pipeline to use it.

First, create the OIDC provider in AWS (1), then create the IAM role trusting that provider (3). Next, configure the pipeline to request tokens (2), and finally assume the role (4).

Practice

1. What is the main benefit of using OIDC authentication in CI/CD pipelines with Terraform?

easy

A. It disables all access restrictions for faster builds.

B. It automatically deploys code without any manual approval.

C. It replaces Terraform with a different infrastructure tool.

D. It allows secure authentication without storing passwords in the pipeline.

Solution

1. Step 1: Understand OIDC purpose in CI/CD

   OIDC provides a secure way for pipelines to prove identity without passwords.

2. Step 2: Connect to Terraform usage

   Terraform can create roles that trust OIDC tokens, avoiding password storage.

3. Final Answer:

   It allows secure authentication without storing passwords in the pipeline. -> Option D

4. Quick Check:

   OIDC = passwordless secure authentication [OK]

Hint: OIDC means no passwords needed in CI/CD [OK]

Common Mistakes:

• Thinking OIDC automates deployment without approval
• Confusing OIDC with replacing Terraform
• Assuming OIDC disables access controls

2. Which Terraform resource block correctly defines an IAM role trusting GitHub Actions OIDC provider?

easy

A. resource "aws_iam_role" "github_oidc_role" {
assume_role_policy = jsonencode({
Version = "2012-10-17",
Statement = [{
Effect = "Allow",
Principal = { Federated = "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com" },
Action = "sts:AssumeRoleWithWebIdentity"
}]
})
}

B. resource "aws_iam_role" "github_oidc_role" {
assume_role_policy = jsonencode({
Version = "2012-10-17",
Statement = [{
Effect = "Allow",
Principal = { Service = "github.com" },
Action = "sts:AssumeRole"
}]
})
}

C. resource "aws_iam_role" "github_oidc_role" {
assume_role_policy = jsonencode({
Version = "2012-10-17",
Statement = [{
Effect = "Allow",
Principal = { AWS = "arn:aws:iam::123456789012:root" },
Action = "sts:AssumeRoleWithWebIdentity"
}]
})
}

D. resource "aws_iam_role" "github_oidc_role" {
assume_role_policy = jsonencode({
Version = "2012-10-17",
Statement = [{
Effect = "Allow",
Principal = { Federated = "arn:aws:iam::123456789012:oidc-provider/github.com" },
Action = "sts:AssumeRoleWithWebIdentity"
}]
})
}

Solution

1. Step 1: Identify correct OIDC provider ARN format

   The OIDC provider ARN for GitHub Actions uses 'token.actions.githubusercontent.com'.

2. Step 2: Check assume_role_policy structure

   The policy must allow 'sts:AssumeRoleWithWebIdentity' with Principal as Federated and correct ARN.

3. Final Answer:

   The resource block with Federated principal using 'token.actions.githubusercontent.com' and 'sts:AssumeRoleWithWebIdentity' action. -> Option A

4. Quick Check:

   Correct OIDC ARN + sts:AssumeRoleWithWebIdentity = resource "aws_iam_role" "github_oidc_role" { assume_role_policy = jsonencode({ Version = "2012-10-17", Statement = [{ Effect = "Allow", Principal = { Federated = "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com" }, Action = "sts:AssumeRoleWithWebIdentity" }] }) } [OK]

Hint: OIDC provider ARN uses token.actions.githubusercontent.com [OK]

Common Mistakes:

• Using Service principal instead of Federated
• Wrong OIDC provider ARN format
• Using sts:AssumeRole instead of sts:AssumeRoleWithWebIdentity

3. Given this Terraform snippet for an IAM role trust policy, what is the effect of the condition block?

condition = {
  StringEquals = {
    "token.actions.githubusercontent.com:sub" = "repo:myorg/myrepo:ref:refs/heads/main"
  }
}

medium

A. Allows any GitHub repo to assume the role.

B. Restricts role assumption to the main branch of myorg/myrepo only.

C. Blocks all role assumptions from GitHub Actions.

D. Allows only forks of myorg/myrepo to assume the role.

Solution

1. Step 1: Understand the condition key

   The condition uses 'token.actions.githubusercontent.com:sub' to specify the GitHub repo and branch.

2. Step 2: Interpret the value

   The value 'repo:myorg/myrepo:ref:refs/heads/main' restricts access to the main branch of that repo only.

3. Final Answer:

   Restricts role assumption to the main branch of myorg/myrepo only. -> Option B

4. Quick Check:

   Condition limits to specific repo and branch = Restricts role assumption to the main branch of myorg/myrepo only. [OK]

Hint: Condition with repo and ref limits branch access [OK]

Common Mistakes:

• Ignoring the branch restriction in condition
• Assuming condition allows all repos
• Confusing forks with original repo access

4. You wrote this Terraform assume_role_policy but your CI/CD pipeline fails to authenticate:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Federated": "arn:aws:iam::123456789012:oidc-provider/github.com" },
    "Action": "sts:AssumeRoleWithWebIdentity"
  }]
}

What is the most likely error?

medium

A. The Principal should use 'Service' instead of 'Federated'.

B. The Action should be 'sts:AssumeRole' instead of 'sts:AssumeRoleWithWebIdentity'.

C. The OIDC provider ARN is incorrect; it should be 'token.actions.githubusercontent.com'.

D. The Version date is invalid and must be updated.

Solution

1. Step 1: Check the OIDC provider ARN

   The ARN 'arn:aws:iam::123456789012:oidc-provider/github.com' is incorrect for GitHub Actions.

2. Step 2: Identify correct ARN for GitHub Actions

   The correct ARN uses 'token.actions.githubusercontent.com' as the OIDC provider host.

3. Final Answer:

   The OIDC provider ARN is incorrect; it should be 'token.actions.githubusercontent.com'. -> Option C

4. Quick Check:

   Wrong OIDC ARN causes auth failure = The OIDC provider ARN is incorrect; it should be 'token.actions.githubusercontent.com'. [OK]

Hint: Check OIDC ARN spelling carefully for GitHub Actions [OK]

Common Mistakes:

• Using 'sts:AssumeRole' instead of 'sts:AssumeRoleWithWebIdentity'
• Confusing Federated with Service principal
• Ignoring ARN format for OIDC provider

5. You want to create a Terraform IAM role for GitHub Actions that only allows workflows from the 'release' branch of 'myorg/myrepo' to assume it. Which condition block correctly enforces this restriction?

hard

A. {
"StringEquals": {
"token.actions.githubusercontent.com:sub": "repo:myorg/myrepo:ref:refs/heads/release"
}
}

B. {
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:myorg/myrepo:ref:refs/heads/*"
}
}

C. {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
}
}

D. {
"StringNotEquals": {
"token.actions.githubusercontent.com:sub": "repo:myorg/myrepo:ref:refs/heads/main"
}
}

Solution

1. Step 1: Understand the condition key and value

   To restrict to the 'release' branch, the condition must match 'repo:myorg/myrepo:ref:refs/heads/release'.

2. Step 2: Choose correct operator

   'StringEquals' ensures exact match, so only 'release' branch is allowed.

3. Final Answer:

   The condition block with StringEquals matching 'repo:myorg/myrepo:ref:refs/heads/release'. -> Option A

4. Quick Check:

   Exact branch match uses StringEquals with correct ref [OK]

Hint: Use StringEquals with exact repo and branch ref [OK]

Common Mistakes:

• Using StringLike with wildcard allowing all branches
• Checking audience (aud) instead of subject (sub)
• Using StringNotEquals which excludes main but allows others