SAP-C02 Practice Question: Accelerate Workload Migration and Modernization

Which THREE of the following are common challenges when migrating a monolithic application to a microservices architecture on AWS? (Choose three.)

⚠ Common exam trap

SAP-C02 often tests the confusion between challenges of microservices and benefits, such as mistaking independent scaling as a challenge rather than an advantage.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Managing distributed transactions across multiple services

Option A is correct because decomposing a monolith into microservices means a single business operation often spans multiple services, each with its own datastore, so maintaining atomicity requires patterns like Saga, two-phase commit, or compensating transactions instead of a single ACID transaction. Option C is correct because calls that were once in-process method invocations become remote network calls over HTTP/gRPC or via queues, adding serialization, connection, and round-trip latency plus retry and timeout overhead. Option D is correct because when each service owns its own database, you lose the monolith's single ACID transaction and must handle eventual consistency, idempotency, and reconciliation across services. Option B is not a challenge specific to microservices migration — a shared single database is actually a characteristic of the monolith being left behind, and the migration goal is typically to decompose that database. Option E is not a challenge but a benefit: microservices are designed so each service can be scaled independently, which is easier than scaling a monolith as a whole.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Managing distributed transactions across multiple services
Why this is correct
With data split across services, a business operation spanning several of them cannot rely on a single local transaction. Coordinating commits across service boundaries needs compensating actions or saga orchestration, making distributed transaction management a core migration challenge.
✗
Single database bottleneck when all services share the same database
Why it's wrong here
A shared database creates coupling and a single point of contention, but this is a genuine migration challenge, not a reason to reject it. The option is tempting precisely because it correctly describes a real obstacle teams encounter when decomposing monoliths, so it satisfies the question rather than failing it.
✓
Increased network latency due to inter-service communication
Why this is correct
Splitting a monolith replaces in-process method calls with remote calls over the network, so each request now incurs serialisation, transport and retry overhead. This directly satisfies the stem's migration-challenge framing: distributed communication adds latency that a single-process monolith never incurred.
✓
Ensuring data consistency between services that own their own databases
Why this is correct
Each microservice owning its own database removes shared ACID transactions, so maintaining consistency across service boundaries requires patterns such as sagas or eventual consistency. This distributed data ownership is a direct consequence of decomposing the monolith.
✗
Difficulty in scaling individual services independently
Why it's wrong here
Independent scaling is the goal microservices deliver, not a challenge; the difficulty lies in decomposing a monolith so services can scale separately. It tempts because scaling concerns feel migration-related, but the actual obstacle is the coupled monolith, not the target architecture's scaling capability.

Go deeper

SAP-C02 Practice Question: Accelerate Workload Migration and Modernization

Why each option matters

Option-by-option breakdown

Related to this question