[2022年01月30日] 合格させるHashiCorp TA-002-P試験情報と無料練習テスト [Q60-Q80]

[2022年01月30日] 合格させるHashiCorp TA-002-P試験情報と無料練習テスト

TA-002-P試験問題集PDF更新された問題集にはJPNTest試験合格保証付き

HashiCorp TA-002-P 認定試験の出題範囲：

トピック	出題範囲
トピック 1	Describe secure secret injection best practice Use resource addressing and resource parameters to connect resources together
トピック 2	Destroy Terraform managed infrastructure (terraform destroy) Given a scenario: choose when to use terraform fmt to format code
トピック 3	Explain multi-cloud and provider-agnostic benefits Understand infrastructure as code (IaC) concepts
トピック 4	Given a scenario: choose when to use terraform workspace to create workspaces Describe effect of Terraform refresh on state
トピック 5	Use Terraform built-in functions to write configuration Generate and review an execution plan for Terraform (terraform plan)
トピック 6	Describe remote state storage mechanisms and supported standard backends Describe how Terraform finds and fetches providers
トピック 7	Given a scenario: choose when to use terraform state to view Terraform state Describe plugin based architecture
トピック 8	Given a scenario: choose when to use terraform taint to taint Terraform resources Handle backend authentication methods
トピック 9	Describe the benefits of Sentinel, registry, and workspaces Describe variable scope within modules child modules
トピック 10	Explain when to use and not use provisioners and when to use local-exec or remote-exec Describe advantages of IaC patterns
トピック 11	Create and differentiate resource and data configuration Understand the use of collection and structural types
トピック 12	Discover modules from the public Terraform Module Registry Initialize a Terraform working directory (terraform init)
トピック 13	Describe backend block in configuration and best practices for partial configurations Demonstrate using multiple providers
トピック 14	Execute changes to infrastructure with Terraform (terraform apply) Handle Terraform and provider installation and versioning
トピック 15	Given a scenario: choose when to enable verbose logging and what the outcome value is Interact with module inputs and outputs

質問 60
John is writing a module and within the module, there are multiple places where he has to use the same conditional expression but he wants to avoid repeating the same values or expressions multiple times in a configuration,. What is a better approach to dealing with this?

A. Expressions
B. Local Values
C. Variables
D. Functions

正解: B

解説:
Explanation
A local value assigns a name to an expression, allowing it to be used multiple times within a module without repeating it.
https://www.terraform.io/docs/configuration/locals.html

質問 61
How is the Terraform remote backend different than other state backends such as S3, Consul, etc.?

A. It can execute Terraform runs on dedicated infrastructure on premises or in Terraform Cloud
B. All of the above
C. It doesn't show the output of a terraform apply locally
D. It is only available to paying customers

正解: A

解説:
Explanation
If you and your team are using Terraform to manage meaningful infrastructure, we recommend using the remote backend with Terraform Cloud or Terraform Enterprise.
Reference: https://www.terraform.io/docs/language/settings/backends/index.html

質問 62
You need to deploy resources into two different cloud regions in the same Terraform configuration. To do that, you declare multiple provider configurations as follows:

What meta-argument do you need to configure in a resource block to deploy the resource to the "us-west-2" AWS region?

A. provider = west
B. alias = west
C. provider = aws.west
D. alias = aws.west

正解: B

質問 63
Which of the following best describes the default local backend?

A. The local backend is the directory where resources deployed by Terraform have direct access to in order to update their current state.
B. The local backend stores state on the local filesystem, locks the state using system APIs, and performs operations locally.
C. The local backend is how Terraform connects to public cloud services, such as AWS, Azure, or GCP.
D. The local backend is where Terraform Enterprise stores logs to be processed by an log collector.

正解: B

解説:
Explanation
The local backend stores state on the local filesystem, locks that state using system APIs, and performs operations locally.
terraform {
backend "local" {
path = "relative/path/to/terraform.tfstate"
}
}
https://www.terraform.io/docs/backends/types/local.html

質問 64
Workspaces in Terraform provides similar functionality in the open-source, Terraform Cloud, and Enterprise versions of Terraform.

A. True
B. False

正解: B

