New cloud resources for a smart-city project sometimes appear with open security groups. What automation pattern best hardens them at birth?
Select an answer to reveal the explanation.
Short Explanation
Guard rails are the automatic seatbelts that click on when a new cloud box rolls off the line—secure security groups and policies land without hoping someone remembers later.
Full Explanation
Smart-city cloud resources that appear with open security groups create immediate Internet exposure. Guard rails and baseline security groups applied automatically at provision time—via policy-as-code, landing-zone controls, infrastructure-as-code modules, or cloud organization policies—ensure new resources inherit deny-by-default network controls and approved baselines without relying on later human memory. Birth-time hardening is the automation pattern that prevents 'we will lock it down after launch' drift on municipal cloud projects.
Allowing any developer to publish 0.0.0.0/0 rules without review forever institutionalizes exposure. Waiting six months after launch before attaching network controls leaves a long unprotected window. Documenting insecure defaults in a wiki without technical enforcement is paperwork without control.
Exam caveat: guard rails should allow approved exceptions through change control, not shadow IT bypasses; overly rigid policies that teams routinely evade fail in practice. Combine preventive policies with detective drift detection for resources changed after creation.
Operational check: enforce organization policies or IaC modules that attach baseline security groups/NSGs on create, block unrestricted ingress by default, alert on public-open rules, and scan the smart-city subscription for resources missing the mandatory baselines.