Visit here for our full HashiCorp Terraform Associate 003 exam dumps and practice test questions.
QUESTION 21:
What is the main purpose of using the local backend in Terraform?
ANSWER:
A) To store the Terraform state file on the local filesystem for single-user workflows
B) To enable collaborative state locking for teams
C) To enforce remote execution policies
D) To automatically synchronize state across multiple machines
EXPLANATION:
The local backend is the simplest backend type provided by Terraform. Its primary purpose is to store the Terraform state file directly on the local filesystem rather than on a remote backend or a centralized storage system. This makes the local backend best suited for single-user workflows, small projects, or testing environments where collaboration is not required. When using the local backend, Terraform saves the state in a file named terraform.tfstate within the working directory, unless otherwise configured. The local backend offers minimal features compared to remote backends. Because the file is stored locally, it lacks built-in encryption, versioning, remote locking, or team-based access control. This places the responsibility of securing, backing up, and managing the file entirely on the individual practitioner.
While the local backend is simple, it is not appropriate for collaborative environments. When multiple users attempt to work against the same configuration using a shared filesystem without state locking, they risk corrupting the state or overwriting each other’s changes. This is why teams commonly use remote backends such as Terraform Cloud, S3 with DynamoDB locking, Azure Blob Storage, or GCS. These remote backends provide essential collaboration features like locking, durable storage, and access control.
Option B is incorrect because the local backend does not support state locking. Option C is incorrect because the local backend does not enforce policies; policy enforcement occurs in remote environments such as Terraform Cloud with Sentinel or OPA integration. Option D is incorrect because the local backend does not synchronize state across machines. Instead, each local user has their own isolated state unless they manually share the file.
Therefore, option A is correct. The local backend exists to store Terraform state on the local filesystem for single-user workflows, testing, and simple infrastructure experiments.
QUESTION 22:
What is the purpose of the terraform graph command?
ANSWER:
A) To generate a visual representation of Terraform’s resource dependency graph
B) To check state consistency
C) To import resources into the state
D) To validate variable definitions
EXPLANATION:
The terraform graph command exists to help practitioners visualize how Terraform interprets resource relationships and dependencies. Terraform automatically builds a dependency graph whenever configurations are processed. This graph defines the order in which Terraform evaluates, creates, updates, and destroys resources. Understanding this graph is essential when working with large or complex infrastructures because it ensures that resources are provisioned in the correct order based on dependencies such as attribute references or explicit depends_on settings.
The terraform graph command outputs the dependency graph in DOT language format. This format is compatible with visualization tools such as Graphviz. By converting the DOT output into an image or diagram, practitioners can analyze the resource relationships and debug unexpected behaviors. For example, if Terraform appears to process resources out of order or fails due to dependency cycles, terraform graph can reveal hidden or unintended connections. This is especially valuable when modules, dynamic blocks, and complex relationships are involved.
Option B is incorrect because state consistency is checked through terraform plan or manual state inspections, not terraform graph. Option C is incorrect because importing resources is handled by terraform import. Option D is incorrect because terraform validate ensures variable definitions are syntactically correct.
Therefore, option A is correct. The terraform graph command generates a visual representation of the resource dependency graph, which helps practitioners understand and troubleshoot resource relationships.
QUESTION 23:
What is the purpose of the sensitive argument in Terraform variable definitions?
ANSWER:
A) To prevent Terraform from displaying variable values in the CLI output
B) To encrypt variables in the state file
C) To automatically rotate secrets
D) To store secrets externally without state tracking
EXPLANATION:
The sensitive argument in Terraform variable definitions is designed to prevent sensitive information from being exposed in CLI outputs, logs, and plan displays. When a variable is marked sensitive, Terraform masks its value and replaces it with a placeholder during output. This is essential for security practices because exposing secrets such as API keys, passwords, or database connection strings could compromise the environment. By marking a variable sensitive, Terraform ensures that this data is not shown directly in plain text.
However, it is important to clarify that the sensitive argument does not encrypt values in the state file. Sensitive variables still appear in the state file unless managed through backend encryption. Option B is therefore incorrect. Sensitive arguments only affect display behavior and do not alter how the state stores values.
Option C is incorrect because Terraform does not handle secret rotation automatically; secret rotation must occur through external tools or automation pipelines. Option D is incorrect because Terraform still stores sensitive variable values in state, even when marked sensitive. Storing secrets externally, such as in Vault or AWS Secrets Manager, is a separate practice that Terraform can integrate with but does not enforce through the sensitive argument.
Thus, option A is correct. The sensitive argument prevents Terraform from displaying variable values in outputs and logs, improving operational security.
QUESTION 24:
What is a key benefit of using remote execution in Terraform Cloud?
ANSWER:
A) Infrastructure changes run on Terraform Cloud rather than on local machines
B) Local state files are automatically deleted
C) Terraform no longer requires providers
D) Variable definitions become optional
EXPLANATION:
Remote execution in Terraform Cloud transitions the responsibility for running terraform plan and terraform apply operations from the local user’s machine to Terraform Cloud’s managed environment. This provides numerous benefits in terms of security, consistency, compliance, and collaboration. When using remote execution, Terraform Cloud performs the runs, stores logs, manages state, handles locking, and ensures that infrastructure deployments happen in a standardized environment. This reduces dependency on a practitioner’s local configuration and eliminates problems arising from inconsistent local versions, credentials, or operating system setups.
Another major advantage is the separation of duties. Developers can trigger Terraform runs without needing direct access to production credentials. Terraform Cloud stores sensitive credentials securely and executes plans on behalf of the user. This eliminates the need for distributing credentials across local machines. Additionally, remote execution provides full audit trails, saving run history, logs, and policy evaluation results for compliance and organizational governance.
Option B is incorrect because Terraform Cloud does not delete local state files unless configured to migrate state. Option C is incorrect because providers are always required in Terraform; remote execution simply manages them remotely. Option D is incorrect because variables remain essential.
Thus, option A is correct. Remote execution ensures that Terraform runs occur in a centralized, secure, and consistent environment rather than relying on local machine environments.
QUESTION 25:
Why is version control considered a best practice for managing Terraform configurations?
ANSWER:
A) It tracks changes to infrastructure code and supports collaborative workflows
B) It eliminates the need for state files
C) It allows apply operations without plan
D) It prevents Terraform from using providers
EXPLANATION:
Version control is fundamental to infrastructure as code because it provides a structured and traceable history of changes made to Terraform configuration files. When configurations are stored in a version control system such as Git, teams can track who modified which resources, when changes occurred, and why they were implemented. This is critical for auditing, reviewing changes, and maintaining accountability. It also provides an easy method to roll back to previous versions of infrastructure definitions if errors or misconfigurations occur.
Version control also enables collaborative workflows. Multiple users can work on different branches, submit pull requests, and review changes before merging them into shared environments. This allows organizations to enforce code reviews, implement automated testing pipelines, run terraform plan checks during CI, and maintain consistent governance across the team.
Additionally, version control supports automation by integrating with CI/CD pipelines. Automated triggers can run terraform plan or terraform apply when changes are pushed to specific branches. This aligns Terraform workflows with DevOps best practices.
Option B is incorrect because version control does not eliminate the need for state files. Option C is incorrect because apply should always follow plan, and version control does not change that behavior. Option D is incorrect because provider usage is controlled through configuration and backend settings, not version control.
Thus, option A is correct. Version control supports traceability, collaboration, and structured change management, making it a core best practice in Terraform workflows.
QUESTION 26:
What is the main advantage of using Terraform provisioning with cloud-init or user data scripts?
ANSWER:
A) It allows initialization of compute resources during creation without modifying Terraform state
B) It forces Terraform to manage OS-level configuration continuously
C) It removes the need to define variables
D) It prevents resources from being replaced when configuration changes
EXPLANATION:
The primary advantage of using Terraform provisioning with cloud-init or user data scripts is that it enables practitioners to initialize compute resources at creation time without continuously managing operating system–level configuration through Terraform. Cloud-init and user data integrate deeply with cloud providers, allowing instance-level setup such as installing packages, writing configuration files, setting environment variables, creating users, downloading application code, or preparing disks. All these tasks occur during the instance boot process, which is separate from Terraform’s lifecycle. Terraform simply delivers the initialization script, and the cloud platform applies it automatically.
Cloud-init and user data are ideal because Terraform is an infrastructure automation tool, not a configuration management system. Terraform does not track changes inside machines, so using these mechanisms ensures that initialization happens deterministically without causing Terraform state drift. Another advantage is immutability. If cloud-init or user data changes, Terraform often requires creating a new instance rather than modifying an existing one. This aligns with immutable infrastructure principles—ensuring that each instance is built cleanly and predictably.
This also prevents Terraform from becoming overloaded with responsibilities. OS-level changes should not be managed by Terraform because they do not fit Terraform’s model of predictable, declared infrastructure. Tools like Ansible or Chef manage configuration drift; Terraform handles provisioning.
Option B is incorrect because Terraform never continuously manages OS-level configuration. Option C has no relation to variable definitions. Option D is incorrect because user data modifications often do cause replacements.
Thus, option A is correct.
QUESTION 27:
What is one benefit of storing Terraform configuration files in a remote version control repository like GitHub or GitLab?
ANSWER:
A) It facilitates collaboration, auditing, and controlled change management for infrastructure code
B) It automatically encrypts all Terraform variables
C) It removes the need for a backend
D) It forces Terraform to run plans locally only
EXPLANATION:
Storing Terraform configuration files in a remote version control repository is considered an industry best practice because it brings structure, transparency, and accountability to infrastructure-as-code workflows. Version control systems provide an immutable history of all changes, including who made them, why they were made, and when they occurred. This is critical for auditing and compliance purposes.
Collaboration is another major benefit. When Terraform configurations live in a centralized repository, multiple engineers can submit changes through pull requests or merge requests. These changes undergo review, testing, and automated validation before being merged. This helps ensure that mistakes or misconfigurations do not reach critical environments like production.
Version control integrates naturally with CI/CD pipelines, allowing automated terraform validate, terraform fmt, or terraform plan checks. Teams can enforce policies ensuring infrastructure changes follow review processes and approval workflows.
Option B is incorrect because version control does not encrypt variables. Option C is incorrect because a backend remains necessary for state. Option D is incorrect because version control does not force local execution; Terraform Cloud supports remote execution tied to VCS triggers.
Thus, option A is correct.
QUESTION 28:
Why is it recommended to use terraform destroy only in non-production or controlled environments?
ANSWER:
A) Because terraform destroy removes all resources in the configuration, which can cause irreversible outages
B) Because terraform destroy automatically reinitializes backends
C) Because terraform destroy encrypts state files
D) Because terraform destroy only works if variables are not defined
EXPLANATION:
terraform destroy is an extremely powerful command that performs complete destruction of all infrastructure resources tracked within the current Terraform state. This includes networks, compute instances, databases, storage buckets, IAM roles, and any dependent components. Running destroy in production environments without strict governance risks catastrophic failures, including service outages, permanent data loss, and the disruption of mission-critical systems.
In production, infrastructure should only be deleted under highly controlled circumstances, following peer review, appropriate approval workflows, and a clear understanding of downstream effects. Many organizations deliberately restrict destroy permissions using IAM rules, Terraform Cloud workspace restrictions, or policy-as-code systems. Destroy is most appropriately used in ephemeral environments—such as staging, QA, temporary test environments, or automated deployment sandboxes—where tearing down infrastructure is safe and expected.
Option B is incorrect because destroy does not reinitialize backends. Option C is incorrect because destroy does not encrypt state. Option D is incorrect because destroy works regardless of variable definition.
Thus, option A is correct.
QUESTION 29:
What is the main benefit of using workspace-specific variables in Terraform Cloud?
ANSWER:
A) They allow different environments to use different variable values without modifying configuration code
B) They force Terraform to ignore variable types
C) They eliminate the need for remote backends
D) They prevent drift by blocking manual changes
EXPLANATION:
Workspace-specific variables allow Terraform Cloud users to define different values for the same variables based on the workspace being used. This is highly useful when a single Terraform configuration deploys multiple environments—such as dev, QA, staging, and production—where each environment requires different instance sizes, network subnets, scaling parameters, or credentials.
Using workspace-specific variables means the underlying Terraform code remains identical. This improves maintainability because teams do not need separate configuration files or branches for each environment. Instead, the variables injected into the workspace distinguish each environment.
This approach improves security as well. Sensitive environment-specific parameters such as tokens, database passwords, or API keys can be stored securely in Terraform Cloud’s variable management interface, hidden from logs and plan output. Workspace variable separation also simplifies governance by enforcing authority boundaries between development and production teams.
Option B is incorrect because type enforcement still applies. Option C is incorrect because backend choice is independent of variable management. Option D is incorrect because variables do not prevent drift; configuration discipline does.
Thus, option A is correct.
QUESTION 30:
What is the main purpose of using terraform login with Terraform Cloud?
ANSWER:
A) It authenticates the local CLI with Terraform Cloud to allow remote operations and access to state
B) It installs all provider plugins automatically
C) It initializes the backend without configuration
D) It deletes unused state files in Terraform Cloud
EXPLANATION:
terraform login enables secure authentication between the user’s local Terraform CLI and Terraform Cloud. When this command is executed, Terraform prompts the user to generate or provide an API token. That token is then stored in a credentials file on the local machine. With that authentication established, the Terraform CLI can access remote workspaces, read or write remote state, trigger remote plans and applies, and interact with Terraform Cloud features such as variables, state history, and policy enforcement.
Authenticating through terraform login ensures secure communications with Terraform Cloud without requiring users to manually configure headers or embed credentials in configuration files. This separation of secrets supports best practices in secure automation and prevents accidental leaks.
Option B is incorrect because provider plugins are installed via terraform init. Option C is incorrect because even after login, backends still require proper configuration. Option D is incorrect because terraform login does not remove or modify state.
Therefore, the correct answer is option A.
QUESTION 31:
What is the purpose of using terraform workspace new when working with multiple environments?
ANSWER:
A) It creates a separate state file for an isolated environment using the same configuration
B) It copies provider plugins into a new directory
C) It forces Terraform to ignore existing state files
D) It automatically provisions a new cloud environment
EXPLANATION:
The terraform workspace new command is a core component of Terraform’s workspace mechanism, which is designed to allow separate instances of Terraform state to exist within the same configuration directory. When practitioners manage multiple environments such as development, staging, or production, they often want to reuse the same infrastructure code but ensure that the resources for each environment are tracked separately. This is where terraform workspace new becomes valuable. When executed, this command creates a new workspace, meaning it establishes a new, isolated state file under the same configuration folder. Terraform then uses this workspace-specific state file to track all resources associated with that workspace.
This isolation is crucial because it prevents conflicts between environments. If state is shared between environments unintentionally, Terraform may treat resources belonging to one environment as if they belong to another. This can lead to incorrect updates, accidental deletions, or destructive behavior. By creating a workspace, the practitioner ensures that environment boundaries are preserved even though all environments use the same underlying .tf configuration code.
It is important to understand that terraform workspace new does not automatically provision infrastructure or replicate resources. Rather, it simply creates a new blank state. After creating the workspace, practitioners must run terraform apply to provision infrastructure for that environment. Because the state starts empty, Terraform interprets the configuration as needing all resources created.
Option B is incorrect because provider plugins are not copied during workspace creation; they are installed through terraform init. Option C is incorrect because workspaces do not force Terraform to ignore existing state files; each workspace has its own state file, but existing ones remain intact. Option D is incorrect because creating a workspace alone does not provision any infrastructure; it merely prepares a new state context.
Workspaces are especially useful for lightweight environment separation but should not be confused with more robust environment management approaches used in production, such as directory-based separation, multiple repositories, or multiple backends. While workspaces offer convenience, they are best for managing simple environments rather than large-scale enterprise infrastructure.
Thus, option A is correct. terraform workspace new creates isolated state files using the same configuration, allowing structured, environment-based resource management.
QUESTION 32:
What is one advantage of using the count meta-argument in Terraform resources?
ANSWER:
A) It enables creating multiple instances of a resource dynamically using a single resource block
B) It converts resources into data sources
C) It eliminates the need for modules
D) It forces resources to always be recreated on every apply
EXPLANATION:
The count meta-argument is one of Terraform’s foundational mechanisms for dynamic resource creation. When assigned a value, count determines how many instances of a resource should be created. This allows a single resource block to create multiple resources based on input variables, local values, or computed expressions. For example, if count is set to 3 for an AWS instance resource, Terraform will create three separate instances indexed as count.index values 0, 1, and 2. This significantly reduces configuration duplication because practitioners do not need to manually write multiple resource blocks performing the same function.
Using count improves scalability and maintainability. For example, if a team needs to deploy a variable number of compute instances, security group rules, subnets, or IAM resources, count allows them to scale up or down simply by changing a numeric variable. This contributes to immutable infrastructure patterns and predictable deployments.
Another strength is conditional resource creation. Practitioners can set count to 0 to disable a resource entirely without removing the resource block from code. This is helpful when deploying optional resources based on environment types. For example, dev environments may require fewer resources than production. Through count-based conditions, Terraform can deploy or skip resources programmatically.
Option B is incorrect because count has nothing to do with converting resources into data sources; these are separate block types. Option C is incorrect because count does not eliminate the need for modules. Modules are required for structural reuse and organization and serve a broader architectural role. Option D is incorrect because count does not force resources to always be recreated; Terraform only recreates resources when count changes in ways that necessitate replacement.
Therefore, the correct answer is option A. Using the count meta-argument allows practitioners to dynamically create multiple resource instances from a single resource block, greatly enhancing flexibility.
QUESTION 33:
Why is the terraform providers command useful when troubleshooting configuration issues?
ANSWER:
A) It lists all providers used in the configuration and shows how they are sourced and required
B) It downloads all available providers for every cloud platform
C) It recreates provider configurations automatically
D) It updates provider credentials stored in the backend
EXPLANATION:
The terraform providers command offers deep insight into which providers a Terraform configuration uses, how those providers are sourced, and whether any of them require or consume specific dependencies. This command is particularly useful during troubleshooting because provider-related issues are often the root cause of Terraform errors. Such errors may include version mismatches, improper namespace definitions, missing provider blocks, or module-level provider configurations behaving unexpectedly.
When terraform providers is executed, Terraform displays a comprehensive report of all providers referenced either directly in configurations or indirectly through modules. It shows provider aliases, module-provider relationships, and any overrides that may exist. This visibility is crucial for diagnosing scenarios where modules implicitly expect a provider configuration or where a provider is incorrectly sourced from an unintended registry namespace.
Option B is incorrect because terraform providers does not download providers; terraform init performs plugin installation. Option C is incorrect because Terraform does not automatically recreate provider configurations; they must be defined manually in configuration files. Option D is incorrect because provider credentials are not stored or updated through terraform providers; they are managed via environment variables, shared credentials files, or CLI authentication.
Therefore, option A best describes the usefulness of terraform providers. It gives practitioners a clear view of provider usage, making troubleshooting easier and reducing configuration errors.
QUESTION 34:
How does Terraform handle resource drift when managed infrastructure is changed outside of Terraform?
ANSWER:
A) Terraform detects differences during plan and proposes actions to reconcile them
B) Terraform permanently ignores external changes
C) Terraform immediately applies corrective changes without user approval
D) Terraform deletes the affected resources automatically
EXPLANATION:
Resource drift occurs when infrastructure that Terraform manages is modified outside of Terraform’s control, such as changes made manually through cloud consoles or external automation. Terraform is designed to detect and reconcile such drift, ensuring that infrastructure remains consistent with the declared configuration.
When a practitioner runs terraform plan, Terraform compares the real-world infrastructure state (fetched through provider APIs) against the expected resource definitions stored in the state file. If any differences are found—such as altered tags, modified instance types, security group changes, or network modifications—Terraform highlights these differences in the plan output.
Terraform never immediately applies corrective actions. Instead, it surfaces the proposed changes and waits for user confirmation during terraform apply. This ensures that practitioners retain control and have full visibility into reconciliations before action is taken.
Option B is incorrect because Terraform does not permanently ignore drift; drift is a central concept of its infrastructure-as-code model. Option C is incorrect because Terraform never applies changes without approval unless auto-approve is explicitly used. Option D is incorrect because Terraform does not delete resources solely because of drift unless the configuration specifically indicates deletion.
The correct answer is option A. Terraform detects drift during the plan phase and provides a preview of actions required to align infrastructure back with configuration. This drift detection mechanism is essential for maintaining predictable, consistent infrastructure.
QUESTION 35:
Why is managing Terraform state securely important for long-term infrastructure stability?
ANSWER:
A) Because state contains critical metadata needed for Terraform to safely manage infrastructure
B) Because Terraform cannot run without the state being publicly accessible
C) Because state automatically regenerates on every apply
D) Because state prevents provider plugin downloads
EXPLANATION:
Terraform state is one of the most sensitive and important components of Terraform’s architecture. It holds essential metadata about all managed resources, including resource IDs, dependency relationships, and attributes required to plan or apply changes safely. Without accurate and secure state, Terraform cannot function predictably. If state becomes corrupted, lost, or tampered with, Terraform may attempt destructive operations, fail to detect existing resources, or misalign configurations with real world environments. This threatens infrastructure stability.
Security is also critical because Terraform state may contain sensitive information such as resource identifiers, networking details, or passwords stored inside resource attributes. While Terraform allows sensitive variables to be masked, some providers still store sensitive outputs in state. If state is stored insecurely, unauthorized individuals may gain insight into system architecture or sensitive internal data.
State must also be protected against concurrent write operations. Without state locking—provided through remote backends or Terraform Cloud—multiple users could modify state simultaneously, leading to race conditions and corruption. This is why storing state locally is risky in team environments, and why secure remote backends are strongly recommended.
Option B is incorrect because state should never be publicly accessible. Option C is incorrect because state does not regenerate; it persists until modified. Option D is inaccurate because state has no role in provider downloads.
Thus, the correct answer is option A. Securely managing state ensures consistency, prevents corruption, protects sensitive metadata, and supports long-term infrastructure reliability.
QUESTION 36:
What is the primary benefit of using the for_each meta-argument instead of count in Terraform resources?
ANSWER:
A) It allows creation of resources mapped to unique keys rather than numeric indices
B) It automatically secures state files
C) It prevents all resource replacement operations
D) It eliminates the need for variables altogether
EXPLANATION:
The for_each meta-argument in Terraform provides a major advantage over count by associating resource instances with meaningful keys rather than numerical indices. This allows practitioners to create resources based on maps or sets, where each resource instance corresponds to a stable key. This stability results in fewer unnecessary replacements because keys do not shift when new elements are added, unlike with count, where inserting or reordering items in a list may force resource recreation.
Another benefit of for_each is clarity. Instead of managing ambiguous numerical indexes, using meaningful keys such as usernames, subnet names, or rule identifiers makes both the configuration and state file easier to understand. This improves debugging, team collaboration, and the predictability of Terraform operations. With for_each, Terraform can precisely update or replace only the specific resource associated with a given key.
Option B is incorrect because for_each does not secure state. Option C is incorrect because replacement behavior still depends on configuration changes. Option D is incorrect because variables remain important for customization. The correct answer is A.
QUESTION 37:
What is the purpose of the terraform init command when working with modules?
ANSWER:
A) It downloads and installs modules referenced in the configuration
B) It applies all module resources immediately
C) It destroys unused modules
D) It converts modules into data sources
EXPLANATION:
When working with Terraform, modules are an essential way to structure and reuse infrastructure code. Before Terraform can use any modules referenced in a configuration, it must first set them up properly, and this is where the initialization process comes in. The first option refers to the main purpose of terraform init: it downloads and installs modules referenced in the configuration. When you declare a module from a registry, a Git repository, or a local path, Terraform retrieves the module’s source code and places it into the local working directory. This ensures that all module components are available and ready for planning or applying. Without this initialization step, Terraform would not know where to find the modules or how to use them.
The second option, which states that initialization applies all module resources immediately, is incorrect. The terraform init command never applies resources or makes changes to infrastructure. It strictly prepares the working directory by setting up backends, downloading providers, and installing modules. The apply phase happens only when the user explicitly runs terraform apply, which triggers resource creation or modification after showing a plan.
Option C suggests that initialization destroys unused modules. Terraform does not delete or destroy modules during initialization. Removing a module from the configuration may cause Terraform to mark its corresponding resources for destruction during an apply, but this is unrelated to the init process itself. Init simply handles setup, not lifecycle operations.
Option D claims that initialization converts modules into data sources. This is also incorrect. Modules and data sources serve different purposes: modules group resources for reuse, while data sources fetch external information. Terraform does not convert one into the other under any circumstance.
Taken together, these explanations show that the core purpose of terraform init is to prepare the working environment by fetching and configuring required modules and providers, not altering infrastructure.
The correct answer is A.
QUESTION 38:
Why is it important to define version constraints for providers in Terraform?
ANSWER:
A) To ensure consistent provider behavior and avoid unexpected breaking changes
B) To force automatic provider upgrades on every init
C) To disable remote backend functionality
D) To reduce the size of plan outputs
EXPLANATION:
Terraform relies on providers to interact with various cloud platforms and services. Managing provider versions is an important part of ensuring stable and predictable infrastructure behavior. The first option highlights the primary reason for specifying provider versions: to ensure consistent provider behavior and avoid unexpected breaking changes. Providers evolve over time, introducing new features, modifying existing ones, or removing outdated behaviors. By locking a version or defining version constraints, users prevent Terraform from unexpectedly switching to a newer provider version that might behave differently, potentially leading to errors, incompatible configurations, or unintended infrastructure changes. This stability is essential for production environments, team collaboration, and long-term project maintenance.
Option B suggests forcing automatic provider upgrades on every initialization. Terraform does not automatically upgrade providers unless the configuration explicitly allows it. In fact, provider version constraints are the opposite: they intentionally prevent unplanned upgrades. Without version constraints, Terraform may fetch newer versions, but this is not guaranteed, nor is it recommended in workflows where reliability and repeatability matter. Automatic upgrades could introduce breaking changes without warning, which is why Terraform encourages explicit version control instead.
Option C claims that provider version settings disable remote backend functionality. This is incorrect because backend configuration and provider versioning are separate concerns. Remote backends handle state storage, locks, and remote execution, while providers handle resource interactions. Configuring one does not hinder the other, and Terraform treats them independently.
Option D suggests that specifying provider versions reduces the size of plan outputs. This is not the purpose of version constraints. Plan output size is determined by the number and complexity of resources, not the provider version. Versioning ensures stability, while plan output reflects infrastructure changes.
Collectively, these options help clarify that provider version constraints primarily serve to maintain consistency and prevent unexpected behavior across different Terraform runs.
The correct answer is A.
QUESTION 39:
What does Terraform do when a resource block is removed from configuration but still exists in the state file?
ANSWER:
A) It marks the resource for destruction in the next terraform apply
B) It permanently ignores the resource
C) It automatically imports the resource again
D) It locks the state file until the resource is manually removed
EXPLANATION:
When working with Terraform, understanding what happens when a resource is removed or managed within the state file is essential. If a resource is marked for deletion within Terraform, it generally means the configuration no longer defines that resource, yet it still exists in the remote environment and in Terraform’s state. In such cases, Terraform interprets this as a discrepancy between configuration and real-world infrastructure.
Option A indicates that the resource is marked for destruction in the next terraform apply. This is the typical behavior when the resource is removed from the configuration file but still exists in the state. Terraform will plan to destroy the resource to bring the real infrastructure back into alignment with the declared configuration. This ensures that the infrastructure matches exactly what is written in code, following Terraform’s declarative model.
Option B suggests that Terraform permanently ignores the resource. This is not the default behavior; Terraform does not automatically ignore resources unless a user explicitly tells it to, such as by using lifecycle rules like ignore_changes, or by removing the resource from the state manually with terraform state rm. Without such manual action, Terraform will not permanently ignore anything simply because it is missing from configuration.
Option C implies that Terraform automatically imports the resource again. Terraform never automatically imports resources. Importing must be done manually using the terraform import command if you want Terraform to regain control of an existing resource. Terraform will not assume ownership of external infrastructure on its own, as this could create significant risk or unintended side effects.
Option D proposes that Terraform locks the state file until the resource is manually removed. Terraform state locking occurs only during operations like plan and apply to prevent concurrent modifications, but losing a resource from configuration does not trigger a permanent lock. The state file remains usable, and it is up to the operator to either remove the resource from the state, re-import it, or update the configuration.
Together, these options illustrate important differences between how Terraform manages lifecycle actions, state synchronization, and resource control.
The correct answer is A.
QUESTION 40:
What is the main reason to use terraform output after running terraform apply?
ANSWER:
A) To display resource attributes defined as output values in the configuration
B) To show provider logs
C) To rotate Terraform Cloud tokens
D) To validate internal module variables
EXPLANATION:
Terraform provides several important features and operational capabilities that assist users in managing infrastructure safely, efficiently, and predictably. The first of these involves displaying resource attributes that are defined as output values within a configuration. When a Terraform configuration is applied, certain details about the created resources become important for operators or other systems that rely on them. By defining output values, users can expose attributes such as IP addresses, resource IDs, load balancer endpoints, or any other relevant information. The terraform output command then allows these values to be viewed easily, making them useful for automation, integration, or simply for reference during troubleshooting or deployment processes.
In addition to handling outputs, Terraform also provides the ability to show provider logs. Providers act as the bridge between Terraform and external platforms like AWS, Azure, or Google Cloud. When something goes wrong or a resource behaves unexpectedly, provider logs help uncover what occurred behind the scenes. By enabling logging through environment variables like TF_LOG or using more detailed debug settings, users can observe API calls, retries, validation errors, and other activity. This visibility is essential when diagnosing complex infrastructure issues and ensures that interactions with cloud APIs are transparent and understandable.
Another important task involves rotating Terraform Cloud tokens. These tokens authenticate users and systems that interact with Terraform Cloud. Since long-lived tokens can pose security risks, regular rotation helps maintain strong security practices by invalidating old credentials and issuing new ones. This minimizes exposure from accidental leaks, enforces compliance requirements, and ensures that only authorized parties can access Terraform Cloud workspaces or API functions.
Lastly, Terraform supports validation of internal module variables. Modules often define variables to configure behavior, and ensuring that these variables contain valid or expected values is essential. Validation blocks allow module authors to enforce rules such as value ranges, formatting, and conditional requirements. This prevents misconfigurations before they reach the planning or applying stage, reducing errors and promoting consistency across environments.
Together, these capabilities enhance Terraform’s reliability, security, and usability.
Therefore, A is correct.
