The city's cloud team uses infrastructure-as-code templates to deploy identical hardened network baselines for each department. Which security implication is most accurate?

Infrastructure-as-code (IaC) lets the city's cloud team deploy identical hardened network baselines repeatedly, which improves consistency, reduces snowflake drift, and makes secure defaults reviewable in source control. That consistency is a genuine security benefit for departmental environments that must meet the same segmentation and logging standards. The matching risk is replication at scale: a flawed template—open security group, missing flow logs, overly broad IAM role—can stamp the same weakness across every department deployment before anyone notices a single misconfigured console click. Security+ links secure coding and automation concepts to configuration management: automation amplifies both good and bad patterns.

Claiming IaC eliminates all misconfiguration risk because templates cannot contain errors ignores human authoring mistakes and incomplete modules. Saying IaC is only documentation with no effect on builds misunderstands that pipelines actually provision resources from those definitions. Requiring that version control be disabled so operators can change production faster removes peer review, change history, and rollback—the governance mechanisms that make IaC safer than ad-hoc clicks.

Exam caveat: automation questions often contrast "consistency" with "blast radius"; both ideas matter, and the accurate statement usually includes the scaled-flaw caveat. Operationally, keep templates in reviewed repositories, run policy-as-code or static checks in CI, require approvals for privileged modules, scan for public exposure patterns, and periodically reconcile deployed state against declared baselines so drift and template defects surface early.