Remote municipal IT admins need encrypted user-level access from laptops into VPC private resources for after-hours support. Site-to-Site VPN already links headquarters, but individual teleworkers are not on that office network. What should the architect provide?
Select an answer to reveal the explanation.
Short Explanation
Headquarters already has a Site-to-Site tunnel; teleworkers need their own secure on-ramp. Client VPN is that per-user tunnel into the VPC—without opening SSH to the whole Internet.
Full Explanation
Remote municipal IT admins who need encrypted user-level access from laptops into VPC private resources—and who are not sitting on the headquarters Site-to-Site VPN—need a client VPN model. AWS Client VPN lets each teleworker authenticate and establish a secure TLS VPN session into the VPC, reaching private administrative endpoints for after-hours support without placing the entire home network on the office Site-to-Site link. Site-to-Site remains appropriate for the headquarters network; Client VPN addresses people, not just sites.
Disabling all remote access and requiring physical presence fails operational reality for after-hours civic support. Publishing RDP/SSH of every instance on 0.0.0.0/0 without VPN exposes management planes to the internet. Replacing IAM entirely with shared local OS passwords emailed weekly destroys identity accountability and secrets hygiene.
Exam caveat: Client VPN still requires authorization rules, subnet associations, and strong identity federation (for example, Active Directory or SAML). It does not replace Session Manager as another hardening option, but the stem asks specifically for user VPN into the VPC. Site-to-Site and Client VPN solve different endpoint types.
Operational check: enroll a pilot admin on Client VPN with MFA-backed identity; confirm access only to intended private subnets; revoke a user and verify access ends; and keep Site-to-Site for HQ while Client VPN covers teleworkers during emergency change windows.