A national retailer with 180 small stores plans DIA for point-of-sale cloud access and guest browsing. All Internet traffic must receive URL filtering and malware inspection. Store WAN Edges run high CPU, sites have no local security staff, and MPLS bandwidth is limited. Which DIA security enforcement design should the engineer choose?
Select an answer to reveal the explanation.
Short Explanation
You’re offloading heavy lifting without losing control here. Branch devices can’t handle inspection and you’ve got no hands on site, so cloud enforcement keeps you fast and covered with centralized-policy control.
Full Explanation
The correct design is optimal because forwarding local DIA breakouts over automated tunnels to a cloud security platform provides full centralized URL filtering and malware inspection without using limited MPLS, without loading WAN Edges already high in CPU, and without needing local staff for updates and operations. Enforcing integrated threat prevention directly on each store WAN Edge under controller management is a standard branch simplification, yet it fails on resource fit because on-box decryption, categorization and sandboxing add significant CPU and memory to constrained routers and increase local troubleshooting. Sending store Internet traffic to a regional hub firewall cluster for centralized inspection is a proven pattern for consistent control, yet it fails on transport fit because it trombones guest and cloud traffic across scarce MPLS and overlay capacity and adds latency to POS cloud access. Using cloud DNS-layer filtering with centralized logging is a common lightweight scaling method, yet it fails on functional scope because DNS policy plus visibility cannot replace proxy-based URL filtering and file malware inspection required for all traffic. For exams, routing control or DNS security does not equal full inspection, and in practice confirm tunnel automation, redundancy, TLS inspection coverage, and that no local breakout path can bypass the cloud inspection chain.