A parks department needs identical Wi-Fi SSID definitions across twelve park sites without copying the same block into twelve separate files. What IaC reusability approach should they use?

Infrastructure-as-code reusability for identical Wi-Fi SSID definitions across twelve park sites centers on a parameterized shared module. Each park stack calls that module with site-specific inputs—park name, VLAN, RADIUS realm, or captive-portal URL—while the SSID construction, security mode, and logging hooks remain defined once. Updates to the shared module propagate consistently on the next apply instead of requiring twelve manual edits.

Twelve independent copy-pasted SSID stanzas look fast on day one and fail on day thirty: one park receives WPA3 hardening while another keeps the old passphrase policy, and nobody can prove which file is authoritative. A single hard-coded SSID string with no parameters cannot express legitimate site differences without forking the whole stack or inventing brittle conditionals outside the module boundary. Ad-hoc CLI commands on each access controller leave no shared definition at all; they are imperative snowflakes that IaC was meant to eliminate.

Exam caveat: a shared module is not “one global apply that blindly overwrites every park.” Parameters exist precisely so municipal sites stay consistent where policy requires consistency and differ where topology requires difference. Over-parameterizing every trivial string can also obscure the shared contract—keep inputs to what genuinely varies per park.

Operational check: change one shared SSID attribute in the module, plan/apply two sample park stacks, and verify both controllers show the new definition while site-specific inputs remain distinct. Diff the generated config against a third park that was not yet applied to confirm reuse, not copy-paste drift.