Municipal 311 developers want self-service virtual network constructs for a test environment without waiting on the core-switch team. Which SDDC capability should they identify?
Select an answer to reveal the explanation.
Short Explanation
Test networks should be a self-serve kiosk, not a ticket to the core-switch team. Authorized operators create virtual constructs in software without touching the chassis for every request.
Full Explanation
Municipal 311 developers wanting self-service virtual network constructs for test environments without waiting on the core-switch team are identifying authorized self-service creation of virtual networks without a physical core-switch change for every request. In an SDDC, RBAC-scoped operators or automation can create overlay segments for non-prod work while the underlay remains stable. Opening a weeks-long VLAN ticket for every test network is the bottleneck being removed. Publishing the app as a Horizon desktop may avoid a server network for UI testing but does not provide the virtual network constructs developers asked for. NATing all test VMs onto the production VLAN from the internet edge is unsafe and not self-service network virtualization. Exam caveat: self-service must still be authorized, quota-limited, and audited in municipal environments. Operational check: grant a 311 non-prod role rights to create a test segment and confirm creation succeeds without a core VLAN change while production remains untouched. 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.