A bank operates isolated EC2 instances in private subnets with no internet, where developers currently share SSH keys via bastion hosts violating audit. They need audited shell access without opening inbound ports or managing keys. Which administrative access method should the architect configure for secure compute?

The correct design succeeds because Session Manager uses outbound-only TLS to Systems Manager, requiring no inbound ports or bastion, replacing shared SSH keys with IAM authentication, preserving isolation via interface VPC endpoints for ssm, ssmmessages and ec2messages, and capturing full session data in S3 with KMS encryption for tamper-evident audit, satisfying every constraint together. The Instance Connect Endpoint design offers IAM-controlled SSH without public IPs and CloudTrail events, yet it fundamentally still opens SSH on port 22 from the endpoint and relies on short-lived pushed keys, violating the zero-inbound and zero-key goals. The hardened bastion design with MFA and S3 recording is an accepted hardening pattern that improves accountability, but it retains inbound SSH, patching, scaling, and credential lifecycle overhead the scenario explicitly seeks to eliminate. The internet-based Session Manager design delivers keyless audited shells to CloudWatch, but depending on a gateway or NAT for API reachability directly breaks the no-internet isolation and introduces egress exposure. For exams, distinguish no-inbound browser shells from IAM SSH that still needs port 22, and treat any internet gateway, NAT, or public IP as disqualifying for isolated subnets; in practice confirm SSM Agent health, instance profile with AmazonSSMManagedInstanceCore, endpoint resolution, and verified S3 KMS log delivery before removing bastions.