A platform team is building a shared storage bucket module for 30 application teams. Security requires that server-side encryption and public access blocking are always present on every bucket the module creates, with no way for a caller to turn them off. How should the module implement these guardrails?

A shared module is an effective place to encode organizational guardrails because every caller gets them without writing extra code. When a control must always be present, the module should create the supporting resources unconditionally and expose no input that disables them, so the secure configuration is a fixed part of the module's behavior rather than a caller's choice. Inputs remain for the things that legitimately vary, such as name and lifecycle rules. Feature-flag variables that default to true are still flags: any caller can set them to false, and a README instruction does not enforce anything, so the stated requirement of no opt-out is not met. Pushing the controls back to each team defeats the purpose of the module and guarantees inconsistency across 30 teams. Provider default tags apply tag key-value pairs to supported resources; tags are metadata and cannot configure encryption or block public access. Exam caveat: module defaults prevent accidental misconfiguration, while a plan-time policy is still the backstop that catches buckets created outside the module, so the two controls complement each other. Operational check: call the module with only its required inputs in a test, plan it, and assert that the encryption configuration and public access block appear for the bucket.