Free Remote Access Technologies practice questions

TCP 3389 is the port used by the Remote Desktop Protocol (RDP), Microsoft's proprietary remote desktop technology built into Windows. RDP is efficient because it sends drawing commands, compresses graphics primitives, and caches bitmaps rather than streaming raw video, making it perform well even over limited bandwidth. It is also encrypted with TLS by default, which makes it ideal for securely administering Windows servers and workstations in a managed environment. TCP 22 is used by Secure Shell (SSH), which provides an encrypted command-line session primarily to Linux, Unix, and network devices—not a graphical Windows desktop. TCP 5900 is used by Virtual Network Computing (VNC), a cross-platform screen-sharing system built on the Remote Frame Buffer protocol that shares the actual framebuffer of the current display, but it is not encrypted by default and is less bandwidth-efficient. TCP 5985 is used by Windows Remote Management (WinRM) over HTTP, which handles remote command and script execution via PowerShell Remoting rather than providing a graphical desktop. Because the scenario requires a built-in, encrypted, bandwidth-efficient graphical remote desktop for Windows, RDP on TCP 3389 is the correct answer.

Windows Remote Management (WinRM) is Microsoft's implementation of the WS-Management protocol and is the engine behind PowerShell Remoting, using cmdlets such as Enter-PSSession and Invoke-Command. WinRM lets an administrator run commands, scripts, and management queries against remote Windows machines at scale without a graphical session, and it integrates tightly with Active Directory to authenticate using domain credentials. This makes it ideal for pushing a fix or script to many workstations at once. VNC is a cross-platform screen-sharing tool that transmits pixel updates of a single desktop and does not execute batch commands or scripts across a fleet. SSH provides an encrypted command-line session to a single host and is the standard for Linux and Unix systems, though modern Windows can run an OpenSSH server; however, it is not the native PowerShell Remoting engine described here. RDP delivers a graphical remote desktop session to one machine at a time and cannot run scripts simultaneously against many machines. Because the task involves native Windows automation via PowerShell Remoting across many systems, WinRM is the correct technology.

A client-to-site VPN creates an encrypted tunnel across the untrusted internet that makes a single remote device behave as if it were plugged directly into the private corporate LAN. This lets the employee reach internal file shares and internal RDP hosts through the tunnel without exposing those services to the open internet, and a VPN acts as the secure container inside which other remote-access tools run. Port forwarding on the perimeter router would directly expose the internal services to the internet, which is the opposite of the security goal and makes RDP a prime target for attackers. A cloud relay screen-sharing session brokers a graphical remote-support connection through a vendor's servers for attended support, but it does not extend general network access to internal file shares. An SSH tunnel could secure a single protocol like VNC to one host, but it is not the standard method for giving a remote device broad membership on the corporate network to reach multiple internal resources including file shares. Because the requirement is to securely extend the private network to a remote device without exposing services, a client-to-site VPN is the correct answer.

A cloud relay screen-sharing application, such as TeamViewer or AnyDesk, is the most appropriate choice because both the technician and the user make outbound connections to the vendor's relay server, typically over TCP 443/HTTPS. This traverses firewalls and NAT with no port forwarding required, which is critical when the technician does not manage the home router. The user reads out a session ID and one-time code, so the connection requires the user's active consent, and the user watches the same screen while the fix is performed—ideal for attended support and teaching. An RDP session expects a direct network path to the host and would require firewall rules or port forwarding across the home network, plus the Home edition of Windows cannot host RDP. Opening a VNC session directly to the framebuffer also expects a direct network path and would require exposing port 5900 through the router, and base VNC is not encrypted by default. A WinRM PowerShell session provides command-line automation, not a visible attended session the non-technical user can observe, and it also expects reachable ports on the target. Because the scenario needs consent-based, firewall-friendly, observable support, a cloud relay screen-sharing tool is correct.

Virtual Network Computing (VNC) is a cross-platform screen-sharing system built on the Remote Frame Buffer (RFB) protocol that runs on Windows, macOS, Linux, and Unix, making it ideal for mixed-OS environments. VNC shares the actual framebuffer of the host's current display, so it is a true remote control model where the remote viewer and the local user see the very same desktop and can both watch simultaneously. This is exactly what is needed when a local user should observe the control session. RDP is Microsoft's proprietary protocol that normally creates a private virtual session and locks the local console, so the end user standing at the machine typically cannot watch the remote session; it also is not the natural cross-platform choice for Linux and macOS hosts. WinRM is a Windows-only remote command and script execution engine using WS-Management and does not provide a shared graphical desktop across platforms. SSH provides an encrypted text-based command-line session, not a graphical desktop that a local user can watch. Because the requirement is cross-platform graphical remote control with a shared, observable desktop, VNC is the correct answer.

