A logistics site has MPLS, Internet, and LTE transports. Dispatch traffic must use MPLS primarily with LTE as backup, while guest traffic must use Internet only. Centralized data policy already matches the apps. Which TLOC list design best steers traffic to the specific transports?

The correct design works because centralized data policy steers already-matched application prefixes by setting the next-hop transport via TLOC lists referenced in the forward action, so creating one list that contains MPLS TLOCs preferred first with LTE TLOCs as backup gives dispatch the required primary-backup behavior while a second list containing only Internet TLOCs constrains guest traffic to Internet only. Grouping MPLS with Internet for dispatch is conceptually valid for load sharing but fails the backup requirement by steering dispatch failover to Internet instead of LTE, violating strict transport separation and LTE-as-backup intent. Grouping MPLS alone and LTE with Internet fails isolation by leaving dispatch without defined backup and by mixing guest Internet with LTE, which would allow guest to use LTE and break the Internet-only constraint. Using the same correct TLOC groupings but applying them as local actions in application-aware routing policy fails by mechanism because application-aware routing selects best path based on SLA measurements and local decisions, whereas the scenario explicitly states centralized data policy already matches apps and requires forwarding enforcement from the controller. As an exam caveat, do not confuse list type with match criteria, since data, application, site, VPN, and TLOC lists have distinct roles and only the TLOC list defines transport next-hops for forwarding. As a practical check, verify colors and encapsulation for MPLS, Internet, and LTE TLOCs on the logistics routers, confirm sequence order with primary and backup preference, then test dispatch failover by shutting MPLS and confirm guest stays on Internet during packet captures.