Cloud Digital Leader Practice Question: A company's monolithic application is difficult…

Answer analysis

Option-by-option breakdown

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

• ✗

  Microservices always cost less than monolithic applications to run.

  Why it's wrong here

  This conflates architectural style with cost efficiency. In practice, microservices often increase operating cost: each service may run as its own process or container requiring compute, memory, and a share of overhead for service discovery, API gateways, distributed logging, and per-service CI/CD pipelines. Network calls between services introduce latency and increase failure modes, and you typically need more sophisticated observability and resilience tooling. The reason to choose microservices is agility, independent scaling, and team autonomy—not a guaranteed reduction in spend.

• ✓

  Each service can be updated and deployed independently, enabling teams to release changes faster with lower risk and without full-application downtime.

  Why this is correct

  Independent deployability is the defining operational advantage of microservices: because services communicate via well-defined APIs rather than sharing code and runtime state, changing service A requires only rebuilding and redeploying that service, leaving B, C, and D untouched. This shrinks the deployment blast radius, lets teams ship on their own cadence, and supports safer strategies like canary releases or blue-green deployments that would be far riskier and slower on a single monolithic unit. The result is faster feature delivery with less coordination overhead and no need to drain and redeploy the entire application.

• ✗

  Microservices eliminate the need for testing because each service is small enough to be bug-free.

  Why it's wrong here

  Microservices do not eliminate testing; each service still requires unit, integration, and contract tests to validate its independent behaviour, and the scenario’s multi-hour downtime stems from redeploying the entire monolith, not from testing volume. The option is tempting because smaller codebases reduce the scope of regression testing per service, which could be mistaken for removing testing entirely, but this confuses reduced scope with zero verification.

• ✗

  Microservices allow applications to run on any hardware without modification.

  Why it's wrong here

  This confuses a benefit of containerization or virtualization with a property of microservices. Microservices are an architectural pattern for decomposing an application into independently deployable business capabilities; they say nothing about the underlying hardware abstraction layer. You can run a monolith on Kubernetes or a microservices architecture on bare-metal VMs, and whether the code is portable depends on the runtime environment, not on whether the application is split into services. The statement is technically false because hardware portability comes from packaging and execution environments like containers, not from service decomposition itself.

Go deeper

Related to this question