A municipal CRM follows a classic three-tier design: web, application, and database. How should the architect place the tiers for a scalable, loosely coupled layout on AWS?
Select an answer to reveal the explanation.
Short Explanation
Three floors, three locks: ALB to the app tier, database tucked in private subnets, each floor scalable alone. One public kitchen-sink instance or a naked public database is how outages and breaches share a calendar invite.
Full Explanation
A municipal CRM in classic three-tier form should place presentation and application tiers behind an Application Load Balancer across appropriate subnets, keep the database in private subnets without public exposure, and scale each tier independently. That layout preserves loose coupling: web/app instances can autoscale behind the ALB while the data tier remains protected and sized for persistence needs. It is the standard AWS multi-tier pattern for civic line-of-business systems.
Collocating web, app, and database on one public EC2 instance with no load balancer creates a single failure domain and an oversized attack surface. Exposing the database with a public IP and skipping the application tier violates least privilege networking and removes a business-logic boundary. Storing all CRM state only in browser localStorage eliminates server tiers and cannot provide durable multi-user municipal CRM semantics.
Exam caveat: private subnet databases, ALB toward app tier, and no public DB addresses are frequent correct patterns. Operational check: place RDS in private subnets, restrict security groups so only app tier SGs may connect, put the ALB in public or edge subnets as designed, and scale app ASG separately from web if split.