Subnet-level rules in a municipal VPC allow only specific ports between the web, application, and data tiers. Which control operates at that subnet scope?
Select an answer to reveal the explanation.
Short Explanation
Think of subnet NACLs as the street barriers between neighborhoods—only the ports you list get through from web to app to data. They sit at the subnet edge, not inside the SSO password policy or the object-lifecycle settings. Tight tier-to-tier port lists keep lateral movement harder.
Full Explanation
Network ACLs apply allow/deny rules at the subnet boundary and are well suited to constraining which ports pass between web, application, and data tiers in a municipal VPC. Subnet-scoped filtering complements instance-level controls by enforcing tier separation for citizen application architectures.
Per-user SSO password length policies in the identity directory do not filter packets between subnets. Application code linting rules never evaluate network flows. Object storage lifecycle policies only transition storage classes/archives—they are not subnet network filters.
Exam caveat: NACLs are subnet-stateless (commonly) allow/deny lists; security groups are usually stateful instance/NIC-level filters. Exams often contrast the two scopes.
Operational check: define NACL rules that allow only required ports between tiers, deny unnecessary mid-tier paths, test application functionality after changes, and log rejects where supported. Document the tier model in the city’s VPC design guide.
When application teams request new cross-tier ports, require an architecture note justifying the flow; default-deny NACL posture for municipal VPCs should make unjustified openings visible in change review.