TF-004 Understand Terraform's purpose Practice Question
Your organization manages a multi-cloud infrastructure using Terraform. The infrastructure includes an AWS VPC with subnets and EC2 instances, and an Azure resource group with virtual networks and VMs. The Terraform configuration is stored in a Git repository, and state is stored in an S3 bucket with DynamoDB locking. Recently, a developer updated the configuration to add a new security group rule in AWS, but after running `terraform apply`, the rule was not created. The developer verified that the configuration file contains the rule. Additionally, the developer noticed that the state file shows the security group exists but without the new rule. The developer ran `terraform plan` again, and it shows that the rule will be created. However, when applying, it fails with a 'timeout' error. The operations team suspects network connectivity issues to the S3 backend. What is the best course of action to resolve this issue?
⚠ Common exam trap
HashiCorp often tests the distinction between provider-level timeouts (for API calls to cloud providers) and backend-level timeouts (for state storage), leading candidates to incorrectly choose increasing provider timeouts when the issue is actually with backend connectivity.
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
✓
Migrate the state backend to Terraform Cloud, and use remote operations for applies.
The timeout error when applying, despite a successful plan, indicates that the issue is not with the configuration or state locking but with the network connectivity to the S3 backend during the apply operation. Migrating to Terraform Cloud with remote operations moves the execution environment to Terraform Cloud's infrastructure, which has reliable connectivity to the S3 backend, bypassing the local network issues. This resolves the timeout without altering the configuration or compromising state integrity.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Run `terraform init` again to reinitialize the backend.
Why it's wrong here
Running `terraform init` again primarily configures the backend, downloads providers, and initializes modules. While it establishes the backend connection, it does not inherently resolve underlying network connectivity issues or transient timeouts between the local machine and the remote state backend. If the network path itself is unstable or congested, re-running `init` will likely encounter the same timeout, as it is not a diagnostic or remediation tool for network infrastructure problems.
- ✓
Migrate the state backend to Terraform Cloud, and use remote operations for applies.
Why this is correct
Migrating the state backend to Terraform Cloud and utilizing remote operations offloads the execution of `terraform apply` from the local machine to HashiCorp's managed infrastructure. This approach effectively bypasses local network instability, proxy configurations, or firewall restrictions that might be causing timeouts when accessing the state backend or provider APIs from the local environment. Terraform Cloud's robust and highly available execution environment ensures reliable communication with the state backend and target cloud providers.
- ✗
Increase the timeout value in the Terraform provider configuration.
Why it's wrong here
Increasing the timeout value within a Terraform *provider* configuration, such as for AWS or Azure, only affects the duration Terraform waits for responses from the *cloud provider's API* during resource creation or modification. This setting has no impact on the connectivity or timeout issues experienced when Terraform attempts to communicate with its own *state backend*, which is a separate network operation. The problem lies in accessing the state file, not in the subsequent interaction with cloud resources.
- ✗
Disable state locking by removing the DynamoDB table reference.
Why it's wrong here
Disabling state locking by removing the DynamoDB table reference, which is typically used for robust locking with S3 backends, would indeed bypass any locking-related timeouts. However, this action introduces a critical risk of state corruption, especially in collaborative environments. Without state locking, multiple concurrent `terraform apply` operations could attempt to modify the state file simultaneously, leading to data loss, inconsistent infrastructure, or unrecoverable errors. It is a dangerous workaround that compromises state integrity.
Visual reference
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
One of 428 original TF-004 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.