Visit here for our full HashiCorp Terraform Associate exam dumps and practice test questions.
Question 196:
What is the purpose of the ignore_changes lifecycle argument?
A) To prevent Terraform from tracking resource changes
B) To instruct Terraform to ignore changes to specific attributes
C) To skip validation of resource configurations
D) To disable state file updates
Answer: B
Explanation:
The ignore_changes lifecycle argument instructs Terraform to ignore changes to specific resource attributes, preventing Terraform from attempting to revert those changes during subsequent apply operations. This is useful when certain resource attributes are modified outside of Terraform by automated processes, manual interventions, or the resource provider itself, and you want Terraform to manage the resource without constantly trying to reset those particular attributes to their configured values.
Common use cases for ignore_changes include ignoring tags that are automatically added by organizational policies, ignoring attributes that are modified by autoscaling or other automated systems, or ignoring values that change frequently and do not affect the resource’s primary function. For example, an EC2 instance might have tags added by a compliance system, or a database might have its maintenance window automatically adjusted. By using ignore_changes, you tell Terraform to manage the resource but leave specific attributes alone.
The ignore_changes argument accepts a list of attribute names that should be ignored. You can specify individual attributes like ignore_changes equals bracket tags bracket, or you can use all to ignore changes to all attributes with ignore_changes equals bracket all bracket. When using all, Terraform will still track the resource in state but will not attempt to update any of its attributes, effectively making the resource read-only from Terraform’s perspective.
It is important to use ignore_changes judiciously because overusing it can lead to configuration drift where the actual infrastructure diverges from what is defined in your Terraform code. This makes it harder to understand the true state of your infrastructure and can cause confusion for team members. The ignore_changes argument does not prevent tracking, skip validation, or disable state updates entirely. It specifically controls which attribute changes Terraform will attempt to reconcile during apply operations.
Question 197:
Which command validates the syntax and configuration of Terraform files?
A) terraform check
B) terraform validate
C) terraform test
D) terraform verify
Answer: B
Explanation:
The terraform validate command validates the syntax and internal consistency of Terraform configuration files. This command checks that your configuration is syntactically valid and internally consistent, verifying that resource blocks are properly structured, required arguments are provided, variable references are correct, and that the overall configuration follows Terraform’s language rules. Validation happens without accessing any remote services or state files, making it a fast operation suitable for CI/CD pipelines.
Running terraform validate is an important step in developing Terraform configurations because it catches many common errors early in the development process. The command checks for issues such as missing required arguments on resources, invalid attribute names, type mismatches in variable assignments, circular dependencies in resource relationships, and syntax errors in HCL. It also validates module calls to ensure required input variables are provided and that output references are valid.
The terraform validate command requires that the working directory be initialized with terraform init before it can run, because validation needs access to provider schema information to properly validate resource configurations. The schemas tell Terraform which arguments are required, which are optional, and what types are expected, allowing for thorough validation beyond just syntax checking. Without initialization, Terraform cannot perform comprehensive validation of provider-specific resources.
While terraform validate is excellent for catching configuration errors, it does not check whether your configuration will successfully create working infrastructure. It cannot validate credentials, quota limits, or whether requested resources are available in your target environment. These runtime issues are only discovered when you run terraform plan or terraform apply. There is no terraform check, terraform test, or terraform verify command in Terraform’s standard command set, though some organizations build custom testing frameworks around Terraform.
Question 198:
What is the difference between input variables and output values in Terraform?
A) Input variables pass data into modules, output values expose data from modules
B) They are the same thing with different names
C) Input variables are for providers, output values are for resources
D) Output values can only be used in the root module
Answer: A
Explanation:
Input variables pass data into modules, while output values expose data from modules. This distinction is fundamental to how Terraform modules work and how data flows through Terraform configurations. Input variables allow you to parameterize your configurations, making them reusable and flexible by accepting values from the calling module or from external sources. Output values allow modules to expose specific data to the calling module or to display information to users after infrastructure is created.
Input variables are defined using variable blocks and can have types, default values, descriptions, and validation rules. When you call a module, you provide values for its input variables, customizing the module’s behavior for your specific use case. For example, you might pass in different instance types, region names, or environment labels to the same module to create variations of infrastructure. Input variables can come from multiple sources including command-line flags, environment variables, variable files, or direct assignment in module blocks.
Output values are defined using output blocks and typically expose important resource attributes that other parts of your configuration need to reference or that users need to know. For example, a networking module might output VPC IDs and subnet IDs so that a compute module can place instances in the correct network. Output values from the root module are displayed to users after terraform apply completes, providing information like load balancer URLs, database endpoints, or IP addresses that are needed for accessing the infrastructure.
The relationship between input variables and output values enables modular, composable infrastructure code. You can chain modules together by passing output values from one module as input variables to another module. This creates a data flow through your infrastructure configuration. Input variables and output values are not the same, are not specific to providers versus resources, and output values can be used in any module including child modules, not just the root module.
Question 199:
What is the purpose of the create_before_destroy lifecycle argument?
A) To validate resources before destroying them
B) To create a new resource before destroying the old one during replacement
C) To create backups before destruction
D) To prevent accidental resource destruction
Answer: B
Explanation:
The create_before_destroy lifecycle argument instructs Terraform to create a new replacement resource before destroying the old one when a resource must be replaced. Normally, when Terraform determines that a resource cannot be updated in-place and must be replaced, it destroys the existing resource first and then creates the new one. However, this default behavior can cause downtime or service interruptions. Setting create_before_destroy to true reverses this order, minimizing downtime and ensuring continuity of service.
This lifecycle option is particularly important for resources that cannot tolerate downtime or that other resources depend on. For example, if you have a launch configuration for an auto-scaling group, you might need to create the new launch configuration before destroying the old one to prevent the auto-scaling group from losing its configuration. Similarly, security groups might need to exist before associated instances are created, requiring careful ordering during replacements.
When create_before_destroy is enabled, Terraform handles the replacement process carefully. It first creates the new resource with all its dependencies, verifies the creation was successful, updates any resources that reference the old resource to point to the new one, and only then destroys the old resource. This ensures a smooth transition with minimal risk of service disruption. However, it requires that you can temporarily have both resources existing simultaneously, which might have implications for naming, quotas, or costs.
There are some considerations when using create_before_destroy. Resources with unique naming constraints may need special handling since you cannot have two resources with the same name existing at once. You might need to use name prefixes or generated names. Also, if resources have dependencies, those dependencies might also need create_before_destroy to avoid conflicts. The option does not validate resources, create backups, or prevent destruction altogether, which are separate concerns addressed by other features.
Question 200:
Which Terraform command removes unused provider plugins from the .terraform directory?
A) terraform clean
B) terraform prune
C) terraform providers lock
D) None, Terraform does not automatically remove unused plugins
Answer: D
Explanation:
Terraform does not have a built-in command to automatically remove unused provider plugins from the .terraform directory. Once provider plugins are downloaded during terraform init, they remain in the .terraform directory even if you later remove the provider from your configuration or change version constraints. This behavior is intentional to avoid repeatedly downloading the same providers and to maintain a stable local environment.
If you want to clean up unused provider plugins, you must manually delete the .terraform directory and run terraform init again. This will download only the providers currently required by your configuration based on the required_providers block and any modules you are using. The manual deletion approach ensures you have explicit control over when providers are removed and gives you the opportunity to back up or review the directory contents if needed.
The .terraform directory serves as a local cache and working directory for Terraform operations. Besides provider plugins, it contains downloaded modules, backend configuration, and other metadata. Since these can all be regenerated by running terraform init, it is safe to delete the entire .terraform directory when you want a clean state. Some teams include scripts in their development workflows to periodically clean and reinitialize Terraform directories to save disk space or ensure a fresh environment.
There is no terraform clean or terraform prune command in Terraform’s standard command set. The terraform providers lock command is used to update the dependency lock file with provider checksums for additional platforms, not to remove unused providers. Understanding that the .terraform directory can be safely deleted and regenerated helps with troubleshooting plugin issues and managing disk space, particularly in environments with many Terraform projects or in CI/CD systems where clean builds are preferred.
Question 201:
What is a Terraform provisioner used for?
A) To configure providers in Terraform
B) To execute scripts or commands during resource creation or destruction
C) To provision new cloud accounts
D) To validate resource configurations
Answer: B
Explanation:
A Terraform provisioner is used to execute scripts or commands during resource creation or destruction. Provisioners allow you to run arbitrary commands or scripts on local machines or remote resources as part of the resource lifecycle. They are typically used for bootstrapping, configuration management tasks, or cleanup operations that cannot be accomplished through Terraform’s declarative resource definitions. Common provisioner types include local-exec for running commands on the machine running Terraform, remote-exec for running commands on remote resources, and file for copying files to remote resources.
Provisioners are defined within resource blocks and execute at specific points in the resource lifecycle. By default, provisioners run during resource creation after the resource has been successfully created. You can also configure provisioners to run during destruction by setting when equals destroy. Multiple provisioners can be defined on a single resource and will execute in the order they are defined. Each provisioner operates independently, and by default, if a provisioner fails, Terraform will mark the resource as tainted.
While provisioners provide flexibility for tasks that cannot be handled declaratively, Terraform documentation explicitly recommends using them as a last resort. Provisioners make Terraform configurations less predictable and harder to maintain because they introduce imperative operations into an otherwise declarative system. Whenever possible, you should prefer using native Terraform resources, cloud-init or user data for instance initialization, configuration management tools invoked separately, or custom providers instead of provisioners.
Common but discouraged use cases for provisioners include installing software on virtual machines, running configuration management tools, or executing initialization scripts. Better alternatives include using pre-configured machine images, leveraging cloud provider user data features, or separating configuration management from infrastructure provisioning. Provisioners do not configure Terraform providers, provision cloud accounts, or validate configurations, which are handled by different Terraform features and processes.
Question 202:
What does the terraform graph command do?
A) It creates performance graphs of Terraform operations
B) It generates a visual representation of the dependency graph
C) It displays resource cost graphs
D) It shows state file growth over time
Answer: B
Explanation:
The terraform graph command generates a visual representation of the dependency graph for your Terraform configuration. This command outputs the dependency relationships between resources in DOT format, which is a graph description language that can be rendered into visual diagrams using tools like Graphviz. The graph shows how resources depend on each other, helping you understand the relationships and order of operations in your infrastructure code.
The dependency graph is fundamental to how Terraform operates, determining the order in which resources are created, updated, or destroyed. By visualizing this graph, you can better understand complex configurations, debug dependency issues, identify circular dependencies, and optimize your infrastructure code. The graph includes nodes for resources, data sources, variables, outputs, and modules, with edges representing dependencies between them.
To use the terraform graph output, you typically pipe it to a visualization tool. A common workflow is terraform graph pipe dot dash Tpng dash o graph.png, which creates a PNG image of the dependency graph. You can generate graphs at different stages of Terraform operations using flags. The default graph shows the configuration without applying any operations, but you can use plan files to show the graph for specific apply operations.
The graph can become quite complex for large Terraform configurations with many resources and modules. While this complexity can make the graph harder to read, it also reveals the true intricacy of your infrastructure and the relationships Terraform manages. The terraform graph command does not create performance metrics, display costs, or track state file growth over time, which would require external tools or monitoring solutions. It specifically focuses on visualizing the logical dependency structure of your Terraform configuration.
Question 203:
Which type of Terraform variable constraint allows you to specify exactly which values are acceptable?
A) type
B) default
C) validation
D) description
Answer: C
Explanation:
The validation constraint within variable blocks allows you to specify exactly which values are acceptable for a variable using custom validation rules. Variable validation was introduced to provide fine-grained control over what values can be assigned to variables, enabling you to enforce business rules, naming conventions, or acceptable value ranges beyond what type constraints alone can provide. Validation rules use conditional expressions to check if values meet your requirements and provide custom error messages when they do not.
Variable validation blocks are defined within variable declarations and contain a condition expression that must evaluate to true for the value to be accepted, along with an error_message that is displayed when validation fails. For example, you might validate that an environment variable is one of dev, staging, or prod, or that an instance count is between specific numbers, or that a name follows a particular pattern. The condition can use any Terraform expression including functions, operators, and references to the variable being validated.
You can include multiple validation blocks for a single variable, allowing you to check different aspects of the value and provide specific error messages for each validation rule. All validation rules must pass for the variable value to be accepted. This enables complex validation logic while maintaining clear, specific error messages that guide users toward correct values. Validation happens before Terraform creates an execution plan, catching invalid values early.
The type constraint specifies the data type expected for a variable such as string, number, bool, list, or map, but it does not allow you to constrain specific values within that type. The default provides a fallback value when none is provided. The description provides documentation for the variable. Only the validation block with its condition and error_message structure allows you to define custom rules for acceptable values, making it the correct answer for constraining specific allowable values.
Question 204:
What is the purpose of the sensitive argument in Terraform output values?
A) To encrypt output values in the state file
B) To prevent output values from being displayed in CLI output
C) To validate output values before displaying them
D) To mark outputs that require special permissions
Answer: B
Explanation:
The sensitive argument in Terraform output values is used to prevent those values from being displayed in CLI output, protecting sensitive information from being exposed in logs, terminal history, or console output. When you mark an output as sensitive by setting sensitive equals true, Terraform will hide the value in the plan and apply output, showing only that the output is sensitive rather than displaying its actual value. This is important for outputs containing passwords, API keys, private keys, or other confidential information.
Marking outputs as sensitive provides a layer of protection against accidental exposure of secrets through command-line interfaces, CI/CD logs, or screen sharing during demonstrations. However, it is important to understand that the sensitive flag only affects display behavior in Terraform’s output. The actual values are still stored in the state file in plain text, and they are still accessible through the terraform output command when called with the JSON flag or when specifically requesting that output value.
The sensitive flag is particularly useful when outputs contain credentials or other secrets generated or retrieved during Terraform operations. For example, if you create a database and Terraform generates a random password for it, marking the password output as sensitive prevents it from appearing in apply logs. However, users who need the password can still retrieve it using terraform output password, which will display the value since they explicitly requested it.
For comprehensive secrets management, you should combine the sensitive output flag with other security measures such as encrypting state files at rest, restricting access to state files using backend authentication and authorization, using secret management systems to store sensitive values, and ensuring CI/CD logs are properly secured. The sensitive argument does not encrypt values in state, validate outputs, or implement access controls, which are separate security concerns requiring additional measures.
Question 205:
Which meta-argument specifies an alternate provider configuration for a resource?
A) depends_on
B) provider
C) alias
D) source
Answer: B
Explanation:
The provider meta-argument specifies an alternate provider configuration for a resource. By default, Terraform associates each resource with a provider based on the resource type prefix. For example, aws_instance resources automatically use the aws provider. However, when you have multiple configurations of the same provider, such as for different regions or accounts, you use the provider meta-argument to explicitly specify which provider configuration a resource should use.
Multiple provider configurations are defined using the alias argument within provider blocks. For example, you might have one AWS provider configuration for us-east-1 with alias equals east and another for us-west-2 with alias equals west. To use a specific aliased provider configuration with a resource, you set the provider meta-argument to provider_name.alias, such as provider equals aws.west. This tells Terraform to use the west configuration of the AWS provider for that particular resource.
This capability is essential for multi-region deployments, multi-account architectures, or scenarios where you need different provider settings for different resources. Common use cases include deploying resources across multiple AWS regions in a single configuration, managing resources in multiple AWS accounts simultaneously, or using different authentication methods for different sets of resources. Without the ability to specify alternate provider configurations, you would need separate Terraform configurations for each region or account.
The provider meta-argument applies to individual resources, data sources, and modules. When you pass a provider configuration to a module using the providers argument in the module block, you map provider configurations from the calling module to the expected provider names in the child module. The depends_on meta-argument establishes explicit dependencies, alias is used within provider blocks to name alternate configurations, and source is used in module blocks to specify where modules come from.
Question 206:
What is the recommended way to store sensitive data like passwords in Terraform?
A) Store them directly in configuration files
B) Use environment variables or secret management systems
C) Store them in the state file only
D) Include them in module outputs
Answer: B
Explanation:
The recommended way to store sensitive data like passwords in Terraform is to use environment variables or dedicated secret management systems rather than hardcoding them in configuration files. Sensitive values such as passwords, API keys, access tokens, and private keys should never be stored in plain text in Terraform configuration files because these files are typically committed to version control, shared among team members, and may be visible in various logs and systems throughout your development and deployment pipeline.
Environment variables provide a basic level of separation between sensitive data and configuration code. You can reference environment variables in Terraform using the TF_VAR prefix for variable values or through provider-specific environment variables for authentication credentials. This keeps secrets out of version control while still making them available to Terraform at runtime. However, for production systems, dedicated secret management solutions provide better security, audit trails, and access controls.
Integration with secret management systems like HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or Google Secret Manager is the preferred approach for handling sensitive data in production environments. Terraform can retrieve secrets from these systems at runtime using data sources or provider configurations. These systems offer features like encryption at rest and in transit, fine-grained access controls, secret rotation, audit logging, and versioning. By retrieving secrets dynamically, you ensure they are never stored in your code or version control.
It is important to note that sensitive values retrieved or generated by Terraform will still appear in the state file in plain text, which is why securing the state file is equally critical. Use remote backends with encryption at rest, restrict access to state files using authentication and authorization, and consider using backends that support state encryption. Never store passwords directly in configuration files or expose them through outputs without marking them sensitive, as these practices significantly increase the risk of credential exposure.
Question 207:
What does the replace flag do in the terraform apply command?
A) It replaces variables in the configuration
B) It forces replacement of a specific resource
C) It replaces the state file with a backup
D) It replaces the provider configuration
Answer: B
Explanation:
The replace flag in the terraform apply command forces the replacement of a specific resource, causing Terraform to destroy and recreate that resource even if no configuration changes would normally require it. This flag is useful when a resource has become degraded, misconfigured outside of Terraform, or when you need to force a recreation for troubleshooting purposes. The syntax is terraform apply dash replace equals resource_address, where resource_address is the full identifier of the resource you want to replace.
The replace flag was introduced as a more explicit and safer alternative to the terraform taint command. While terraform taint modifies the state file to mark a resource as tainted before you run apply, the replace flag allows you to specify replacement intent at apply time without modifying state beforehand. This makes the operation more transparent and reduces the risk of accidentally leaving resources in a tainted state if you change your mind before applying.
When you use the replace flag, Terraform creates an execution plan that shows the specified resource being destroyed and recreated. You can review this plan before confirming, just like any other apply operation. The resource will be destroyed and recreated according to the normal dependency rules, meaning dependent resources will be updated to reference the new resource, and by default the old resource is destroyed before the new one is created unless create_before_destroy is configured.
You can specify multiple replace flags in a single terraform apply command to force replacement of multiple resources. This is useful when several resources need to be recreated together. The replace functionality does not replace variables, state files, or provider configurations, which are different concepts in Terraform. It specifically targets individual resources for forced recreation, providing a controlled way to handle resources that need fresh deployment without changing your configuration.
Question 208:
Which command is used to upgrade provider versions within version constraints?
A) terraform update
B) terraform upgrade
C) terraform init -upgrade
D) terraform providers upgrade
Answer: C
Explanation:
The terraform init dash upgrade command is used to upgrade provider versions within the constraints specified in your configuration. When you run terraform init without the upgrade flag, Terraform respects the provider versions recorded in the dependency lock file and installs those exact versions. The upgrade flag tells Terraform to check for newer provider versions that satisfy your version constraints and update the lock file with the new selections if newer versions are available.
This upgrade mechanism balances stability with the ability to get updates. By default, Terraform installations are stable and reproducible because the lock file pins specific versions. However, when you explicitly run terraform init dash upgrade, you opt into getting newer versions of providers within your specified constraints. For example, if your constraint allows version tilde greater than 4.0, Terraform might upgrade from 4.0.0 to 4.67.0, but not to 5.0.0 which would be outside the constraint.
After running terraform init dash upgrade, you should review the changes to the dependency lock file to see which providers were updated and to what versions. You should also review the changelog for upgraded providers to understand what changes, new features, or bug fixes are included. It is good practice to test your configuration after upgrading providers, especially before applying changes to production environments, as provider updates can sometimes introduce breaking changes or behavior differences.
The upgrade flag can also be combined with the upgrade flag when you want to target specific providers for upgrade rather than all providers. However, the basic terraform init dash upgrade command upgrades all providers. There is no standalone terraform update, terraform upgrade, or terraform providers upgrade command in Terraform. The init command with the upgrade flag is the standard and recommended way to update provider versions while respecting your version constraints.
Question 209:
What is the purpose of the terraform console command?
A) To open a web-based console for Terraform
B) To provide an interactive console for evaluating expressions
C) To display console logs from resources
D) To configure console output formatting
Answer: B
Explanation:
The terraform console command provides an interactive console for evaluating Terraform expressions. This command opens a command-line interface where you can type expressions and immediately see their results, making it an invaluable tool for testing and debugging Terraform configurations. The console has access to all the same functions, variables, resources, and data sources available in your configuration, allowing you to experiment with expressions before incorporating them into your actual Terraform code.
The console is particularly useful for testing complex expressions, understanding how functions work, debugging variable interpolations, examining resource attributes from state, and exploring data transformations. For example, you can test string manipulation functions, try different combinations of conditional expressions, verify that your for loops produce expected results, or check what attributes are available on resources in your state file. The console provides immediate feedback, making iteration much faster than modifying configuration files and running plan or apply.
When you run terraform console, Terraform loads your configuration and state just as it would for a plan operation. This means you have access to all variables with their current values, all resource and data source attributes from state, and all local values and module outputs. You can reference these using the same syntax you would use in configuration files. For example, typing var.environment would show the value of that variable, and typing aws_instance.example.public_ip would show that attribute from state.
The console supports multi-line input for complex expressions, and you can scroll through command history using arrow keys. To exit the console, you type exit or press Ctrl-D. The terraform console command does not open a web interface, display resource logs, or configure output formatting. It is specifically designed as an interactive expression evaluation tool for development and debugging purposes, helping you understand and test Terraform’s expression language.
Question 210:
What is the primary use of the dynamic block in Terraform?
A) To create resources dynamically at runtime
B) To generate multiple nested blocks within a resource
C) To dynamically select provider configurations
D) To create dynamic variable types
Answer: B
Explanation:
The primary use of the dynamic block in Terraform is to generate multiple nested blocks within a resource based on a collection such as a list or map. Many Terraform resources contain nested configuration blocks that can be repeated multiple times, such as ingress rules in security groups, tag blocks, or settings configurations. The dynamic block allows you to programmatically generate these repeated nested blocks without having to manually write each one, making your configuration more flexible and maintainable.
The dynamic block uses a for-each style iteration to create nested blocks. The syntax includes the dynamic keyword followed by the name of the nested block type you want to generate, a for_each argument specifying the collection to iterate over, and a content block defining the structure of each generated nested block. Inside the content block, you can reference the current iteration element using the iterator name, which defaults to the block type name but can be customized.
A common example is generating multiple ingress rules for an AWS security group. Instead of writing separate ingress blocks for each port, you can define a list or map of port configurations and use a dynamic block to generate the ingress rules from that collection. This approach makes it easy to add or remove rules by modifying the input collection rather than editing multiple static blocks. The dynamic block can also be nested within other dynamic blocks for complex multi-level structures.
While dynamic blocks are powerful, they should be used judiciously. Overusing dynamic blocks can make configurations harder to read and understand, especially for team members less familiar with Terraform’s meta-programming features. Use dynamic blocks when you have a variable number of repeated nested blocks based on input data, but prefer explicit static blocks when the structure is fixed and simple. Dynamic blocks do not create resources dynamically, select providers, or create variable types, which are separate Terraform concepts.