A small township library app is one deployable unit sharing one schema, maintained by three staff. Leadership asks whether splitting into ten services is mandatory on AWS. Which statement is accurate?
Select an answer to reveal the explanation.
Short Explanation
AWS is not a micromanager that forces every town library into ten microservices. For three staff and one simple schema, one deployable unit is still a solid pattern. Split only when the domain and team pain actually need it.
Full Explanation
AWS does not mandate that every municipal application become ten microservices before using Lambda or API Gateway. For a small township library app that is one deployable unit with one schema and three staff, a monolith remains a valid pattern. Operational simplicity, single transaction boundaries, and one release train often beat distributed complexity when the domain is cohesive and the team cannot staff on-call for a mesh of services. Cloud-native hosting (ECS, Elastic Beanstalk, even a modular monolith on EC2) does not require decomposing the domain first.
The claim that AWS requires microservices before any Lambda or API Gateway use is false by concept—many successful serverless designs still wrap a cohesive application behind one API. Saying a monolith is always invalid because ECS cannot host a single deployable unit misunderstands ECS, which happily runs one service definition. Mandating ten services whenever more than two developers touch the code confuses headcount with domain boundaries; premature decomposition creates network chatter, distributed failure modes, and change coordination costs a three-person library team cannot absorb.
Exam caveat: “monolith is valid” is not “monolith forever.” If permits, fines, and digital lending later diverge with separate SLAs and teams, extract bounded contexts deliberately. The exam tests whether you recognize that microservices are a tradeoff, not a cloud tax.
Operational check: document team size, change frequency, and failure-isolation needs; keep a modular monolith with clear package boundaries until pain appears; avoid splitting solely to “look cloud-native”; and only introduce separate datastores when independent deployability becomes a measured requirement.