While preparing for the AWS SAP-C02, many candidates get confused by SSH hardening strategies. In the real world, this is fundamentally a decision about Security Perimeter vs. Audit Depth vs. Operational Friction. Let’s drill into a simulated scenario.
The Scenario #
NexusCore Analytics, a fast-growing AI/ML startup, operates a cluster of 45 Amazon EC2 instances (Amazon Linux 2) in private subnets across a VPC. Their data science engineers frequently SSH into these instances for model debugging and troubleshooting. The current architecture includes:
- A VPC with public and private subnets, plus a NAT Gateway for outbound internet access
- A Site-to-Site VPN connecting the VPC to the company’s on-premises office network
- EC2 security groups configured to allow SSH (TCP/22) from the on-premises network CIDR range
The newly appointed CISO has mandated two immediate improvements:
- Enhance SSH security posture to meet SOC 2 Type II compliance requirements
- Implement comprehensive audit logging of all commands executed by engineers on production instances
The VP of Engineering insists that any solution must NOT increase operational friction or require engineers to learn entirely new workflows.
Key Requirements #
Strengthen SSH access controls, enable full command audit capabilities, and minimize the attack surface—while maintaining engineer productivity and operational simplicity.
The Options #
-
A) Install and configure EC2 Instance Connect on all instances. Remove all inbound TCP/22 security group rules. Train engineers to use the EC2 Instance Connect CLI for remote access.
-
B) Update EC2 security groups to allow inbound TCP/22 only from specific engineer device IP addresses. Install the Amazon CloudWatch agent on all instances and configure OS-level audit logs to stream to CloudWatch Logs.
-
C) Update EC2 security groups to allow inbound TCP/22 only from specific engineer device IP addresses. Enable AWS Config to monitor EC2 security group resource changes. Enable AWS Firewall Manager to apply security group policies that automatically remediate unauthorized rule changes.
-
D) Create an IAM role with the AmazonSSMManagedInstanceCore managed policy attached and associate it with all EC2 instances. Remove all inbound TCP/22 security group rules. Have engineers install the AWS Systems Manager Session Manager plugin on their workstations and use the
start-sessionAPI to remotely access instances.
Correct Answer #
D.
Step-by-Step Winning Logic #
This solution achieves all three core requirements simultaneously:
-
Eliminates the attack surface: By removing all inbound TCP/22 rules, you close the traditional SSH port entirely. No exposed listening service = no brute-force risk, no vulnerability to SSH daemon exploits.
-
Identity-based security: Access control shifts from network-layer (IP whitelisting) to identity-layer (IAM policies). Engineers authenticate via IAM, and you can enforce MFA, session duration limits, and granular instance-level permissions.
-
Built-in audit at zero incremental cost: Session Manager automatically logs all session activity to CloudTrail (who connected, when, to which instance) and can stream full command-level logs to CloudWatch Logs or S3 without requiring CloudWatch agent installation. This is a native SSM capability.
-
Operational simplicity: Engineers install a single lightweight plugin and use familiar CLI syntax:
aws ssm start-session --target i-0abc123. The workflow is nearly identical to SSH, minimizing friction. -
VPN independence: Session Manager uses outbound HTTPS (443) to the Systems Manager service endpoint. Engineers can connect from anywhere with AWS CLI credentials—no VPN required. This supports remote work scenarios without additional infrastructure.
💎 Professional-Level Analysis #
This section breaks down the scenario from a professional exam perspective, focusing on constraints, trade-offs, and the decision signals used to eliminate incorrect options.
🔐 Expert Deep Dive: Why Options Fail #
This walkthrough explains how the exam expects you to reason through the scenario step by step, highlighting the constraints and trade-offs that invalidate each incorrect option.
Prefer a quick walkthrough before diving deep?
[Video coming soon] This short walkthrough video explains the core scenario, the key trade-off being tested, and why the correct option stands out, so you can follow the deeper analysis with clarity.
🔐 The Traps (Distractor Analysis) #
This section explains why each incorrect option looks reasonable at first glance, and the specific assumptions or constraints that ultimately make it fail.
The difference between the correct answer and the distractors comes down to one decision assumption most candidates overlook.
-
Why not Option A (EC2 Instance Connect)?
- Partial audit gap: EC2 Instance Connect provides temporary SSH key injection and logs connection events to CloudTrail, but it does NOT log commands executed during the session. You’d still need CloudWatch agent + OS audit logs to meet the “comprehensive command audit” requirement.
- Port 22 still required: Instance Connect still uses SSH protocol (TCP/22). While the inbound rule can be restricted to AWS IP ranges, the SSH daemon remains active and exposed.
- Region/AZ dependency: Instance Connect relies on AWS service endpoints in the same region; Session Manager has broader availability and better failure domain isolation.
-
Why not Option B (IP Whitelisting + CloudWatch Agent)?
- Attack surface remains: TCP/22 is still exposed, even if restricted to specific IPs. IP-based security is fragile (IP spoofing, engineer device compromise, dynamic IP changes for remote workers).
- Operational overhead: Maintaining an accurate whitelist of engineer IPs is a management nightmare (VPN IP changes, home office IPs, coffee shop access). Every IP change requires security group updates.
- Higher cost: CloudWatch Logs ingestion for command audit logs across 45 instances = ~$0.50/GB ingested + $0.03/GB/month storage. For a team generating 10GB/month of logs, that’s $5/month ingestion + growing storage costs. Session Manager’s S3 logging is ~$0.023/GB (4.6x cheaper).
- Agent management complexity: CloudWatch agent requires installation, configuration, version updates, and troubleshooting across all instances.
-
Why not Option C (IP Whitelisting + AWS Config + Firewall Manager)?
- Misses the core requirement: This option focuses on preventing unauthorized security group changes (a governance/compliance control), but does NOT address the two primary requirements: eliminating the attack surface and enabling command audit.
- TCP/22 still exposed: Same fundamental flaw as Option B—the SSH port remains open.
- No audit capability: AWS Config and Firewall Manager provide configuration compliance monitoring, NOT command-level session logging.
- Overcomplicated for this use case: Firewall Manager is designed for multi-account, multi-VPC centralized security group management. For a single startup VPC, this is architectural overkill and adds unnecessary complexity.
- Cost inefficiency: AWS Config rules = $2/rule/region + $0.003/configuration item recorded. Firewall Manager = $100/policy/region/month. You’re paying ~$100+/month for a solution that doesn’t even solve the audit requirement.
🔐 The Solution Blueprint #
This blueprint visualizes the expected solution, showing how services interact and which architectural pattern the exam is testing.
Seeing the full solution end to end often makes the trade-offs—and the failure points of simpler options—immediately clear.
graph TD
Eng[Engineer Workstation
AWS CLI + SSM Plugin] -->|1. aws ssm start-session| IAM[IAM Authentication
MFA Enforced]
IAM -->|2. Validated Identity| SSM[AWS Systems Manager
Session Manager Service]
SSM -->|3. Establish Session via HTTPS:443| Agent[SSM Agent on EC2
AmazonSSMManagedInstanceCore Role]
Agent -->|4. Interactive Shell| EC2[Private EC2 Instance
No Inbound TCP/22 Rule]
SSM -->|5. Log Session Metadata| CT[CloudTrail
Who/When/Which Instance]
SSM -->|6. Stream Command Logs| CWL[CloudWatch Logs or S3
Full Command Audit Trail]
style EC2 fill:#FF6B6B,stroke:#C92A2A,color:#FFF
style SSM fill:#51CF66,stroke:#2F9E44,color:#FFF
style IAM fill:#4DABF7,stroke:#1971C2,color:#FFF
Diagram Note: The engineer authenticates via IAM, Session Manager brokers the connection over HTTPS, and all activity is logged without ever exposing SSH port 22.
🔐 The Decision Matrix #
This matrix compares all options across cost, complexity, and operational impact, making the trade-offs explicit and the correct choice logically defensible.
At the professional level, the exam expects you to justify your choice by explicitly comparing cost, complexity, and operational impact.
| Option | Est. Complexity | Est. Monthly Cost (45 Instances) | Pros | Cons |
|---|---|---|---|---|
| A (EC2 Instance Connect) | Low | $0 (native AWS service, no incremental cost) | ✅ Simple setup ✅ Logs connection events to CloudTrail ✅ Temporary key-based access |
❌ No command-level audit (only connection logs) ❌ TCP/22 still exposed to AWS IP ranges ❌ Requires additional CloudWatch agent for full audit |
| B (IP Whitelist + CloudWatch Agent) | Medium-High | ~$150-250/month ($5-8 for 10-15GB log ingestion + $0.03/GB storage + NAT Gateway data processing ~$135/month for log uploads) |
✅ Familiar SSH workflow ✅ Full command audit via CloudWatch |
❌ TCP/22 exposed (perimeter security risk) ❌ IP whitelist maintenance nightmare ❌ Agent installation/updates on 45 instances ❌ Highest ongoing log ingestion cost |
| C (IP Whitelist + Config + Firewall Manager) | High | ~$250-300/month ($100 Firewall Manager policy + $2/Config rule + ~$30 Config item recordings + ~$135 NAT Gateway data transfer) |
✅ Strong governance (auto-remediation of policy violations) ✅ Multi-account scalability |
❌ TCP/22 still exposed ❌ Zero audit capability for commands ❌ Massive overkill for single-VPC startup ❌ Highest cost with lowest ROI for this requirement |
| D (Systems Manager Session Manager) | Low | ~$0-15/month (SSM service free; optional S3 log storage ~$0.50/month for 20GB @ $0.023/GB; no agent installation needed—SSM agent pre-installed on Amazon Linux 2) |
✅ Zero attack surface (no TCP/22) ✅ IAM-based identity security ✅ Built-in CloudTrail + command logging ✅ No VPN dependency ✅ No agent management (pre-installed) ✅ Lowest cost |
⚠️ Engineers need one-time SSM plugin install ⚠️ Shift from IP-based to IAM-based mental model |
FinOps Insight: Option D delivers 95% cost reduction vs. Option C while simultaneously achieving superior security posture. The “complexity” of IAM policy management is a one-time investment that scales better than IP whitelist maintenance.
🔐 Real-World Practitioner Insight #
This section connects the exam scenario to real production environments, highlighting how similar decisions are made—and often misjudged—in practice.
This is the kind of decision that frequently looks correct on paper, but creates long-term friction once deployed in production.
Exam Rule #
“For the SAP-C02 exam, when you see requirements for SSH security hardening + audit logging + minimize attack surface, immediately think Systems Manager Session Manager. If the question mentions ‘command-level audit’ or ‘close all inbound ports,’ Session Manager is almost always the correct answer.”
Real World #
In production, we’d enhance Option D with:
-
IAM Conditions for MFA Enforcement:
{ "Condition": { "BoolIfExists": {"aws:MultiFactorAuthPresent": "true"} } }This forces engineers to use MFA before starting sessions.
-
Session Duration Limits: Set
IdleSessionTimeoutto 20 minutes andMaxSessionDurationto 60 minutes via SSM Session Manager preferences to auto-terminate inactive sessions. -
S3 Logging with Lifecycle Policies: Store command logs in S3 with 90-day retention, then transition to Glacier for 7-year compliance archival (reduces storage cost from $0.023/GB to $0.004/GB).
-
Hybrid Approach for Break-Glass Scenarios: Keep a single, highly restricted bastion host in a public subnet with Session Manager + SSH fallback for catastrophic SSM service outages. This bastion uses AWS Secrets Manager for SSH key rotation and is only accessible via IAM temporary credentials.
-
Advanced Monitoring: Use CloudWatch Insights to query Session Manager logs for anomalous patterns (e.g.,
sudousage spikes, access to/etc/shadow, unusual time-of-day connections). -
Port Forwarding for Debugging: Session Manager supports SSH-style port forwarding (
aws ssm start-session --target i-xyz --document-name AWS-StartPortForwardingSession) for accessing local services like databases or debugging ports without exposing them publicly.
Caveat: In highly regulated environments (e.g., PCI-DSS Level 1), you might combine Session Manager with AWS Systems Manager Session Document restrictions to enforce specific commands (e.g., allow only read-only sessions for junior engineers). This is beyond the exam scope but critical in finance/healthcare.