A product team asks for environments in small, medium and large sizes. They should never need to know instance types or node counts, and any size other than those three must be rejected. How should the module translate the requirement into code?
Select an answer to reveal the explanation.
Short Explanation
Think of a coffee shop menu: you order a medium and the barista knows how many shots that means. A validated size input plus a lookup map gives your users the menu, not the recipe. Watch the fallback option; quietly turning a typo into large is the opposite of rejecting it.
Full Explanation
Translating business vocabulary into infrastructure is a module-interface decision. A single size variable, guarded by a validation block that accepts only small, medium and large, gives consumers the abstraction they asked for and rejects anything else with a clear error at plan time. A local map keyed by size then holds the concrete settings, so local.sizes[var.size] yields the instance type and node count in one place that the platform team can tune without changing the interface. Exposing raw instance_type and node_count variables pushes provider knowledge back onto the product team and does nothing to stop a value outside the three sizes. Publishing three module copies multiplies maintenance and still leaves teams choosing between implementations rather than expressing a requirement. A conditional on every argument scatters the mapping across the configuration, and silently falling back to large converts an invalid input into an expensive environment instead of rejecting it. Exam caveat: validation conditions should reference the variable being validated, so keep the allowed list next to the variable declaration. Operational check: run terraform plan with size set to an unsupported value and confirm it fails with the validation message, then run it with medium and confirm the expected instance type appears.