Windows Home editions cannot act as an RDP host, which is why the option to allow incoming Remote Desktop connections is missing. Only the Professional and higher editions—Pro, Enterprise, and Education—can receive incoming Remote Desktop connections. A Home edition device can still run the Remote Desktop Connection client and connect outward to a host, but it cannot host a session itself. Joining an Active Directory domain is not required to enable RDP hosting; the capability is tied to the Windows edition, not domain membership, and Home editions cannot join a domain anyway. A blocked TCP port 3389 in Windows Firewall would prevent connections from succeeding, but it would not cause the enable option itself to be absent from the settings. The Remote Desktop Connection client (mstsc.exe) is included on all Windows editions including Home, so its absence is not the issue and it relates to connecting out rather than hosting. Because the missing host capability is a fundamental edition limitation, the correct answer is that Windows Home editions cannot act as an RDP host.

TCP 5986 is the WinRM port for HTTPS, providing the secure, certificate-backed transport that is recommended for connections crossing trust boundaries. While WinRM traffic over the HTTP port is encrypted at the message level when using standard domain (Kerberos/Negotiate) authentication, the certificate-backed transport encryption required by the policy is only available over HTTPS on port 5986. TCP 5985 is the WinRM HTTP port, which relies on message-level encryption rather than certificate-backed transport, so it does not meet the stated requirement. TCP 3389 is the Remote Desktop Protocol port used for graphical Windows sessions, not for WinRM management traffic. TCP 443 is the standard HTTPS port commonly used by SSL VPNs and cloud relay screen-sharing tools, but it is not the dedicated WinRM HTTPS port. Because the policy specifically demands certificate-backed transport encryption for WinRM across a trust boundary, the connection must use TCP 5986.

Tunneling the VNC session through SSH is the correct action because base VNC is not inherently encrypted, and wrapping it inside an encrypted SSH connection on port 22 protects the otherwise-plaintext screen data as it crosses the network. SSH supports port forwarding specifically for this purpose, allowing protocols like VNC to ride securely inside the encrypted tunnel. Using a VPN would accomplish the same goal, but among the choices, SSH tunneling is the direct method. Changing the VNC display port from 5900 to 5901 only selects a different display number and does nothing to encrypt the traffic. Enabling VNC password authentication is misleading because many VNC implementations only encrypt the initial password exchange, leaving the actual session data in the clear, so the screen content would still be exposed. Routing VNC traffic over TCP port 3389 is invalid because 3389 is the RDP port; simply changing the destination port number does not add encryption or make VNC use RDP. Because the policy requires encrypting the VNC screen data while continuing to use VNC, tunneling it through SSH is the correct answer.

Connecting over the VPN first and then using SSH or WinRM to reach the target reflects the layered defense best practice. A VPN acts as the encrypted wrapper that gives the device virtual membership on the private network, so the management protocols themselves are never directly exposed to the public internet. Once inside the tunnel, SSH handles Unix-like hosts and WinRM handles Windows systems, keeping those channels shielded behind the VPN. Connecting via SSH first and then establishing the VPN reverses the correct order, because the VPN must be the outer secure container established before reaching internal management services. Exposing RDP directly and relying on TLS encryption alone leaves the RDP port as an internet-facing target that attackers actively scan for and attempt to brute force, so encryption alone does not eliminate the exposure risk. Forwarding ports 22 and 5986 through the firewall to each host directly publishes the SSH and WinRM services to the internet, which is exactly the exposure the layered model is designed to prevent. Because best practice keeps management protocols behind the VPN, connecting over the VPN first and then using SSH or WinRM is correct.

Remote Monitoring and Management (RMM) is the platform that powers managed, unattended support. An RMM agent installed on each endpoint continuously reports status to a central console, letting a small team monitor hardware health, deploy patches on a schedule, run maintenance scripts across groups, and jump into any device—all from one pane of glass. This is exactly the model MSPs use to manage large fleets proactively. An ad-hoc screen-sharing tool is reactive and requires a user to grant a one-time attended session, so it cannot proactively monitor or patch hundreds of machines automatically. SPICE is a remote-display protocol for reaching the console of Linux-based virtual machines and VDI, not a fleet-management platform for physical workstations. VNC provides cross-platform screen control of a single machine at a time and offers no monitoring, patching, scripting, or centralized inventory, so it does not scale to proactive management of 800 endpoints.