A municipal court project wants a repeatable blueprint of a segment, gateway, and firewall policy instead of a unique physical design each time. Which SDDC concept is that request?
Select an answer to reveal the explanation.
Short Explanation
The court wants a cookie cutter, not a custom recable for every new app. SDDC building blocks—segment, gateway, firewall policy—are software you stamp out again.
Full Explanation
A municipal court project that wants a repeatable blueprint of a segment, gateway, and firewall policy is asking for repeatable software building blocks rather than a unique physical design per application. In an SDDC, those objects are composable catalog items stamped out for each court workload with consistent security and connectivity patterns. One-off physical recabling for every new court application is the traditional cost the blueprint avoids. Publishing the app as a Horizon desktop may change access method but does not supply the network blueprint. Copying a physical switch running-config by hand into each new rack reintroduces fragile, device-centric repetition. Exam caveat: blueprints still need standards for naming, IPAM, and Tier-0/Tier-1 design; repeatability is not a substitute for architecture review on court systems. Operational check: deploy the same segment-gateway-DFW pattern twice for two court apps and confirm both land consistently via automation or documented API/UI steps without unique cabling designs. Keep municipal naming and change tickets aligned with the software objects so civic audits can trace intent. Prefer verifying with a non-production agency workload before promoting the same pattern to life-safety systems.