Back to HashiCorp Certified: Terraform Associate (TA-004)

Terraform Configuration

Write advanced Terraform configurations using resources, data sources, variables, outputs, and expressions.

This domain covers writing Terraform configuration in depth. It includes using and differentiating resource and data blocks, creating cross-resource references, working with variables and outputs, understanding complex types like lists, maps, and objects, writing dynamic configuration using expressions and functions, defining resource dependencies, validating with custom conditions, and managing sensitive data including secrets with Vault.
5 minutes 5 Questions

Terraform Configuration refers to the set of files written in HashiCorp Configuration Language (HCL) or JSON that define the infrastructure resources you want to create, manage, and provision. These configuration files serve as the blueprint for your infrastructure and are the foundation of Infrast…

Concepts covered: Resource blocks and syntax, Data sources and data blocks, Resource vs data source differences, Resource attribute references, Cross-resource dependencies, Implicit and explicit dependencies, Input variables (variable blocks), Output values (output blocks), Variable definitions and defaults, Setting variable values, List and set types, Map and object types, Tuple types and type constraints, Type conversion and coercion, Terraform expressions and operators, Built-in functions, Conditional expressions, For expressions and iteration, Dynamic blocks, The depends_on meta-argument, Dependency graph and ordering, Preconditions and postconditions, Variable validation rules, Sensitive variables and outputs, Secrets management best practices, Vault integration for secrets

Test mode:
Start practice test
TA-004 - Terraform Configuration Example Questions

Test your knowledge of Terraform Configuration

Question 1

A global logistics company operates a Terraform-managed infrastructure spanning five AWS regions. The platform team uses Terraform Enterprise with Sentinel policies for governance. During a quarterly security assessment, the team discovered that their current workflow involves developers creating short-lived AWS IAM access keys through a self-service portal, then manually configuring these as workspace variables in Terraform Enterprise. The security team has flagged several issues: keys are valid for 24 hours but often not revoked after Terraform runs complete, multiple workspaces share the same credentials, and there's no centralized audit trail linking specific infrastructure changes to credential usage. The company's new security policy mandates that credentials must be scoped to individual Terraform runs, automatically expire after use, and provide complete auditability of which credentials modified which resources. The platform team needs to redesign their credential management approach while minimizing changes to existing Terraform configurations. Which architectural change most effectively addresses all three security policy mandates?

Correct Answer: Implement dynamic credentials using Terraform Enterprise's native integration with AWS, configuring OIDC trust relationships that generate run-specific temporary credentials with automatic expiration and workspace-level audit logging

The correct answer is implementing dynamic credentials using Terraform Enterprise's native integration with AWS through OIDC trust relationships.

This solution directly addresses all three security policy mandates:

  1. Credentials scoped to individual Terraform runs: OIDC-based dynamic credentials generate unique, run-specific temporary credentials. Each Terraform run receives its own credential set that is tied specifically to that execution context.

  2. Automatic expiration after use: Dynamic credentials through OIDC are inherently short-lived and automatically expire. There's no need for manual revocation because the credentials are generated on-demand for each run and expire immediately after the run completes.

  3. Complete auditability: Terraform Enterprise's native integration provides workspace-level audit logging that directly links the generated credentials to specific Terraform runs, workspaces, and the resources they modify. This creates the centralized audit trail the security team requires.

Additionally, this approach minimizes changes to existing Terraform configurations because it operates at the Terraform Enterprise workspace level rather than requiring modifications to the Terraform code itself.

The Vault-based approach with the AWS secrets engine would require integrating the Vault provider into all Terraform configurations, which contradicts the requirement to minimize changes to existing configurations. It also introduces additional operational complexity.

The solution involving IAM roles with assume-role permissions still relies on long-lived role ARNs stored as workspace variables. While CloudTrail provides logging, the credentials themselves aren't scoped to individual runs and don't automatically expire after each Terraform operation.

The custom credential broker approach would generate temporary STS tokens, but it introduces significant operational overhead by requiring development and maintenance of a custom service. It also doesn't provide the same level of native integration and auditability that Terraform Enterprise's built-in dynamic credentials feature offers, and the credential-to-run mapping would need to be manually implemented.

Question 2

You are a platform engineer at a government contractor developing a Terraform module for deploying Azure virtual machines. The module includes a variable called 'vm_sku' that accepts string values representing Azure VM sizes. Your security policy requires that VMs must have a minimum of 4 vCPUs, which corresponds to SKUs containing 'Standard_D4' or higher numeric suffixes (like Standard_D4s_v3, Standard_D8s_v5, etc.). During a compliance review, you discover that some deployments used 'Standard_D2s_v3' which violated the minimum compute requirements. A team member suggests using a regex pattern in the validation block to match SKUs with numeric values of 4 or greater. However, you realize that regex in Terraform's 'can(regex())' function cannot perform numeric comparisons on extracted values. You need to implement a practical validation approach. Which validation strategy best addresses this VM SKU validation requirement?

