A city placed Amazon RDS in a public subnet and enabled public accessibility "for easier admin." Which redesign best hardens the database tier?
Select an answer to reveal the explanation.
Short Explanation
Databases belong in the vault room, not on the sidewalk with a welcome mat. Put RDS in private subnets, turn off public accessibility, and admin through a bastion or Session Manager. Public passwords, world-open Postgres, or no security groups make "easier admin" into easier breach.
Full Explanation
When Amazon RDS was placed in a public subnet with public accessibility enabled “for easier admin,” the hardening redesign moves RDS into private subnets, disables public accessibility, and uses a bastion host or AWS Systems Manager Session Manager path for administration. Databases supporting city services belong on private networks; administrators reach them through controlled jump paths with IAM and security-group constraints rather than opening the database listener to the internet.
Keeping public accessibility and publishing the database password on the city’s public status page fails because it combines network exposure with credential disclosure. Assigning a second Elastic IP and opening PostgreSQL to the world for redundancy fails conceptually: extra public addresses multiply attack surface and “redundancy” does not justify internet-wide database protocols. Deleting all security groups so administrators never hit connection timeouts fails because instances and RDS require security-group state; removing them breaks isolation rather than fixing connectivity design.
Exam caveat: private RDS still needs correct app-tier security groups, Multi-AZ considerations, and encrypted storage/backups—network privacy alone is not a complete database security program. Operational check: set PubliclyAccessible=false, confirm subnet group uses private subnets only, verify no public DNS/IP reachability to port 5432/3306 from the internet, and administer via bastion or SSM with MFA-backed operator roles.