SY0-701 Question 208
Single answerA company is replacing its legacy remote-access VPN concentrator. The security team wants remote employees to connect from unmanaged home networks without installing a full tunnel client, while still ensuring the connection is encrypted and users can be authenticated before accessing an internal web-based ticketing system. The solution must work reliably through hotel and home NAT devices and should require the fewest firewall exceptions on the client side. Which solution BEST meets these requirements?
- A
Deploy an SSL/TLS VPN portal over HTTPS for browser-based remote access to the ticketing application
- B
Deploy a site-to-site IPSec VPN using ESP tunnel mode from each employee laptop to the corporate firewall
- C
Use L2TP without IPSec so users can connect natively from most operating systems without additional software
- D
Implement an SD-WAN overlay from employee laptops directly to the data center for application access
Show answer and explanation
Correct answer: A
Explanation
The best answer is an SSL/TLS VPN portal over HTTPS because the scenario emphasizes remote user access to an internal web application, operation across home and hotel NAT environments, strong encryption, user authentication, and minimal client-side changes. TLS-based remote access aligns well with those goals by using standard HTTPS on TCP 443, which is commonly permitted through outbound firewalls and proxies. By contrast, IPSec is highly effective for secure tunneling but is more commonly associated with site-to-site connectivity or full remote-access clients, and it can require NAT-T and additional configuration to work smoothly across NAT devices. L2TP alone does not provide confidentiality and therefore does not meet basic security requirements. SD-WAN is valuable for branch and WAN path optimization, segmentation, and overlay networking, but it is not the most appropriate primary answer for lightweight browser-based remote access to a single internal web service. These distinctions are consistent with common enterprise remote-access practices and with guidance from protocol documentation such as RFC 8446 for TLS 1.3 and RFC 4301 for the IPSec security architecture.
- A. Correct.
Correct. An SSL/TLS VPN portal delivered over HTTPS is well suited for remote access to a web-based internal application when the organization wants to avoid a full tunnel client. TLS-based remote access commonly traverses NAT and restrictive firewalls more easily because it uses TCP 443, which is typically already allowed outbound. It also supports user authentication before granting access. This directly matches the requirements for encrypted access, minimal client-side firewall exceptions, and browser-based connectivity.
- B. Incorrect.
Incorrect. Site-to-site IPSec VPNs are designed primarily to connect networks to networks, not individual roaming users on unmanaged home networks. Although remote-access IPSec solutions exist, this option specifically describes site-to-site use from each laptop, which is not the right deployment model. In addition, IPSec can be less NAT-friendly unless NAT traversal is used, and it typically requires more configuration than a browser-based TLS portal.
- C. Incorrect.
Incorrect. L2TP by itself does not provide encryption; it is a tunneling protocol, not a secure one. In practice, L2TP is paired with IPSec when confidentiality is required. Choosing L2TP without IPSec fails the requirement to ensure the connection is encrypted. This distractor targets the common misconception that tunneling alone implies security.
- D. Incorrect.
Incorrect. SD-WAN is primarily used to manage connectivity and routing across distributed sites, branches, and transport links. It is not the best fit for providing simple browser-based remote access from individual employee laptops to a single internal web application. While some SD-WAN platforms include remote-user features, that is not the core or most appropriate solution described by the scenario.