HashiCorp Terraform Associate 003 Practice Test - Questions Answers, Page 7

Sentinel is a policy-as-code framework that allows you to define and enforce rules on your Terraform configurations, states, and plans1. Some of the benefits of using Sentinel with Terraform Cloud/Terraform Enterprise are:

* You can restrict specific resource configurations, such as disallowing the use of CIDR=0.0.0.0/0, which would open up your network to the entire internet. This can help you prevent misconfigurations or security vulnerabilities in your infrastructure2.

* Policy-as-code can enforce security best practices, such as requiring encryption, authentication, or compliance standards. This can help you protect your data and meet regulatory requirements3.

* You can enforce a list of approved AWS AMIs, which are pre-configured images that contain the operating system and software you need to run your applications. This can help you ensure consistency, reliability, and performance across your infrastructure4.

Reference =

* 1: Terraform and Sentinel | Sentinel | HashiCorp Developer

* 2: Terraform Learning Resources: Getting Started with Sentinel in Terraform Cloud

* 3: Exploring the Power of HashiCorp Terraform, Sentinel, Terraform Cloud ...

* 4: Using New Sentinel Features in Terraform Cloud - Medium

Terraform can manage resource dependencies implicitly or explicitly. Implicit dependencies are created when a resource references another resource or data source in its arguments. Terraform can infer the dependency from the reference and create or destroy the resources in the correct order. Explicit dependencies are created when you use thedepends_onargument to specify that a resource depends on another resource or module. This is useful when Terraform cannot infer the dependency from the configuration or when you need to create a dependency for some reason outside of Terraform's scope.Reference= :Create resource dependencies:Terraform Resource Dependencies Explained

None of the above methods prevent credentials from being stored in the state file. Terraform stores the provider configuration in the state file, which may include sensitive information such as credentials. This is a potential security risk and should be avoided if possible. To prevent credentials from being stored in the state file, you can use one of the following methods:

Use environment variables to pass credentials to the provider. This way, the credentials are not part of the provider configuration and are not stored in the state file. However, this method may not work for some providers that require credentials to be set in the provider block.

Use dynamic credentials to authenticate with your cloud provider. This way, Terraform Cloud or Enterprise will request temporary credentials from your cloud provider for each run and use them to provision your resources. The credentials are not stored in the state file and are revoked after the run is completed. This method is supported for AWS, Google Cloud Platform, Azure, and Vault.Reference= : [Sensitive Values in State] :Authenticate providers with dynamic credentials

The Terraform collection type that should be used to store key/value pairs ismap. A map is a collection of values that are accessed by arbitrary labels, called keys. The keys and values can be of any type, but the keys must be unique within a map. For example,var = { key1 = 'value1', key2 = 'value2' }is a map with two key/value pairs. Maps are useful for grouping related values together, such as configuration options or metadata.Reference= [Collection Types], [Map Type Constraints]

The reason why the apply fails after adding a new provider to the configuration and immediately runningterraform applyin the CD using the local backend is because Terraform needs to install the necessary plugins first. Terraform providers are plugins that Terraform uses to interact with various cloud services and other APIs. Each provider has a source address that determines where to download it from. When Terraform encounters a new provider in the configuration, it needs to runterraform initfirst to install the provider plugins in a local directory. Without the plugins, Terraform cannot communicate with the provider and perform the desired actions.Reference= [Provider Requirements], [Provider Installation]

The two steps that are required to provision new infrastructure in the Terraform workflow areinitandapply. Theterraform initcommand initializes a working directory containing Terraform configuration files. It downloads and installs the provider plugins that are needed for the configuration, and prepares the backend for storing the state. Theterraform applycommand applies the changes required to reach the desired state of the configuration, as described by the resource definitions in the configuration files. It shows a plan of the proposed changes and asks for confirmation before making any changes to the infrastructure.Reference= [The Core Terraform Workflow], [Initialize a Terraform working directory with init], [Apply Terraform Configuration with apply]

The name of the default file where Terraform stores the state isterraform.tfstate. This file contains a JSON representation of the current state of the infrastructure managed by Terraform. Terraform uses this file to track the metadata and attributes of the resources, and to plan and apply changes. By default, Terraform stores the state file locally in the same directory as the configuration files, but it can also be configured to store the state remotely in a backend.Reference= [Terraform State], [State File Format]

This is the command that can add existing resources into Terraform state, by matching them with the corresponding configuration blocks in your files.