While preparing for the AWS SAP-C02, many candidates get confused by hybrid infrastructure management tools. In the real world, this is fundamentally a decision about operational consolidation vs. feature sprawl. The question isn’t just ‘can it patch servers?’—it’s ‘can we eliminate 5 different tools and still pass our next SOC 2 audit?’ Let’s drill into a simulated scenario.
The Scenario #
GlobalManufacture Inc. operates a distributed manufacturing execution system (MES) spanning 12 on-premises data centers and 340 Amazon EC2 instances across 4 AWS regions. Their current patch management landscape is fragmented:
- On-premises RHEL/Windows servers use Ansible Tower
- AWS Linux instances use custom Lambda-triggered shell scripts
- Windows EC2 instances use third-party agent software
The VP of Infrastructure Security has mandated: “We need a single-pane-of-glass compliance report showing patch status for ALL servers—on-prem and cloud—delivered to our board quarterly for SOC 2 Type II certification. The current tooling chaos is unauditable.”
Key Requirements #
Implement a unified patch management and reporting solution that:
- Manages patching for both on-premises servers and EC2 instances
- Generates consolidated compliance reports without custom ETL pipelines
- Minimizes architectural complexity and third-party dependencies
The Options #
- A) Use AWS Systems Manager to manage on-premises servers and EC2 instances; generate patch compliance reports through Systems Manager.
- B) Use AWS OpsWorks to manage on-premises servers and EC2 instances; generate patch compliance reports through Amazon QuickSight integration with OpsWorks.
- C) Use Amazon EventBridge rules to schedule AWS Systems Manager patch remediation tasks; use Amazon Inspector to generate patch compliance reports.
- D) Use AWS OpsWorks to manage on-premises servers and EC2 instances; publish patch status to AWS Systems Manager OpsCenter via AWS X-Ray to generate compliance reports.
Correct Answer #
A.
The Architect’s Analysis #
Correct Answer #
Option A – AWS Systems Manager for hybrid patch management and native compliance reporting.
Step-by-Step Winning Logic #
Why Systems Manager dominates this scenario:
-
Hybrid-First Design: Systems Manager was purpose-built for hybrid workloads. The SSM Agent works identically on on-prem and EC2 instances—no architectural bifurcation.
-
Compliance as a Native Feature: Patch Manager includes Compliance Dashboard out-of-the-box. You get:
- Per-instance patch status
- Severity-based filtering (Critical/Important/Medium/Low)
- Export to S3 for long-term audit trails
- No custom Lambda, Athena queries, or QuickSight datasets required
-
Operational Consolidation: You replace 3+ tools (Ansible Tower, custom scripts, third-party agents) with a single control plane. This reduces:
- License costs (Ansible Tower enterprise = $14K/year minimum)
- Agent sprawl (one SSM Agent vs. multiple vendor daemons)
- Training overhead (one AWS console section vs. three product UIs)
-
FinOps Efficiency:
- On-prem managed instances: $0.00695/hour ≈ $5.00/month per server
- EC2 instances: Free (included in EC2 pricing)
- No QuickSight ($24/user/month), no OpsWorks Chef licensing, no EventBridge rule proliferation
The Traps (Distractor Analysis) #
Why not Option B?
- OpsWorks is a configuration management service (Chef/Puppet), not a patch orchestrator. While you can write Chef recipes to patch servers, you’re now:
- Maintaining cookbooks for patch logic (operational burden)
- Paying for QuickSight to visualize data that OpsWorks doesn’t natively structure for compliance
- Missing built-in patch compliance tracking—OpsWorks has no “compliance dashboard” concept
- Cost: QuickSight Enterprise = $24/user/month × 5 compliance officers = $1,440/year, plus OpsWorks node fees
Why not Option C?
- Amazon Inspector is a vulnerability scanner, not a patch manager. It finds CVEs; it doesn’t install patches.
- Architectural mismatch: EventBridge → Systems Manager makes sense for triggering patches, but:
- Inspector can’t generate patch compliance reports (it generates vulnerability reports)
- You’d still need Systems Manager for reporting—so why add EventBridge complexity?
- On-prem gap: Inspector doesn’t scan on-premises servers (it’s EC2/ECR/Lambda only)
Why not Option D?
- X-Ray is a distributed tracing service (for application performance), not a data pipeline for operational metrics
- Nonsensical integration: X-Ray → OpsCenter isn’t a supported workflow. You can’t “publish patch status via X-Ray”
- Redundant layers: Why use OpsWorks + X-Ray + OpsCenter when Systems Manager does all three functions natively?
The Architect Blueprint #
Diagram Note: SSM Agent creates a unified control plane—on-prem and cloud servers are managed identically, with compliance data flowing directly to the native dashboard (no ETL required).
The Decision Matrix #
| Option | Est. Complexity | Est. Monthly Cost (500 Instances) | Pros | Cons |
|---|---|---|---|---|
| A – Systems Manager | Low | $250/mo (50 on-prem @ $5 each) |
✅ Native compliance dashboard ✅ Hybrid-first design ✅ Zero ETL for reporting ✅ Consolidates 3+ tools |
⚠️ Requires SSM Agent installation (one-time effort) |
| B – OpsWorks + QuickSight | High | $1,200/mo (OpsWorks nodes + QS licenses) |
✅ Familiar to Chef/Puppet teams | ❌ No native patch compliance tracking ❌ Requires custom cookbook development ❌ QuickSight licensing overhead |
| C – EventBridge + Inspector | Medium | $400/mo (Inspector scans + EB rules) |
✅ Automated scheduling | ❌ Inspector doesn’t manage patches (only scans) ❌ No on-prem support ❌ Still needs SSM for reporting |
| D – OpsWorks + X-Ray + OpsCenter | Very High | $1,500/mo (OpsWorks + X-Ray traces) |
❌ None (architecturally invalid) | ❌ X-Ray doesn’t transport patch metadata ❌ Unsupported integration path ❌ 3-service complexity for 1-service job |
FinOps Insight: Option A delivers $950/month savings vs. Option B, while reducing operational complexity. The ROI is immediate—no QuickSight user licenses, no Chef cookbooks to version-control, no ETL pipelines to maintain.
Real-World Practitioner Insight #
Exam Rule #
For SAP-C02, always choose Systems Manager when you see:
- “Hybrid” + “on-premises” + “EC2”
- “Unified reporting” or “compliance dashboard”
- “Patch management” without mention of Chef/Puppet
Real World #
In reality, we’d likely augment this with:
-
Patch Baselines with Approval Rules: Use Systems Manager Maintenance Windows to enforce “patch Tuesdays” (e.g., only deploy Critical patches within 72 hours; delay Important patches by 14 days for testing).
-
Integration with ServiceNow: Export Systems Manager compliance data to S3, trigger Lambda to create ServiceNow change tickets for non-compliant instances (true enterprise workflow).
-
Cost Optimization: For the 50 on-prem servers, evaluate if AWS Systems Manager Advanced Instances ($0.00695/hour) is cheaper than maintaining Ansible Tower licenses + infrastructure. (Spoiler: At scale, it almost always is.)
-
Multi-Account Strategy: Use AWS Organizations with Systems Manager Quick Setup to auto-configure Patch Manager across 20+ AWS accounts (not mentioned in the question, but critical for real enterprises).