解説:
https://www.terraform.io/docs/cloud/migrate/workspaces.html
Workspaces, managed with the terraform workspace command, aren't the same thing as Terraform Cloud's workspaces. Terraform Cloud workspaces act more like completely separate working directories; CLI workspaces are just alternate state files.

質問 65
Which one is the right way to import a local module names consul?

A. module "consul" { source = "consul"}
B. module "consul" { source = "./consul"}
C. module "consul" { source = "module/consul"}
D. module "consul" { source = "../consul"}

正解: B,D

解説:
Explanation
A local path must begin with either ./ or ../ to indicate that a local path is intended, to distinguish from a module registry address.
module "consul" {
source = "./consul"
}

質問 66
After executing a terraform apply, you notice that a resource has a tilde (~) next to it. What does this infer?

A. The resource will be created.
B. The resource will be destroyed and recreated.
C. The resource will be updated in place.
D. Terraform can't determine how to proceed due to a problem with the state file.

正解: C

解説:
Explanation
The prefix -/+ means that Terraform will destroy and recreate the resource, rather than updating it in-place.
The prefix ~ means that some attributes and resources can be updated in-place.
$ terraform apply
aws_instance.example: Refreshing state... [id=i-0bbf06244e44211d1]
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement
Terraform will perform the following actions:
# aws_instance.example must be replaced
-/+ resource "aws_instance" "example" {
~ ami = "ami-2757f631" -> "ami-b374d5a5" # forces replacement
~ arn = "arn:aws:ec2:us-east-1:130490850807:instance/i-0bbf06244e44211d1" -> (known after apply)
~ associate_public_ip_address = true -> (known after apply)
~ availability_zone = "us-east-1c" -> (known after apply)
~ cpu_core_count = 1 -> (known after apply)
~ cpu_threads_per_core = 1 -> (known after apply)
- disable_api_termination = false -> null
- ebs_optimized = false -> null
get_password_data = false
+ host_id = (known after apply)
~ id = "i-0bbf06244e44211d1" -> (known after apply)
~ instance_state = "running" -> (known after apply)
instance_type = "t2.micro"
~ ipv6_address_count = 0 -> (known after apply)
~ ipv6_addresses = [] -> (known after apply)
+ key_name = (known after apply)
- monitoring = false -> null
+ network_interface_id = (known after apply)
+ password_data = (known after apply)
+ placement_group = (known after apply)
~ primary_network_interface_id = "eni-0f1ce5bdae258b015" -> (known after apply)
~ private_dns = "ip-172-31-61-141.ec2.internal" -> (known after apply)
~ private_ip = "172.31.61.141" -> (known after apply)
~ public_dns = "ec2-54-166-19-244.compute-1.amazonaws.com" -> (known after apply)
~ public_ip = "54.166.19.244" -> (known after apply)
~ security_groups = [
- "default",
] -> (known after apply)
source_dest_check = true
~ subnet_id = "subnet-1facdf35" -> (known after apply)
~ tenancy = "default" -> (known after apply)
~ volume_tags = {} -> (known after apply)
~ vpc_security_group_ids = [
- "sg-5255f429",
] -> (known after apply)
- credit_specification {
- cpu_credits = "standard" -> null
}
+ ebs_block_device {
+ delete_on_termination = (known after apply)
+ device_name = (known after apply)
+ encrypted = (known after apply)
+ iops = (known after apply)
+ snapshot_id = (known after apply)
+ volume_id = (known after apply)
+ volume_size = (known after apply)
+ volume_type = (known after apply)
}
+ ephemeral_block_device {
+ device_name = (known after apply)
+ no_device = (known after apply)
+ virtual_name = (known after apply)
}
+ network_interface {
+ delete_on_termination = (known after apply)
+ device_index = (known after apply)
+ network_interface_id = (known after apply)
}
~ root_block_device {
~ delete_on_termination = true -> (known after apply)
~ iops = 100 -> (known after apply)
~ volume_id = "vol-0079e485d9e28a8e5" -> (known after apply)
~ volume_size = 8 -> (known after apply)
~ volume_type = "gp2" -> (known after apply)
}
}
Plan: 1 to add, 0 to change, 1 to destroy.

質問 67
In regards to deploying resources in multi-cloud environments, what are some of the benefits of using Terraform rather than a provider's native tooling? (select three)

