AWS provider Provider Management Practice Test 3 — 15 Questions

Question 1

If a developer wants to use a provider that is not in the public registry, can they still use it?

Accepted Answer

Yes, by using a local registry or filesystem mirror.. Terraform supports provider installation from local filesystem mirrors or a local registry, not just the public Terraform Registry. A filesystem mirror is a directory containing provider packages in the expected layout, and a local registry can serve providers over HTTP. This allows developers to use custom or private providers without publishing them publicly.

Answer

No, only registry providers are supported.

Answer

Yes, by setting the env var TF_IN_AUTOMATION.

Answer

Yes, by recompiling Terraform binary.

Question 2

What is the primary function of the 'source' attribute in the 'required_providers' block?

Accepted Answer

To specify the registry address.. The 'source' attribute in the 'required_providers' block specifies the global source address of the provider, which is the registry hostname, namespace, and type. This tells Terraform where to download the provider from, such as 'hashicorp/aws' or 'registry.terraform.io/hashicorp/aws'. It does not define a local path or region.

Answer

To define the local path of the provider code.

Answer

To define the AWS region.

Answer

To enable debugging.

Question 3

What happens if you have a provider version conflict in your module dependencies?

Accepted Answer

Terraform will fail to initialize.. When two modules or the root module declare incompatible version constraints for the same provider, Terraform cannot satisfy both and aborts during 'terraform init' with a provider version conflict error. Terraform does not silently pick a version when constraints are mutually exclusive; it requires the user to reconcile the constraints. This fail-fast behavior prevents unpredictable provider behavior across modules.

Answer

Terraform will pick the newest version.

Answer

Terraform will ignore the constraints.

Answer

Terraform will pick the oldest version.

Question 4

When using multiple provider instances with different regions, what must be defined in the provider configuration?

Accepted Answer

A unique alias identifier.. When you declare multiple instances of the same provider (e.g., two `aws` providers for different regions), each non-default instance must have a unique `alias` argument. Resources then select the desired instance using the `provider = aws.<alias>` meta-argument. Without an alias, Terraform cannot distinguish the instances and errors on duplicate provider configuration.

Answer

A unique project ID.

Answer

A credentials object.

Answer

A version constraint in each block.

Question 5

What is the correct way to specify a version constraint for a provider that must be at least 3.0 but less than 4.0?

Accepted Answer

version = "~> 3.0". The pessimistic constraint operator ~> 3.0 means '>= 3.0 and < 4.0', allowing any 3.x release while preventing upgrades to 4.0. This matches the requirement of at least 3.0 but less than 4.0 exactly. It is the idiomatic Terraform way to pin to a major version while accepting minor and patch updates.

Answer

version = ">= 3.0"

Answer

version = "3.0"

Answer

version = "> 3.0, < 4.0"

Question 6

When defining a provider in Terraform, what does the 'alias' meta-argument signify?

Accepted Answer

It allows using multiple configurations of the same provider.. The 'alias' meta-argument lets you declare multiple configurations of the same provider within a single configuration, each with different settings (e.g., different AWS regions or accounts). Resources then reference the aliased provider to control which configuration they use.

Answer

It links to a different provider type.

Answer

It defines the provider's short name.

Answer

The provider is deprecated.

Question 7

Which block is used to configure provider-level settings like region or profile?

Accepted Answer

provider "aws" {}. The 'provider' block is used to configure the provider itself.

Answer

module {}

Answer

terraform {}

Answer

resource "aws_instance" {}

Question 8

Which command helps verify if the providers are properly initialized?

Accepted Answer

terraform providers. 'terraform providers' lists all providers required by the configuration, confirming they are initialized.

Answer

terraform validate

Answer

terraform show

Answer

terraform plan

Question 9

When writing a custom provider, what is the 'Schema' used for?

Accepted Answer

To define the attributes of resources.. In the Terraform Plugin SDK, a provider's 'Schema' defines the structure, types, and behaviour of every attribute on a resource or data source — including whether fields are Required, Optional, Computed, their types, defaults, and validation. It is the contract between Terraform configuration and the provider's CRUD functions.

