Twelve branch offices must send internal traffic to workloads in the organization's virtual network in a public cloud. That traffic currently crosses the internet unencrypted, and dedicated private circuits are not in the budget. What is the most appropriate solution?
Select an answer to reveal the explanation.
Short Explanation
When you can't afford a private road, you build an armoured tunnel through the public one. A site-to-cloud IPsec VPN encrypts and authenticates everything between each branch and the virtual network. The trap is tools that filter, sign names or watch traffic without ever encrypting it.
Full Explanation
A site-to-site virtual private network, here between each branch office gateway and the cloud virtual network's VPN gateway, creates encrypted, mutually authenticated tunnels across the internet. IPsec provides confidentiality, integrity and peer authentication for all traffic between the two private address spaces, and keeps the workloads on private addresses rather than exposing them publicly. Publishing internal workloads through a public load balancer moves them onto the internet; source IP restrictions narrow who can connect, but traffic is not encrypted unless every application adds TLS, and the workloads' attack surface grows. DNSSEC protects the integrity and origin of DNS answers only; it has no effect on the confidentiality or integrity of the application traffic that follows a lookup. An intrusion detection sensor observes and alerts; it provides no encryption and would itself be inspecting plaintext sensitive data crossing the internet. Exam caveat: dedicated interconnects provide private, predictable connectivity but are not inherently encrypted; where encryption is required, a VPN or TLS may still be layered on top. Operational check: confirm that each tunnel uses strong IKE and IPsec parameters with certificate or strong pre-shared key authentication, that routing sends cloud-bound branch traffic only through the tunnel, and that tunnel status and failures are monitored.