EC2 Instance Hardening: Breaking Down the SCS-C03 Question
A practical walkthrough of the AWS Security Specialty EC2 hardening scenario: IMDSv2, Session Manager, least-privilege instance profiles, and why removing SSH is the correct call.
The exam pattern
AWS SCS-C03 repeats EC2 hardening scenarios because they combine IAM, network security, instance metadata, and operational access. The most common trap is picking an answer that reduces one risk while leaving another open—for example, keeping port 22 open but adding MFA, or using EC2 Instance Connect while still allowing inbound SSH.
Sample question
A security engineer is hardening a fleet of Amazon Linux EC2 instances. The instances currently use long-lived SSH key pairs, an inbound security group rule for port 22 from a corporate CIDR, and IMDSv1 enabled. The security team wants to remove long-lived credentials, close management ports, and reduce SSRF risk.
Which change set meets these requirements?
A. Enforce IMDSv2, attach an instance profile with the AmazonSSMManagedInstanceCore policy, remove the port 22 rule, and use Session Manager.
B. Move SSH keys to Secrets Manager, keep port 22 open, and add a NAT gateway.
C. Use EC2 Instance Connect, keep IMDSv1, and allow SSH from 0.0.0.0/0.
D. Disable IMDS, create a bastion host, and store keys on an encrypted EBS volume.
The correct answer: A
A is correct because it replaces long-lived SSH keys with short-lived, identity-aware Session Manager access. The SSM Agent makes an outbound HTTPS connection to AWS services, so you do not need an inbound SSH rule. Enforcing IMDSv2 requires token-based requests, which blocks most SSRF attacks that try to read instance metadata with a simple GET. AWS recommends IMDSv2 because it adds a session-aware request pattern that helps prevent open metadata endpoints from being abused in server-side request forgery attacks ([AWS documentation on IMDSv2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)).
The instance profile should use the AWS managed policy AmazonSSMManagedInstanceCore. Do not attach AdministratorAccess. Session Manager logs can be sent to Amazon S3 or CloudWatch Logs, and you can restrict IAM users with ssm:StartSession and a resource tag.
Why the other answers fail
B still uses long-lived SSH key material and leaves port 22 open. Secrets Manager is not a substitute for removing SSH keys; it also introduces a runtime secret retrieval path that can fail.
C improves key lifecycle but still relies on SSH, metadata, and an open management port. EC2 Instance Connect uses temporary keys, but it does not close port 22 or eliminate the risk of IMDSv1 abuse.
D disables metadata completely, which breaks many AWS-native tools and instance profile credentials. It also keeps a bastion host and SSH keys, so it does not meet the requirement to remove long-lived credentials.
Hardening checklist
Enforce IMDSv2 by setting the metadata HTTP token requirement to required.
Use Session Manager for interactive access.
Remove inbound SSH and RDP rules from security groups.
Attach a least-privilege instance profile.
Patch and scan with Amazon Inspector.
Send VPC Flow Logs and Session Manager logs to a central S3 bucket.
According to AWS, Session Manager provides access without opening inbound ports or maintaining long-lived SSH keys ([AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html)). At Sapior, we codify these controls as baseline policies so an SCS-C03-style misconfiguration fails a build before it reaches production.