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

Core Terraform Workflow

Execute the write, plan, and apply workflow including initialization, validation, and destruction.

This domain covers the core Terraform workflow of write, plan, and apply. It includes describing the overall workflow, initializing a Terraform working directory with terraform init, validating configurations with terraform validate, generating and reviewing execution plans with terraform plan, applying changes with terraform apply, destroying infrastructure with terraform destroy, and applying formatting with terraform fmt.
5 minutes 5 Questions

The Core Terraform Workflow consists of three main stages: Write, Plan, and Apply. This workflow represents the fundamental process that practitioners follow when using Terraform to manage infrastructure as code. **Write Stage:** In this initial phase, you author your Terraform configuration files…

Concepts covered: The Write, Plan, Apply workflow, Infrastructure lifecycle with Terraform, The terraform init command, Working directory initialization, Downloading providers and modules, The terraform validate command, Configuration syntax validation, The terraform plan command, Understanding plan output, Plan file generation and usage, The terraform apply command, Apply confirmation and auto-approve, Applying saved plan files, The terraform destroy command, Targeted destruction of resources, The terraform fmt command, Configuration formatting standards

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

Test your knowledge of Core Terraform Workflow

Question 1

You are a DevOps engineer at a media streaming company. Your team maintains a Terraform configuration that uses three providers: AWS, Cloudflare, and Datadog. The configuration also references five child modules stored in a private GitLab repository. A new team member clones the repository and attempts to run 'terraform validate' to check the syntax before making changes, but receives an error about uninitialized providers. They then run 'terraform init' and notice it takes several minutes to complete. The team member asks you to explain what operations terraform init performed during those minutes that made the subsequent validate command work. Which response accurately describes the initialization operations that occurred?

Correct Answer: Downloaded provider plugins for AWS, Cloudflare, and Datadog from the configured registries, retrieved the five child modules from the GitLab repository, and prepared the working directory with necessary plugin references

The terraform init command performs several critical initialization operations that prepare the working directory for Terraform operations.

The correct answer accurately describes what terraform init does:

  1. Downloads provider plugins: Terraform init downloads the required provider plugins (AWS, Cloudflare, and Datadog in this case) from the configured registries (typically the HashiCorp registry or any configured mirrors). These plugins are necessary for Terraform to interact with each provider's API.

  2. Retrieves child modules: When modules are referenced from remote sources like a private GitLab repository, terraform init downloads these modules and stores them locally in the .terraform/modules directory. With five modules from GitLab, this can take considerable time depending on network speed and module size.

  3. Prepares the working directory: This includes setting up the .terraform directory structure and creating necessary plugin references so subsequent commands like validate, plan, and apply can function properly.

The other options are incorrect for the following reasons:

  • One option incorrectly states that init verifies syntax of .tf files and creates a state file. Syntax verification is the job of terraform validate, not init. State files are created during terraform apply when resources are actually created, not during initialization.

  • Another option incorrectly claims that init connects to provider APIs to validate credentials and generates a dependency graph. Provider credential validation happens during plan/apply, not init. The dependency graph is generated during plan and apply operations, not during initialization.

  • The last incorrect option suggests that init executes a preliminary plan to identify configuration errors. This is false - terraform init does not run any plan operations. Planning is a separate step performed by terraform plan.

Question 2

You are a DevOps engineer at a fintech company responsible for maintaining Terraform configurations. A developer has created a new module that provisions an AWS DynamoDB table with a global secondary index. The module includes the following resource definition: resource "aws_dynamodb_table" "transactions" { name = var.table_name billing_mode = "PAY_PER_REQUEST" hash_key = "transaction_id" attribute { name = "transaction_id" type = "S" } attribute { name = "customer_id" type = "N" } global_secondary_index { name = "CustomerIndex" hash_key = "customer_id" projection_type = "ALL" } } After running terraform init and terraform validate, both commands complete successfully. However, when terraform apply is executed, AWS returns an error indicating that the attribute type for customer_id should be "S" (String) based on the actual data format your application uses. A colleague argues that terraform validate should have detected this type mismatch. What is the correct explanation for this validation behavior?

Correct Answer: The validate command checks HCL syntax and configuration structure but cannot verify whether attribute types match your application's actual data requirements

The correct answer explains that terraform validate checks HCL syntax and configuration structure but cannot verify whether attribute types match your application's actual data requirements.

The terraform validate command performs the following checks:
- Verifies that the configuration files are syntactically valid HCL
- Checks that the configuration is internally consistent
- Validates that required arguments are present
- Confirms that attribute names and types conform to the provider's schema

However, terraform validate does NOT:
- Connect to any remote services or APIs
- Verify that your configuration values are semantically correct for your specific use case
- Check whether your data types match your application's actual requirements

In this scenario, the DynamoDB configuration is syntactically correct - "N" (Number) is a valid type for a DynamoDB attribute according to the AWS provider schema. The fact that your application actually stores customer_id as a string is a business logic requirement that Terraform has no way of knowing. This is a semantic error, not a syntactic or structural one.

The second answer is incorrect because while validate does check against provider schemas, the schema only ensures valid DynamoDB attribute types (S, N, B) are used - not whether you've chosen the correct type for your application's data.

The third answer is incorrect because terraform validate explicitly does NOT connect to AWS or any remote services. It performs only local validation checks.

The fourth answer is incorrect because terraform validate does not evaluate runtime conditions or cross-reference application data formats. It cannot understand what data format your application uses.

Question 3

When terraform init encounters a module block with a registry source that includes version constraints, which specific file does Terraform consult first to determine if cached modules satisfy the declared requirements?

Correct Answer: The .terraform/modules/modules.json file which tracks installed module metadata and source locations

When terraform init runs and encounters module blocks, Terraform consults the .terraform/modules/modules.json file to determine which modules are already installed and their metadata. This JSON file acts as a manifest that tracks:

  • The source locations of installed modules
  • The local paths where modules are cached
  • Version information for registry modules
  • The mapping between module block names and their installed locations

Terraform uses this file to check if existing cached modules satisfy the version constraints specified in the configuration before deciding whether to download new versions.

The .terraform.lock.hcl file is specifically for provider version locking, not module version tracking. While it does record provider checksums and version selections, modules are not tracked in this dependency lock file.

The terraform.tfstate file contains the state of managed infrastructure resources, not module installation metadata. It tracks the actual resources that have been created, not the modules used to define them.

The .terraform/modules/.cache file does not exist as a standard Terraform file. Terraform does not maintain a separate cache file with cryptographic hashes for modules in this manner. The modules.json file serves as the primary tracking mechanism for module installations.

More Core Terraform Workflow questions
507 questions (total)
Start 100 question test