A. Terraform simplifies management and orchestration, helping operators build large-scale, multi-cloud infrastructure.
B. Terraform can help businesses deploy applications on multiple clouds and on-premises infrastructure.
C. Terraform is not cloud-agnostic and can be used to deploy resources across a single public cloud.
D. Terraform can manage cross-cloud dependencies.

正解: A,B,D

解説:
Explanation
Terraform is cloud-agnostic and allows a single configuration to be used to manage multiple providers, and to even handle cross-cloud dependencies. This simplifies management and orchestration, helping operators build large-scale multi-cloud infrastructures.
https://www.terraform.io/intro/use-cases.html

質問 68
A provider configuration block is required in every Terraform configuration.
Example:

A. True
B. False

正解: A

解説:
Reference: https://github.com/hashicorp/terraform/issues/17928

質問 69
Named workspaces are not a suitable isolation mechanism for strong separation between staging and production?

A. True
B. False

正解: A

解説:
Explanation
Organizations commonly want to create a strong separation between multiple deployments of the same infrastructure serving different development stages (e.g. staging vs. production) or different internal teams. In this case, the backend used for each deployment often belongs to that deployment, with different credentials and access controls. Named workspaces are not a suitable isolation mechanism for this scenario.
https://www.terraform.io/docs/state/workspaces.html#when-to-use-multiple-workspaces

質問 70
Terraform init can indeed be run only a few times, because, every time terraform init will initialize the project , and download all plugins from the internet repository , regardless of whether they were present or not , and this increases the waiting time

A. True
B. False

正解: B

解説:
Re-running init with modules already installed will install the sources for any modules that were added to configuration since the last init, but will not change any already-installed modules. Use -upgrade to override this behavior, updating all modules to the latest available source code.
https://www.terraform.io/docs/commands/init.html

質問 71
You have created two workspaces PROD and DEV. You have switched to DEV and provisioned DEV infrastructure from this workspace. Where is your state file stored?

A. terraform.tfstate
B. terraform.d
C. terraform.tfstate.DEV
D. terraform.tfstate.d

正解: D

解説:
Explanation
Terraform stores the workspace states in a directory called terraform.tfstate.d. This directory should be treated similarly to default workspace state file terraform.tfstate main.tf provider.tf terraform.tfstate.d DEV terraform.tfstate # DEV workspace state file PROD terraform.tfstate # PROD workspace state file terraform.tfvars # Default workspace state file variables.tf

質問 72
You have multiple team members collaborating on infrastructure as code (IaC) using Terraform, and want to apply formatting standards for readability.
How can you format Terraform HCL (HashiCorp Configuration Language) code according to standard Terraform style convention?

A. Manually apply two spaces indentation and align equal sign "=" characters in every Terraform file (*.tf)
B. Run the terraform fmt command during the code linting phase of your CI/CD process
C. Write a shell script to transform Terraform files using tools such as AWK, Python, and sed
D. Designate one person in each team to review and format everyone's code

正解: A

解説:
Explanation
Indent two spaces for each nesting level.
When multiple arguments with single-line values appear on consecutive lines at the same nesting level, align their equals signs.
Reference: https://www.terraform.io/docs/language/syntax/style.html

質問 73
When using constraint expressions to signify a version of a provider, which of the following are valid provider versions that satisfy the expression found in the following code snippet: (select two)
1. terraform
2. {
3. required_providers
4. {
5. aws = "~> 1.2.0"
6. }
7. }

A. 1.3.0
B. 1.2.3
C. 1.3.1
D. 1.2.9

正解: B,D

解説:
Explanation
As your Terraform usage becomes more advanced, there are some cases where you may need to modify the Terraform state. Rather than modify the state directly, the terraform state commands can be used in many cases instead. This command is a nested subcommand, meaning that it has further subcommands.
https://www.terraform.io/docs/commands/state/index.html

質問 74
Hanah is writing a terraform configuration with nested modules, there are multiple places where she has to use the same conditional expression but she wants to avoid repeating the same values or expressions multiple times in the configuration,. What is a better approach to dealing with this?

A. Expressions
B. Local Values
C. Variables
D. Functions

正解: B

解説:
Explanation
https://www.terraform.io/docs/configuration/locals.html

質問 75
Which of the following Terraform files should be ignored by Git when committing code to a repo? (select Three)