Correct Answer: Create a validation block using the 'contains' function with an explicit list of all approved SKU strings that meet the 4 vCPU minimum requirement

The correct answer is to use the 'contains' function with an explicit list of all approved SKU strings that meet the 4 vCPU minimum requirement.

This approach is the most practical and reliable solution for several reasons:

  1. Explicit allowlist approach: By maintaining a curated list of approved VM SKUs (like ['Standard_D4s_v3', 'Standard_D4s_v5', 'Standard_D8s_v3', 'Standard_D8s_v5', etc.]), you ensure only pre-approved, compliant sizes are permitted.

  2. Simple and maintainable: The validation block would look like:

validation {
condition = contains(["Standard_D4s_v3", "Standard_D4s_v5", "Standard_D8s_v3", ...], var.vm_sku)
error_message = "VM SKU must be from the approved list with minimum 4 vCPUs."
}

  1. Government compliance friendly: For security-conscious environments like government contractors, an explicit allowlist is often preferred over pattern matching because it provides deterministic, auditable control.

Why the other approaches are problematic:

  • Using 'can(regex())' with 'tonumber': The question explicitly states that regex in Terraform's 'can(regex())' function cannot perform numeric comparisons on extracted values. The regex function returns matched strings, and combining this with tonumber in a validation condition is complex and error-prone.

  • Using 'substr' with 'tonumber': Azure SKU naming is not consistent enough for simple substring extraction. SKUs like 'Standard_D4s_v3' vs 'Standard_D16as_v5' have varying formats, making substr-based extraction unreliable and brittle.

  • Using 'regex' with 'parseint': While parseint exists in Terraform, the complexity of extracting the exact numeric CPU count from various SKU naming patterns (D4, D4s, D4as, D4ds, etc.) makes this approach fragile and difficult to maintain. Different VM series have different naming conventions.

The contains-based allowlist approach is the most robust, maintainable, and compliance-friendly solution for this government contractor scenario.

Question 3

A platform engineering team at a logistics company is building a Terraform module that provisions AWS Lambda functions for order processing. Each Lambda function requires access to different third-party API credentials stored in HashiCorp Vault. The team has configured the Vault provider using AppRole authentication, where the role_id is stored in the CI/CD pipeline variables and the secret_id is fetched from a secure parameter store at runtime. During a deployment, the team notices that some Lambda functions are being created with empty environment variables for the API credentials, while others receive the correct values. The Vault audit logs show successful secret retrievals for all requested paths. Investigation reveals that the issue occurs intermittently and seems correlated with parallel resource creation. What is the most likely cause of this behavior and how should the team address it?

Correct Answer: Terraform's parallel execution is causing race conditions where some resources are created before dependent data source values are fully resolved; adding explicit depends_on references between the vault data sources and the Lambda resources should resolve the timing issue

The correct answer identifies that Terraform's parallel execution is causing race conditions where some resources are created before dependent data source values are fully resolved.

When Terraform executes in parallel (which is the default behavior), it attempts to create multiple resources simultaneously to improve performance. If Terraform doesn't properly understand the dependency between a Vault data source and the Lambda resource that uses its output, it may attempt to create the Lambda function before the data source has finished retrieving the secret value. This results in empty environment variables for some Lambda functions while others (that happened to be created after their corresponding data sources completed) receive the correct values.

The intermittent nature of the issue strongly supports this diagnosis - race conditions by definition produce inconsistent results depending on timing. The fact that Vault audit logs show successful retrievals confirms the secrets are being fetched, but the timing of when those values become available to dependent resources is the problem.

Adding explicit depends_on references between the Vault data sources and Lambda resources ensures Terraform waits for the data source to complete before attempting to create the Lambda function, resolving the timing issue.

The other answers are incorrect for the following reasons:

  • The answer suggesting AppRole rate-limiting is unlikely because Vault audit logs show successful secret retrievals for all requested paths. If rate-limiting were occurring, we would see failed authentication attempts or errors in the logs, not successful retrievals.

  • The answer about Terraform caching stale values is incorrect because there is no 'skip_child_module_locking' parameter in the Vault provider, and Terraform data sources are refreshed during each plan/apply by default. The described caching behavior doesn't match how Terraform actually works.

  • The answer suggesting token renewal conflicts and recommending separate provider aliases is overly complex and doesn't address the actual problem. The Vault provider handles concurrent operations with a single token, and creating separate provider aliases with unique credentials for each Lambda would be unnecessarily complicated and wouldn't solve a dependency resolution issue.

More Terraform Configuration questions
777 questions (total)
Start 100 question test