A housing-authority team labels “intake,” “inspection,” and “payments” as microservices but packages them as libraries loaded into one OS process so they can share memory. What essential microservice property have they lost?
Select an answer to reveal the explanation.
Short Explanation
If three “services” share one process, you have renamed a monolith—not created microservices. Independent deployability means separate processes and release trains. Shared memory convenience puts shipping, scale, and failure back on one fuse.
Full Explanation
Independent deployability is the essential microservice property the housing-authority team lost by packaging intake, inspection, and payments as libraries in one OS process. Labels do not create microservices; separate processes and release trains do. Shared memory convenience puts shipping, scale, and failure back on one fuse, so a bad payments deploy still takes intake and inspection down with it.
HTTPS between browser clients and a load balancer is an edge transport concern and can exist for monoliths and microservices alike—it does not define microservice decomposition. Requiring every service to use the same programming language is not a microservice property and often works against polyglot independence. Access to Object Storage buckets from within a VCN is networking/storage reachability, unrelated to whether modules can ship and fail apart.
Exam caveat: if several “services” share one process, you have renamed a modular monolith—independent deployability requires process and release isolation, not shared-memory libraries.
Operational check: attempt to deploy a payments fix without rebuilding or restarting intake and inspection; if you cannot, you do not yet have independently deployable microservices.