Provider versioning constraints in Terraform - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Provider Version Constraints

Which Terraform provider version constraint ensures that only versions from 2.0.0 up to, but not including, 3.0.0 are allowed?

A "~> 2.0"

B "^2.0"

C ">= 2.0, < 3.0"

D "= 2.0"

💡 Hint

Think about specifying a range explicitly with both minimum and maximum versions.

The constraint ">= 2.0, < 3.0" explicitly allows any version starting from 2.0 up to but not including 3.0. The "~> 2.0" allows versions from 2.0 up to but not including 3.0 as well, but it also allows patch versions. "^2.0" is not valid syntax in Terraform. "= 2.0" allows only exactly version 2.0.

❓ Configuration

intermediate

Identifying Invalid Provider Version Constraint

Which of the following Terraform provider version constraints will cause a syntax error?

A "^1.0"

B "~> 1.5.0"

C ">= 1.0, < 2.0"

D "= 1.5.0"

💡 Hint

Check which syntax is not supported by Terraform for version constraints.

Terraform does not support the caret (^) syntax for version constraints. Options A, C, and D are valid Terraform version constraints.

❓ Architecture

advanced

Ensuring Provider Compatibility Across Modules

You have two Terraform modules in your project. Module A requires provider version "~> 2.1", and Module B requires provider version ">= 2.0, < 2.3". Which provider version range will Terraform select to satisfy both modules?

A Any version >= 2.0 and < 3.0

B Any version >= 2.1 and < 2.3

C Any version >= 2.3

D Any version >= 2.0 and < 2.1

💡 Hint

Find the overlapping version range between both constraints.

Module A requires versions from 2.1 up to but not including 3.0. Module B requires versions from 2.0 up to but not including 2.3. The overlapping range is from 2.1 up to but not including 2.3.

❓ security

advanced

Risks of Using Loose Provider Version Constraints

What is a potential risk of specifying a very loose provider version constraint like ">= 1.0" in Terraform?

A Terraform will ignore the provider block and use a default version.

B Terraform will always use the oldest provider version, causing missing features.

C Terraform will fail to initialize due to ambiguous version selection.

D Terraform may use a newer provider version with breaking changes, causing unexpected failures.

💡 Hint

Consider what happens when new versions introduce changes.

Using a loose constraint like ">= 1.0" allows Terraform to use any newer provider version, including those with breaking changes. This can cause unexpected failures in your infrastructure code.

❓ service_behavior

expert

Terraform Provider Version Conflict Resolution Behavior

When Terraform detects conflicting provider version constraints across modules that cannot be satisfied by a single version, what is the expected behavior during terraform init?

A Terraform fails initialization with an error indicating version conflict.

B Terraform automatically picks the highest version that satisfies at least one module and ignores others.

C Terraform merges all constraints and picks the lowest common version automatically.

D Terraform downloads all conflicting versions and uses them in parallel.

💡 Hint

Think about how Terraform ensures consistent provider versions.

Terraform requires a single provider version that satisfies all constraints. If no such version exists, terraform init fails with a version conflict error.