A. terraform.tfstate
B. Files named exactly terraform.tfvars or terraform.tfvars.json.
C. Any files with names ending in .auto.tfvars or .auto.tfvars.json.
D. output.tf
E. input.tf

正解: A,B,C

解説:
Explanation
The .gitignore file should be configured to ignore Terraform files that either contain sensitive data or are not required to save.
Terraform state (terraform.tfstate) can contain sensitive data, depending on the resources in use and your definition of "sensitive." The state contains resource IDs and all resource attributes. For resources such as databases, this may contain initial passwords.
When using local state, state is stored in plain-text JSON files.
The terraform.tfvars file may contain sensitive data, such as passwords or IP addresses of an environment that you may not want to share with others.

質問 76
Terraform requires the Go runtime as a prerequisite for installation.

A. True
B. False

正解: B

質問 77
Select the feature below that best completes the sentence:
The following list represents the different types of __________ available in Terraform.
1. max
2. min
3. join
4. replace
5. list
6. length
7. range

A. Named values
B. Backends
C. Functions
D. Data sources

正解: C

解説:
The Terraform language includes a number of built-in functions that you can call from within expressions to transform and combine values. The Terraform language does not support user-defined functions, and only the functions built into the language are available for use.
https://www.terraform.io/docs/configuration/functions.html

質問 78
Only the user that generated a plan may apply it.

A. True
B. False

正解: A

解説:
Explanation
The optional -out argument can be used to save the generated plan to a file for later execution with terraform apply, which can be useful when running Terraform in automation.
Reference: https://learn.hashicorp.com/tutorials/terraform/automate-terraform

質問 79
You have declared a variable name my_var in terraform configuration without a value associated with it.
variable my_var {}
After running terraform plan it will show an error as variable is not defined.

A. True
B. False

正解: B

解説:
Explanation
Input variables are usually defined by stating a name, type and a default value. However, the type and default values are not strictly necessary. Terraform can deduct the type of the variable from the default or input value.
Variables can be predetermined in a file or included in the command-line options. As such, the simplest variable is just a name while the type and value are selected based on the input.
variable "variable_name" {}
terraform apply -var variable_name="value"
The input variables, like the one above, use a couple of different types: strings, lists, maps, and boolean. Here are some examples of how each type are defined and used.
String
Strings mark a single value per structure and are commonly used to simplify and make complicated values more user-friendly. Below is an example of a string variable definition.
variable "template" {
type = string
default = "01000000-0000-4000-8000-000030080200"
}
A string variable can then be used in resource plans. Surrounded by double quotes, string variables are a simple substitution such as the example underneath.
storage = var.template
List
Another type of Terraform variables lists. They work much like a numbered catalogue of values. Each value can be called by their corresponding index in the list. Here is an example of a list variable definition.
variable "users" {
type = list
default = ["root", "user1", "user2"]
}
Lists can be used in the resource plans similarly to strings, but you'll also need to denote the index of the value you are looking for.
username = var.users[0]
Map
Maps are a collection of string keys and string values. These can be useful for selecting values based on predefined parameters such as the server configuration by the monthly price.
variable "plans" {
type = map
default = {
"5USD" = "1xCPU-1GB"
"10USD" = "1xCPU-2GB"
"20USD" = "2xCPU-4GB"
}
}
You can access the right value by using the matching key. For example, the variable below would set the plan to "1xCPU-1GB".
plan = var.plans["5USD"]
The values matching to their keys can also be used to look up information in other maps. For example, underneath is a shortlist of plans and their corresponding storage sizes.
variable "storage_sizes" {
type = map
default = {
"1xCPU-1GB" = "25"
"1xCPU-2GB" = "50"
"2xCPU-4GB" = "80"
}
}
These can then be used to find the right storage size based on the monthly price as defined in the previous example.
size = lookup(var.storage_sizes, var.plans["5USD"])
Boolean
The last of the available variable type is boolean. They give the option to employ simple true or false values.
For example, you might wish to have a variable that decides when to generate the root user password on a new deployment.
variable "set_password" {
default = false
}
The above example boolean can be used similarly to a string variable by simply marking down the correct variable.
create_password = var.set_password
By default, the value is set to false in this example. However, you can overwrite the variable at deployment by assigning a different value in a command-line variable.
terraform apply -var set_password="true"