A county operations team still bastions into EC2 with long-lived SSH keys and shared jump hosts, and auditors want session logging without opening inbound SSH. Which continuous-improvement change best meets that requirement?
Select an answer to reveal the explanation.
Short Explanation
Think of SSH keys like spare house keys floating around the county—Session Manager is the badge reader that logs who walked in. Operators authenticate with IAM, no inbound 22, and sessions can land in CloudWatch or S3 for the auditors. That is how you retire snowflake bastions without giving up ops access.
Full Explanation
County operators still bastioning into EC2 with long-lived SSH keys and shared jump hosts create audit and inbound-SSH exposure problems. Replacing inbound SSH with AWS Systems Manager Session Manager provides IAM-authenticated sessions and session logging to CloudWatch Logs or S3 without opening inbound SSH ports. That continuous-improvement change meets auditor needs because access is identity-based, logged centrally, and network attack surface shrinks. Keeping SSH keys but rotating weekly while storing private keys in a shared S3 bucket fails by concentrating credential theft risk in a widely readable object store. Opening SSH from 0.0.0.0/0 during business hours with security groups maintained by email fails conceptually as an unbounded inbound posture with weak change control. Moving all municipal servers onto a single always-on bastion with password authentication and no MFA fails as a high-value target with weak authentication. Exam caveat: Session Manager still needs SSM Agent, network path to endpoints or NAT, and IAM permissions; logging must be enabled and retained to satisfy auditors—not merely switching tools. Operational check: disable inbound SSH on a pilot ASG, require Session Manager, verify session logs land in the approved bucket or log group with user identity, and revoke shared SSH key distribution for that fleet.