While preparing for the AWS SAP-C02, many candidates get confused by when to use serverless versus container orchestration for hybrid workloads. In the real world, this is fundamentally a decision about Operational Overhead vs. Control Flexibility. Let’s drill into a simulated scenario.
The Scenario #
MedTech Innovations, a connected medical device company, operates an on-premises IoT telemetry platform serving 45,000 wearable health monitors. The current architecture consists of:
- Ingestion Layer: Custom MQTT broker servers receiving device telemetry every 5 minutes
- Storage Layer: Self-managed MongoDB cluster (3-node replica set) storing device metadata and configuration
- Processing Layer: Scheduled batch jobs (running 120-600 seconds each) that join telemetry streams with device metadata to generate compliance reports
- Presentation Layer: Always-on web application for clinicians to view patient device reports
The company’s CTO has mandated cloud migration with “drastically reduced operational overhead” as the primary goal, driven by a 40% staff reduction in the infrastructure team.
Key Requirements #
Migrate the IoT platform to AWS while minimizing operational overhead (staffing, patching, scaling complexity). The solution must maintain current functionality and support 3x device growth over 24 months.
The Options #
Select THREE:
- A) Deploy AWS Lambda functions as MQTT endpoint handlers to receive IoT device connections
- B) Configure IoT devices to publish telemetry data directly to AWS IoT Core using MQTT
- C) Migrate the MongoDB cluster to self-managed MongoDB on Amazon EC2 instances with automated backups
- D) Replace MongoDB with Amazon DocumentDB (with MongoDB compatibility)
- E) Build the reporting pipeline using AWS Step Functions orchestrating Lambda functions, store reports in S3, and serve via CloudFront with S3 origin
- F) Deploy reporting workloads on Amazon EKS cluster with EC2 worker nodes, using Kubernetes Ingress for report delivery
Correct Answer #
B, D, E
Step-by-Step Winning Logic #
This solution represents the maximum operational overhead reduction while maintaining all functional requirements:
-
AWS IoT Core (B) is a fully managed MQTT broker with built-in device authentication, message routing, and rules engine. It eliminates the need to manage MQTT server fleets, handle TLS certificate rotation, or implement custom device authentication. At 45,000 devices × 12 messages/hour, you’re processing ~13M messages/month—well within IoT Core’s sweet spot.
-
Amazon DocumentDB (D) provides MongoDB 4.0 API compatibility with automated backups, point-in-time recovery, automated patching, and continuous monitoring—eliminating 80% of DBA tasks. For metadata storage (relatively small dataset), the operational cost savings dwarf the marginal price premium over self-managed EC2.
-
Step Functions + Lambda + S3 + CloudFront (E) delivers a fully serverless reporting pipeline:
- Step Functions orchestrates the 120-600 second workflows (perfect fit for Standard Workflows)
- Lambda executes data transformation logic without provisioning servers
- S3 provides durable, low-cost report storage
- CloudFront delivers global, low-latency access with built-in DDoS protection
💎 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?
Lambda functions cannot directly accept MQTT connections. MQTT requires persistent TCP connections with QoS state management—Lambda’s ephemeral, request-response model is architecturally incompatible. You could build a custom MQTT broker on ECS/Fargate, but that increases operational overhead, violating the core constraint. AWS IoT Core is purpose-built for this.
Why not Option C?
Self-managed MongoDB on EC2 requires:
- Manual replica set configuration and monitoring
- OS and MongoDB patching schedules
- Backup scripting and testing
- Capacity planning and instance right-sizing
- High availability orchestration
This is the opposite of “minimal operational overhead.” While potentially 20-30% cheaper in compute costs, it requires 0.5-1.0 FTE ongoing, negating any savings.
Why not Option F?
Amazon EKS introduces massive operational complexity:
- Kubernetes control plane management (even when managed by AWS)
- Worker node patching and AMI updates
- Cluster autoscaling configuration
- Ingress controller deployment and certificate management
- Container image builds and registry management
For a reporting workload that runs periodically (not high-throughput, latency-sensitive microservices), EKS is architectural over-engineering. The operational overhead contradicts the stated 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
Devices[45K IoT Devices
MQTT Protocol] -->|Publish Telemetry| IoTCore[AWS IoT Core
Fully Managed MQTT Broker]
IoTCore -->|IoT Rule| Kinesis[Amazon Kinesis Data Streams
Telemetry Buffer]
IoTCore -->|Device Metadata Updates| DocDB[(Amazon DocumentDB
MongoDB-Compatible)]
EventBridge[Amazon EventBridge
Schedule: Every 5 min] -->|Trigger| StepFunc[AWS Step Functions
Standard Workflow]
StepFunc -->|1. Fetch Metadata| Lambda1[Lambda: Data Retrieval]
Lambda1 -->|Query| DocDB
Lambda1 -->|Read Telemetry| Kinesis
StepFunc -->|2. Transform & Aggregate| Lambda2[Lambda: Report Generation
120-600s execution]
Lambda2 -->|Write| S3[Amazon S3
Report Storage]
S3 -->|Origin| CloudFront[Amazon CloudFront
Global CDN]
CloudFront --> Clinicians[Clinician Web App
Report Viewers]
style IoTCore fill:#FF9900,stroke:#232F3E,stroke-width:3px,color:#fff
style DocDB fill:#3B48CC,stroke:#232F3E,stroke-width:2px,color:#fff
style StepFunc fill:#CD2264,stroke:#232F3E,stroke-width:2px,color:#fff
style S3 fill:#569A31,stroke:#232F3E,stroke-width:2px,color:#fff
style CloudFront fill:#8C4FFF,stroke:#232F3E,stroke-width:2px,color:#fff
Diagram Note: This serverless-first architecture eliminates all server provisioning, patching, and scaling decisions—operational tasks are fully delegated to AWS managed services.
🔐 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 | Operational Complexity | Est. Monthly Cost (45K Devices) | Pros | Cons |
|---|---|---|---|---|
| B: IoT Core | ⭐ Low (Fully Managed) | $650 (13M messages + rules) | Zero broker management; built-in device registry; rules engine for routing | Limited to AWS ecosystem; vendor lock-in |
| A: Lambda MQTT Handler | ⭐⭐⭐⭐ Very High (Custom Build) | $1,200+ (ALB + Lambda + connection state management) | Theoretically flexible | Architecturally incompatible; requires custom TCP proxy layer; high failure risk |
| D: DocumentDB | ⭐⭐ Low-Medium (Managed) | $380 (db.r5.large, 100GB) | Automated backups, patching, failover; MongoDB compatibility | 20% price premium vs. self-managed; limited to AWS regions |
| C: Self-Managed MongoDB on EC2 | ⭐⭐⭐⭐⭐ Very High | $290 (3× r5.large + EBS) | Full control; potentially cheaper compute | Requires 0.5 FTE DBA time (~$4K/mo loaded cost); patching overhead; backup scripting |
| E: Step Functions + Lambda + S3 + CloudFront | ⭐ Low (Fully Serverless) | $520 (Step Functions executions + Lambda GB-sec + S3 + CloudFront) | Zero server management; auto-scaling; pay-per-use | Cold start latency (mitigated with provisioned concurrency); 15-min Lambda max (fits 600s requirement) |
| F: EKS + EC2 + Ingress | ⭐⭐⭐⭐⭐ Very High | $890 (EKS control plane $73 + 3× t3.large workers + ALB) | Ultimate flexibility; portable workloads | Requires Kubernetes expertise; control plane + worker node patching; overkill for periodic batch jobs |
FinOps Deep Dive #
Total Monthly Cost Comparison:
- Winning Architecture (B+D+E): ~$1,550/month
- High-Overhead Alternative (A+C+F): ~$2,380/month + $4,000 FTE overhead
The Real Cost Equation:
While the raw infrastructure cost difference is only $830/month, the hidden operational cost is devastating:
- Self-managed MongoDB (C): 20 hours/month DBA work
- EKS cluster management (F): 30 hours/month DevOps work
- Custom Lambda MQTT handler (A): 40 hours/month (initial build) + 10 hours/month (maintenance)
At a blended rate of $100/hour, the operational overhead adds $6,000-8,000/month in the first year.
The serverless architecture (B+D+E) achieves 78% reduction in operational overhead with only 8% higher infrastructure cost—a textbook FinOps win.
🔐 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 SAP-C02, when you see “minimize operational overhead” combined with IoT workloads, the answer pattern is:
- AWS IoT Core for device connectivity (not custom Lambda handlers)
- Managed databases (DocumentDB/DynamoDB) over self-managed EC2
- Serverless compute (Lambda/Step Functions) over container orchestration (EKS/ECS)
Real World #
In production, we’d add nuance:
-
IoT Core Rules Engine Limitations: For complex event processing (CEP), we might introduce Amazon Managed Service for Apache Flink between IoT Core and DocumentDB to handle real-time anomaly detection before storage.
-
DocumentDB vs. DynamoDB: If the metadata schema is highly dynamic or requires single-digit millisecond latency, DynamoDB might be superior (especially with on-demand billing). DocumentDB is optimal when you have existing MongoDB application code to migrate.
-
Step Functions Cost Optimization: At extreme scale (1M+ executions/month), we’d evaluate Express Workflows (60% cheaper) or even EventBridge Pipes + Lambda for simpler orchestration patterns.
-
Hybrid Reporting: For reports requiring >15 minutes (Lambda max), we’d use AWS Batch with Fargate instead of EKS—still serverless operational model, but supports longer-running jobs.
-
Data Sovereignty: If device data must remain in specific geographies (GDPR, HIPAA), we’d implement IoT Core Custom Authorizers with geo-fencing logic and multi-region DocumentDB clusters.
The exam tests principles; production requires calibration to non-functional requirements.