Answer

To define the cloud service billing.

Answer

To define the provider's icon.

Answer

To store state.

Question 10

If a user omits the 'version' in 'required_providers', what version does Terraform use?

Accepted Answer

The latest available version.. When the 'version' argument is omitted inside a required_providers block, Terraform does not pin the provider to any specific release and instead resolves to the newest version available in the configured registry (public Terraform Registry or private registry). This is why HashiCorp strongly recommends always pinning versions in production to avoid unexpected breaking changes.

Answer

It will fail to initialize.

Answer

Version 1.0.0.

Answer

The oldest available version.

Question 11

What is the effect of running 'terraform init -upgrade' on the '.terraform.lock.hcl' file?

Accepted Answer

It updates the file to reflect new provider versions.. Running 'terraform init -upgrade' re-resolves provider version constraints against the registry and updates the .terraform.lock.hcl file to record the newly selected provider versions and their hashes. It is the supported way to move to newer provider releases without deleting the lock file manually.

Answer

It deletes the file.

Answer

It makes the file read-only.

Answer

It hides the file.

Question 12

How do you pass a provider instance from a root module into a child module?

Accepted Answer

Use the 'providers' map in the module block.. The providers map inside a module block explicitly passes a configured provider instance (or alias) from the root module into the child module, allowing the child to use a specific provider configuration rather than inheriting the default. This is required when the child module needs a non-default provider alias, a differently configured region, or a provider defined only in the parent. The syntax is providers = { aws = aws.us_east_1 } inside the module block.

Answer

Use a module output.

Answer

Use a variable.

Answer

You cannot pass providers.

Question 13

If a resource is not specified with a provider meta-argument, which provider instance does it use?

Accepted Answer

The provider configuration without an alias.. When a resource omits the provider meta-argument, Terraform associates it with the default provider configuration — the one declared without an alias. Aliased provider configurations (e.g., provider "aws" { alias = "west" }) are only used when a resource explicitly references them via provider = aws.west. This default-association rule is fundamental to how Terraform resolves provider instances.

Answer

The first one defined.

Answer

The one with the latest version.

Answer

It causes an error.

Question 14

Which of the following are valid ways to specify provider versions? (Select TWO)

Accepted Answer

In the required_providers block.. Option A is correct because Terraform's modern and recommended method for pinning provider versions is the required_providers block inside a terraform block, where each provider is listed with a source address and a version constraint (e.g., version = "~> 5.0"). Option D is correct because the legacy syntax allowed specifying a version argument directly inside a provider configuration block (e.g., provider "aws" { version = "~> 5.0" }), which still works but is deprecated in favor of required_providers. Option B is incorrect because resource blocks configure resource arguments and do not accept a provider version constraint. Option C is incorrect because backend blocks configure state storage and locking, not provider versions. Option E is incorrect because output blocks only export values from the configuration and have no version attribute.

Answer

In the resource block.

Answer

In the backend block.

Answer

In the output block.

Question 15

What are common reasons to use multiple provider instances? (Select TWO)

Accepted Answer

Using different credentials for different resources.. Option D is correct because multiple provider instances (created with the alias meta-argument) let you attach distinct credential sets to different resources, for example managing resources in separate AWS accounts or with different IAM roles within one configuration. Option E is correct because aliased provider instances are the standard way to target multiple AWS regions in a single configuration, such as provider "aws" { alias = "us_east" } and provider "aws" { alias = "eu_west" }, then referencing them per resource. Option A is not a reason for multiple provider instances, since Terraform CLI performance is governed by parallelism and graph execution, not by the number of provider configurations. Option B is incorrect because provider versions are pinned in the required_providers block, not by instantiating multiple provider instances. Option C is incorrect because a state file is always required for tracking real infrastructure; provider aliases do not eliminate it.

Answer

Increasing performance of the Terraform CLI.

Answer

Installing multiple versions of the same provider.

Answer

Bypassing the need for a state file.