4c TERRAFORM-AUTHORING-AND-OPERATIONS-PROFESSIONAL Practice Questions (Page 1)

Questions 1–5

1. 1application · medium

   You are refactoring a Terraform module that creates an AWS EC2 instance. The module currently uses a `count` to create multiple instances based on a list of names. You want to change this to use `for_each` to improve the handling of instance state. What is the most important consideration when making this change?

   • AThe state addresses of the resources will change, which may cause Terraform to recreate the instances.
   • BThe variable type must be changed from a list to a set for `for_each` to work.
   • CThe module's output values will automatically update without any changes.
   • DThe `for_each` syntax is not supported for EC2 instances in Terraform.
   Reveal Solution Discussion Select an answer first
2. 2expert · hard

   You are upgrading a module in your configuration from version `1.0.0` to `1.1.0`. The module's changelog indicates that a new output `vpc_id` was added, and the existing `vpc_name` output is now deprecated but still functional. After updating the source reference and running `terraform plan`, you notice that the plan is empty. What does this indicate?

   • AThe upgrade is backward-compatible, and the new output is available without any infrastructure changes.
   • BThe module's resources have been removed, and Terraform is planning to destroy them.
   • CThe state file is out of sync, and you need to run `terraform refresh` to see the changes.
   • DThe module reference was not updated correctly, and Terraform is still using the old version.
   Reveal Solution Discussion Select an answer first
4. 3application · medium

   You have published version `1.0.0` of a module to your private registry. You later make a backward-compatible bug fix and want to publish it. What version should you publish?

   • A`2.0.0`
   • B`1.0.0-beta`
   • C`1.1.0`
   • D`1.0.1`
   Reveal Solution Discussion Select an answer first
5. 4application · medium

   Your team maintains a Terraform module that provisions an Azure virtual network. The module currently creates a single `azurerm_virtual_network` resource with a fixed address space. A new requirement demands that consumers be able to create multiple subnets with different address prefixes. You want to refactor the module to accept a map of subnet names to prefixes. What is the most appropriate way to implement this change while minimizing disruption to existing consumers?

   • AChange the existing `subnet_prefixes` variable to a map and update the module's internal resource definitions to use `for_each`.
   • BReplace the `azurerm_virtual_network` resource with a `azurerm_virtual_network` data source and use the data source to derive subnets dynamically.
   • CCreate a separate child module for subnets and require all consumers to call it directly instead of through the parent module.
   • DAdd a new optional variable `subnet_map` with a default of `{}` and use `for_each` on the subnet resource, keeping the existing `subnet_prefixes` variable for backward compatibility.
   Reveal Solution Discussion Select an answer first
6. 5foundation · easy

   A team maintains a Terraform module that has been in production for over a year. They want to restructure the module's internal resource definitions to improve readability and reduce duplication. What is the primary reason to prioritize preserving the module's existing input variables and outputs during this refactoring?

   • ATo guarantee that the underlying infrastructure resources will not be replaced
   • BTo avoid breaking existing module consumers who rely on the current interface
   • CTo reduce the number of resources the module manages
   • DTo ensure the module can be published to the public Terraform Registry
   Reveal Solution Discussion Select an answer first