A library consortium containerizes its catalog app but still requires a stop-the-world release whenever any module changes, and operators cannot see why requests fail. What outcomes should the cloud-native pillars primarily unlock?
Select an answer to reveal the explanation.
Short Explanation
The pillars are not trophies for “we used a container”—they are tools so one change does not freeze the whole city hall, a failed unit can be swapped, and operators can see and steer. Loose coupling, resilience, manageability, and observability are the outcomes that matter.
Full Explanation
Cloud-native pillars exist so the library consortium’s catalog gains loose coupling, resilience through replaceable units, manageability, and observability. Those outcomes keep a module change from freezing the whole release, let a failed unit be swapped without nursing a unique host, and give operators visibility to steer when requests fail. Container packaging without those outcomes is cargo-cult: the consortium already containerized yet still suffers stop-the-world releases and opaque failures.
Lower Object Storage list prices and Free Tier eligibility are billing topics, not the purpose of cloud-native fundamentals. Requiring a service mesh for every east-west call mandates a product pattern that may help some topologies but is not itself the pillar outcome set. Mandatory multi-region active-active networking for every microservice over-prescribes topology; many municipal services need loose coupling and observability long before every call path is multi-region.
Exam caveat: techniques such as containers and declarative control are means; the exam wants the outcomes—coupling, resilience, manageability, observability—not a checklist of mandatory meshes or regions.
Operational check: change one module and deploy it without stopping unrelated modules, replace a failed replica without SSH nursing, and verify operators can trace a failed request in aggregated telemetry rather than guessing from a silent container.