002 · Domain 3: Infrastructure Lifecycle and Operations · 22% of the exam
Task 3.8: Input and output data from infrastructure projects
Passing data between projects: outputs and terraform_remote_state, data sources as the looser coupling, module inputs and outputs, and count-dependent references.
Study it
Data between projects: outputs, remote state and data sources
Lesson coming
Sample questions
Try each one before opening the answer. Every option is explained, with the HashiCorp documentation page that proves it.
Question 1 · choose 1
A network configuration must share its VPC and subnet IDs with three consumers: two Terraform configurations and a deployment tool that is not Terraform. None of the consumers may get read access to the network state. Which approach fits?
AExpose root outputs and have every consumer read them through the terraform_remote_state data source
BCommit the IDs to a shared .tfvars file that each consumer copies
CGive each consumer a copy of the state file with sensitive attributes removed
DPublish the IDs with aws_ssm_parameter resources and read them with the matching data source
Show the answer and why
AExpose root outputs and have every consumer read them through the terraform_remote_state data source
Incorrect
Reading root outputs through remote state requires access to the whole state snapshot, and the non-Terraform tool cannot use the data source.
BCommit the IDs to a shared .tfvars file that each consumer copies
Incorrect
Hard-coded copies must be updated by hand whenever the network changes, which HashiCorp advises against.
CGive each consumer a copy of the state file with sensitive attributes removed
Incorrect
Copied state goes stale immediately and still exposes state structure; HashiCorp recommends publishing data explicitly instead.
DPublish the IDs with aws_ssm_parameter resources and read them with the matching data source
Correct
A separate configuration store lets you apply its own access controls, and other systems besides Terraform can read the same values.
terraform_remote_state is convenient but needs full state access. Pairs of managed resources and data sources, such as SSM parameters, DNS records or config maps, publish only what consumers need.
A module's subnet_ids output sometimes returns a map after a refactor, breaking callers that expect a list of strings. Which change makes the mistake fail inside the module?
AMark the output sensitive = true
BAdd a description stating the expected type
CConvert the value to a list in each caller
DAdd type = list(string) to the output
Show the answer and why
AMark the output sensitive = true
Incorrect
Sensitivity hides values; it does not check types.
BAdd a description stating the expected type
Incorrect
Descriptions document intent but are not enforced.
CConvert the value to a list in each caller
Incorrect
That moves the problem to callers instead of the module.
DAdd type = list(string) to the output
Correct
An output's type argument constrains the value it accepts; without one, the output accepts any type.
Output types tell consumers what the module produces and catch mistakes close to their source.