HashiCorp Terraform-Associate-003試験問題（更新されたのは2025年）100%リアル問題解答
合格させるHashiCorp Terraform-Associate-003試験最速合格
HashiCorp Terraform-Associate-003 認定試験の出題範囲：
| トピック | 出題範囲 |
|---|---|
| トピック 1 |
|
| トピック 2 |
|
| トピック 3 |
|
| トピック 4 |
|
| トピック 5 |
|
質問 # 49
How can a ticket-based system slow down infrastructure provisioning and limit the ability to scale? Choose two correct answers.
- A. Ticket based systems generate a full audit trail of the request and fulfillment process
- B. Users can access catalog of approved resources from drop down list in a request form
- C. The more resources your organization needs, the more tickets your infrastructure team has to process
- D. End-users have to request infrastructure changes
正解：D
解説：
Explanation
These are some of the ways that a ticket-based system can slow down infrastructure provisioning and limit the ability to scale, as they introduce delays, bottlenecks, and manual interventions in the process of creating and modifying infrastructure.
質問 # 50
Define the purpose of state in Terraform.
- A. State lets you enforce resource configurations that relate to compliance policies
- B. State codifies the dependencies of related resources
- C. State stores variables and lets you quickly reuse existing code
- D. State maps real world resources to your configuration and keeps track of metadata
正解：D
解説：
The purpose of state in Terraform is to keep track of the real-world resources managed by Terraform, mapping them to the configuration. The state file contains metadata about these resources, such as resource IDs and other important attributes, which Terraform uses to plan and manage infrastructure changes. The state enables Terraform to know what resources are managed by which configurations and helps in maintaining the desired state of the infrastructure.
References = This role of state in Terraform is outlined in Terraform's official documentation, emphasizing its function in mapping configuration to real-world resources and storing vital metadata .
質問 # 51
Terraform variable names are saved in the state file.
- A. False
- B. True
正解：A
解説：
Terraform variable names are not saved in the state file, only their values are. The state file only stores the attributes of the resources and data sources that are managed by Terraform, not the variables that are used to configure them.
質問 # 52
You have a list of numbers that represents the number of free CPU cores on each virtual cluster:
What Terraform function could you use to select the largest number from the list?
- A. ceil (numcpus)
- B. max(numcpus)
- C. hight[numcpus]
- D. top(numcpus)
正解：B
解説：
In Terraform, the max function can be used to select the largest number from a list of numbers. The max function takes multiple arguments and returns the highest one. For the list numcpus = [18, 3, 7, 11, 2], using max(numcpus...) will return 18, which is the largest number in the list.
Reference:
Terraform documentation on max function: Terraform Functions - max
質問 # 53
You are working on some new application features and you want to spin up a copy of your production deployment to perform some quick tests. In order to avoid having to configure a new state backend, what open source Terraform feature would allow you create multiple states but still be associated with your current code?
- A. Terraform data sources
- B. Terraform workspaces
- C. Terraform local values
- D. None of the above
- E. Terraform modules
正解：B
解説：
Terraform workspaces allow you to create multiple states but still be associated with your current code.
Workspaces are like "environments" (e.g. staging, production) for the same configuration. You can use workspaces to spin up a copy of your production deployment for testing purposes without having to configure a new state backend. Terraform data sources, local values, and modules are not features that allow you to create multiple states. References = Workspaces and How to Use Terraform Workspaces
質問 # 54
You have to initialize a Terraform backend before it can be configured.
- A. False
- B. True
正解：A
解説：
Explanation
You can configure a backend in your Terraform code before initializing it. Initializing a backend will store the state file remotely and enable features like locking and workspaces. References = [Terraform Backends]
質問 # 55
Which command must you first run before performing further Terraform operations in a working directory?
- A. terraform init
- B. terraform workspace
- C. terraform import
- D. terraform plan
正解：A
解説：
Explanation
terraform init is the first command that should be run after writing a new Terraform configuration or cloning an existing one from version control. It initializes a working directory containing Terraform configuration files and downloads any required providers and modules. The other commands are used for different purposes, such as importing existing resources, switching between workspaces, generating execution plans, etc.
質問 # 56
terraform validate reports syntax check errors for which of the following?
- A. None of the above
- B. Code contains tabs for indentation instead of spaces
- C. The state file does not match the current infrastructure
- D. There is a missing value for a variable
正解：A
解説：
The terraform validate command is used to check for syntax errors and internal consistency within Terraform configurations, such as whether all required arguments are specified. It does not check for indentation styles, missing variable values (as variables might not be defined at validation time), or state file consistency with the current infrastructure. Therefore, none of the provided options are correct in the context of what terraform validate reports.
Reference = Terraform's official documentation details the purpose and function of the terraform validate command, specifying that it focuses on syntax and consistency checks within Terraform configurations themselves, not on external factors like the state file or infrastructure state. Direct references from the HashiCorp Terraform Associate (003) study materials to this specific detail were not found in the provided files.
質問 # 57
You should run terraform fnt to rewrite all Terraform configurations within the current working directory to conform to Terraform-style conventions.
- A. True
- B. False
正解：A
解説：
You should run terraform fmt to rewrite all Terraform configurations within the current working directory to conform to Terraform-style conventions. This command applies a subset of the Terraform language style conventions, along with other minor adjustments for readability. It is recommended to use this command to ensure consistency of style across different Terraform codebases. The command is optional, opinionated, and has no customization options, but it can help you and your team understand the code more quickly and easily. Reference = : Command: fmt : Using Terraform fmt Command to Format Your Terraform Code
質問 # 58
A provider configuration block is required in every Terraform configuration.
Example:
- A. False
- B. True
正解：A
解説：
A provider configuration block is not required in every Terraform configuration. A provider configuration block can be omitted if its contents would otherwise be empty. Terraform assumes an empty default configuration for any provider that is not explicitly configured. However, some providers may require some configuration arguments (such as endpoint URLs or cloud regions) before they can be used. A provider's documentation should list which configuration arguments it expects. For providers distributed on the Terraform Registry, versioned documentation is available on each provider's page, via the "Documentation" link in the provider's header1. References = [Provider Configuration]1
質問 # 59
The Terraform binary version and provider versions must match each other in a single configuration.
- A. False
- B. True
正解：A
解説：
The Terraform binary version and provider versions do not have to match each other in a single configuration. Terraform allows you to specify provider version constraints in the configuration's terraform block, which can be different from the Terraform binary version1. Terraform will use the newest version of the provider that meets the configuration's version constraints2. You can also use the dependency lock file to ensure Terraform is using the correct provider version3.
References =
* 1: Providers - Configuration Language | Terraform | HashiCorp Developer
* 2: Multiple provider versions with Terraform - Stack Overflow
* 3: Lock and upgrade provider versions | Terraform - HashiCorp Developer
質問 # 60
How would you reference the volume IDs associated with the ebs_block_device blocks in this configuration?
- A. aws_lnstance.example.ebs_block_device.volume_ids
- B. aws_lnstance.example.ebs_block_device.[*].volume_id
- C. aws_instance.example-ebs_block_device.*.volume_id
- D. aws_instance.example.ebs_block_device[sda2,sda3).volume_id
正解：C
解説：
This is the correct way to reference the volume IDs associated with the ebs_block_device blocks in this configuration, using the splat expression syntax. The other options are either invalid or incomplete.
質問 # 61
What are some benefits of using Sentinel with Terraform Cloud/Terra form Cloud? Choose three correct answers.
- A. Sentinel Policies can be written in HashiCorp Configuration Language (HCL)
- B. Policy-as-code can enforce security best practices
- C. You can enforce a list of approved AWS AMIs
- D. You can restrict specific resource configurations, such as disallowing the use of CIDR=0.0.0.0/0.
- E. You can check out and check in cloud access keys
正解：B、C、D
解説：
Explanation
These are some of the benefits of using Sentinel with Terraform Cloud/Terraform Enterprise, as they allow you to implement logic-based policies that can access and evaluate the Terraform plan, state, and configuration. The other options are not true, as Sentinel does not manage cloud access keys, and Sentinel policies are written in Sentinel language, not HCL.
質問 # 62
You have to initialize a Terraform backend before it can be configured.
- A. False
- B. True
正解：A
解説：
You can configure a backend in your Terraform code before initializing it. Initializing a backend will store the state file remotely and enable features like locking and workspaces. References = [Terraform Backends]
質問 # 63
_______backends support state locking.
- A. No
- B. Some
- C. All
- D. Only local
正解：B
解説：
Explanation
Some backends support state locking, which prevents other users from modifying the state file while a Terraform operation is in progress. This prevents conflicts and data loss. Not all backends support this feature, and you can check the documentation for each backend type to see if it does.
質問 # 64
Which option cannot be used to keep secrets out of Terraform configuration files?
- A. secure string
- B. Environment variables
- C. A Terraform provider
- D. A -var flag
正解：A
解説：
A secure string is not a valid option to keep secrets out of Terraform configuration files. A secure string is a feature of AWS Systems Manager Parameter Store that allows you to store sensitive data encrypted with a KMS key. However, Terraform does not support secure strings natively and requires a custom data source to retrieve them. The other options are valid ways to keep secrets out of Terraform configuration files. A Terraform provider can expose secrets as data sources that can be referenced in the configuration. Environment variables can be used to set values for input variables that contain secrets. A -var flag can be used to pass values for input variables that contain secrets from the command line or a file.
References = [AWS Systems Manager Parameter Store], [Terraform AWS Provider Issue #55], [Terraform Providers], [Terraform Input Variables]
質問 # 65
Which option cannot be used to keep secrets out of Terraform configuration files?
- A. secure string
- B. Environment variables
- C. A Terraform provider
- D. A -var flag
正解：A
解説：
A secure string is not a valid option to keep secrets out of Terraform configuration files. A secure string is a feature of AWS Systems Manager Parameter Store that allows you to store sensitive data encrypted with a KMS key. However, Terraform does not support secure strings natively and requires a custom data source to retrieve them. The other options are valid ways to keep secrets out of Terraform configuration files. A Terraform provider can expose secrets as data sources that can be referenced in the configuration. Environment variables can be used to set values for input variables that contain secrets. A -var flag can be used to pass values for input variables that contain secrets from the command line or a file. Reference = [AWS Systems Manager Parameter Store], [Terraform AWS Provider Issue #55], [Terraform Providers], [Terraform Input Variables]
質問 # 66
Which option cannot be used to keep secrets out of Terraform configuration files?
- A. secure string
- B. Environment variables
- C. A Terraform provider
- D. A -var flag
正解：A
解説：
A secure string is not a valid option to keep secrets out of Terraform configuration files. A secure string is a feature of AWS Systems Manager Parameter Store that allows you to store sensitive data encrypted with a KMS key. However, Terraform does not support secure strings natively and requires a custom data source to retrieve them. The other options are valid ways to keep secrets out of Terraform configuration files. A Terraform provider can expose secrets as data sources that can be referenced in the configuration. Environment variables can be used to set values for input variables that contain secrets. A -var flag can be used to pass values for input variables that contain secrets from the command line or a file. References = [AWS Systems Manager Parameter Store], [Terraform AWS Provider Issue #55], [Terraform Providers], [Terraform Input Variables]
質問 # 67
When should you run terraform init?
- A. After you start coding a new terraform project and before you run terraform plan for the first time.
- B. Before you start coding a new Terraform project
- C. Every time you run terraform apply
- D. After you run terraform plan for the time in a new terraform project and before you run terraform apply
正解：A
解説：
You should run terraform init after you start coding a new Terraform project and before you run terraform plan for the first time. This command will initialize the working directory by downloading the required providers and modules, creating the initial state file, and performing other necessary tasks. Reference = : Initialize a Terraform Project
質問 # 68
Which of the following is not a benefit of adopting infrastructure as code?
- A. Reusability of code
- B. Automation
- C. A Graphical User Interface
- D. Versioning
正解：C
解説：
Infrastructure as Code (IaC) provides several benefits, including the ability to version control infrastructure, reuse code, and automate infrastructure management. However, IaC is typically associated with declarative configuration files and does not inherently provide a graphical user interface (GUI). A GUI is a feature that may be provided by specific tools or platforms built on top of IaC principles but is not a direct benefit of IaC itself1.
Reference = The benefits of IaC can be verified from the official HashiCorp documentation on "What is Infrastructure as Code with Terraform?" provided by HashiCorp Developer1.
質問 # 69
You ate creating a Terraform configuration which needs to make use of multiple providers, one for AWS and one for Datadog. Which of the following provider blocks would allow you to do this?
A)
B)
C)
D)
- A. Option D
- B. Option A
- C. Option C
- D. Option B
正解：C
解説：
Option C is the correct way to configure multiple providers in a Terraform configuration. Each provider block must have a name attribute that specifies which provider it configures2. The other options are either missing the name attribute or using an invalid syntax.
質問 # 70
If a module declares a variable with a default, that variable must also be defined within the module.
- A. False
- B. True
正解：A
解説：
Explanation
A module can declare a variable with a default value without requiring the caller to define it. This allows the module to provide a sensible default behavior that can be customized by the caller if needed. References =
[Module Variables]
質問 # 71
Changing the Terraform backend from the default "local" backend to a different one after performing your first terrafom apply is:
- A. Mandatory
- B. Optional
- C. Impossible
- D. Discouraged
正解：D
解説：
Changing the Terraform backend after performing the initial terraform apply is technically possible but strongly discouraged. This is because changing backends can lead to complexities in state management, requiring manual intervention such as state migration to ensure consistency. Terraform's documentation and best practices advise planning the backend configuration carefully before applying Terraform configurations to avoid such changes.
Reference = This guidance is consistent with Terraform's official documentation, which recommends careful consideration and planning of backend configurations to avoid the need for changes.
質問 # 72
When you include a module block in your configuration that references a module from the Terraform Registry, the "version" attribute is required.
- A. False
- B. True
正解：A
解説：
The "version" attribute is optional when referencing a module from the Terraform Registry. If not specified, the latest version will be used, but it is often recommended to specify a version to ensure consistency across environments.
Reference:
Terraform Module Versioning
質問 # 73
......
リアルHashiCorp Terraform-Associate-003試験問題 [更新されたのは2025年]：https://www.goshiken.com/HashiCorp/Terraform-Associate-003-mondaishu.html
準備Terraform-Associate-003問題解答でTerraform-Associate-003試験問題集：https://drive.google.com/open?id=1v_QmDbNE2FgdeUl1OVsnlyRYnwYsa2-_