A manufacturer must isolate guest, IoT and ERP traffic end to end, keep Internet transport separate from LAN, and preserve out-of-band management even if the overlay fails. Templates must map each use case to the correct VPN identifier consistently. Which VPN assignment correctly uses service VPNs, VPN 0 and VPN 512 for segmentation?

Correct design uses separate service VPNs for guest, IoT and ERP to enforce end-to-end segmentation with separate routing tables and policy, reserves VPN 0 for WAN transport to build control and data tunnels, and reserves VPN 512 for out-of-band management that stays reachable if the overlay fails. The design that manages devices in-band via VPN 0 is common to save interfaces and addresses, but it fails survivability because management then depends on the transport and control state it must troubleshoot, so an overlay outage removes access. The design that merges guest and IoT into one service VPN is common to simplify templates and share services, but it fails strict isolation because hosts share one forwarding table with direct reachability and would require extra filtering instead of native separation. The design that extends a service VPN to carry Internet transport is common for direct Internet access, but it fails underlay-overlay separation by mixing public next hops, NAT and Internet policy with LAN segmentation and weakening template consistency. For exams, remember VPN numbers are fixed roles rather than flexible labels, so VPN 0 can never act as a LAN segment and VPN 512 can never act as transport despite valid syntax. In practice, validate with running configuration, per-VPN routing tables, and a failure test proving management over VPN 512 still responds while VPN 0 tunnels are down.