TF-004 Use Terraform outside the core workflow Practice Question
Which THREE of the following are necessary steps to configure OIDC (OpenID Connect) for authenticating Terraform in a CI/CD pipeline?
⚠ Common exam trap
HashiCorp often tests the misconception that OIDC requires storing a long-lived token (Option A) or that the remote backend must use static credentials (Option C), when in fact OIDC replaces both with a trust-based, token-exchange mechanism that uses the `assume_role` and `web_identity_token` attributes.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Set up an OIDC provider in the target cloud (e.g., AWS IAM OIDC provider).
To authenticate Terraform in a CI/CD pipeline using OIDC, you must first establish trust between the CI platform and the cloud provider by creating an OIDC identity provider (e.g., an AWS IAM OIDC provider). This provider validates the JSON Web Token (JWT) issued by the CI platform (e.g., GitHub Actions, GitLab CI) and maps it to an IAM role, enabling token-based authentication without long-lived secrets.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Generate a long-lived API token and store it as a secret.
Why it's wrong here
Generating a long-lived API token and storing it as a secret is contrary to the fundamental security benefits of OpenID Connect (OIDC). OIDC's primary purpose is to eliminate the need for static, long-lived credentials by providing short-lived, dynamically issued identity tokens. Relying on a long-lived token reintroduces the very security risks OIDC aims to mitigate, such as credential compromise and the burden of secure secret management.
- ✓
Set up an OIDC provider in the target cloud (e.g., AWS IAM OIDC provider).
Why this is correct
Setting up an OIDC provider in the target cloud, such as an AWS IAM OIDC provider, is a foundational step. This establishes a trust relationship where the cloud environment explicitly trusts identity tokens issued by your CI/CD system (the OIDC issuer). Without this configured trust anchor, the cloud would have no mechanism to verify the authenticity or validity of the identity tokens presented by your CI/CD pipeline.
- ✗
Configure remote backend with static credentials.
Why it's wrong here
Configuring a remote backend with static credentials directly contradicts the security posture that OIDC aims to achieve. The goal of OIDC integration is to replace all forms of static, long-lived credentials, including those used for backend authentication, with ephemeral, dynamically issued tokens. Using static credentials for the remote backend would bypass the OIDC workflow and reintroduce a persistent attack vector that OIDC is designed to eliminate.
- ✓
Add a provider block with assume_role and web_identity_token attributes in Terraform configuration.
Why this is correct
Adding a provider block with `assume_role` and `web_identity_token` (or `web_identity_token_file`) attributes in the Terraform configuration is essential for Terraform to utilize OIDC. These attributes instruct the Terraform AWS provider to use the OIDC token, obtained from the CI/CD environment, to assume a specific IAM role. This mechanism allows Terraform to acquire temporary, short-lived credentials necessary to interact with AWS resources, adhering to the principle of least privilege and ephemeral access.
- ✓
Create an IAM role in the cloud that the CI job can assume.
Why this is correct
Creating an IAM role in the cloud that the CI job can assume is a critical authorization step. This role must have a trust policy configured to allow the OIDC provider (and specifically your CI/CD system's OIDC issuer) to assume it. The role's attached permissions policies then define the exact set of actions (e.g., `s3:PutObject`, `ec2:RunInstances`) that the CI job will be authorized to perform once it successfully assumes the role using its OIDC token.
Go deeper
Related to this question
About these practice questions
This TF-004 question is part of Courseiva's 428-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This TF-004 practice question is part of Courseiva's free HashiCorp certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the TF-004 exam.