Stage and prod workspaces each call the company's network module from the private registry. Platform wants prod to receive exactly the module code that was already applied and verified in stage, with no edits in between. Which promotion approach meets this?
Select an answer to reveal the explanation.
Short Explanation
Promotion means you ship the same box twice, and a version number is the label that proves it's the same box. Pin it in stage, prove it, then pin the same version in prod.
Full Explanation
Modules from a registry, including the HCP Terraform private registry, are versioned, and a module block can pin an exact version. Promoting by version means stage moves to the new release first and is applied and verified; prod is then changed to the identical version in a small, reviewable change, so prod receives byte-for-byte the code that stage proved. Combined with workspace settings such as manual apply on prod, or a run trigger that queues prod after stage applies, this gives a controlled path between environments. Copying directories and editing them by hand re-introduces exactly the drift that promotion is meant to avoid, because the prod copy can diverge with each edit. Omitting version means prod resolves to the newest available release on each init, so a version published but never tested in stage could reach prod automatically. terraform_remote_state reads outputs from another workspace's state; it does not copy or manage that workspace's resources, so prod would have no infrastructure of its own. Exam caveat: the dependency lock file records providers, not modules, so module pinning must be done with the version argument. Operational check: after raising prod's pin, confirm terraform init downloads the expected version and that the prod plan shows the same kinds of changes that stage applied.