Transit IT compares a ticket-driven VLAN request that takes weeks with a segment created from the NSX UI or API in minutes. Which core SDDC concept does that contrast identify?
Select an answer to reveal the explanation.
Short Explanation
Weeks for a VLAN ticket versus minutes for an NSX segment is the whole agility pitch. SDDC provisioning is software and APIs, not a chassis change request that sits in a queue.
Full Explanation
Transit IT comparing a weeks-long VLAN ticket with a segment created from the NSX UI or API in minutes is identifying programmatic, rapid provisioning of infrastructure services versus slow ticket-driven hardware changes. That agility is a core SDDC outcome: network constructs become software objects under change control that fits software timelines for civic projects. Claiming hardware tickets are faster because they skip change control is false and unsafe. Waiting for a new chassis before any segment exists reasserts the forklift model. Treating API-created segments as a Workspace ONE UEM enrollment workflow confuses device management with network virtualization. Exam caveat: overlay creates still deserve change records; "minutes" describes the technical path length, not an excuse to bypass municipal CAB for production transit systems. Operational check: measure time-to-segment for a non-prod transit request via NSX versus the historical VLAN ticket median, and document that underlay was unchanged. 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.