SAP-C02 Practice Question 60: Self Managed Kafka Replatform
AWS Certified Solutions Architect – Professional (SAP-C02) · Test 6 · question 10 of 10
A telemetry platform runs Apache Kafka on 15 self-managed EC2 broker instances plus a separate Apache ZooKeeper ensemble. Roughly 60 producer and consumer applications use the Kafka client libraries directly, and the operations team relies on standard Kafka command-line tools and two open-source Kafka monitoring plugins.
The arrangement has become the team's largest operational burden. Broker failures require a manual replacement and partition reassignment, the cluster is two Kafka versions behind because upgrades are risky, and the brokers are unevenly distributed across Availability Zones.
The company wants AWS to handle broker provisioning, patching, and failure replacement, wants brokers spread across Availability Zones, and (because 60 applications is too many to rewrite) needs the existing client applications, tools, and plugins to keep working without code changes.
What should the solutions architect recommend?
Show answer and explanation
Answer:
Amazon MSK is a fully managed service that runs open-source versions of Apache Kafka, and AWS states plainly that this means existing applications, tooling, and plugins from partners and the Apache Kafka community are supported without requiring changes to application code, which is exactly the constraint that rules out the other rewrites. MSK provides the control-plane operations while the applications keep using ordinary Kafka data-plane operations, so the 60 clients change only their bootstrap server addresses. On the operational side, when you create a cluster you specify how many brokers to place in each Availability Zone, giving the multi-AZ spread the team lacks, and MSK detects and automatically recovers from the common failure scenarios: it replaces an unhealthy or unreachable broker, reusing the older broker's storage where possible to reduce replication, and the new broker keeps the same IP address so producers and consumers reconnect unchanged.
Option A swaps the messaging model entirely. SNS and SQS have no concept of a replayable partitioned log with consumer offsets, and every one of the 60 applications would be rewritten.
Option C is the same problem in a different service. Kinesis Data Streams is a capable streaming platform but exposes a different API, so the Kafka client libraries, command-line tools, and monitoring plugins all stop working.
Option D relocates the burden rather than removing it. The team would still own broker configuration, version upgrades, and failure handling, and would now also own a Kubernetes cluster and an open-source operator.
Reference: What is Amazon MSK?