A building permits desk chooses between static NAT and a dynamic NAT pool. When is static inside source NAT the better fit?
Select an answer to reveal the explanation.
Short Explanation
Need a permits server to keep the same public face? Use static NAT. A dynamic pool is the shared coat-check for everyday outbound browsers—not a reserved mailbox for a published server.
Full Explanation
A building-permits desk choosing static inside source NAT over a dynamic pool should do so when a server needs a fixed public IP mapping for consistent inbound or published reachability. Static NAT reserves that permanent one-to-one relationship so citizens, partners, or DNS records can depend on one public address across sessions. Dynamic pools are the wrong tool when fixed identity matters because bindings are temporary and not reserved for a published permits service.
Choosing static NAT when thousands of ephemeral clerk browsers need temporary public addresses with no inbound fixed mapping fails by concept: that scenario favors dynamic pool (or PAT) outbound NAT, not static per-host mappings that consume scarce public space. Avoiding NAT entirely by bridging the permits VLAN to the ISP fails by concept: bridging does not answer the static-versus-pool design question and often violates addressing and security design for municipal networks. Saying the only requirement is NTP synchronization for log timestamps fails by concept: time sync improves logging but does not provide a public IP mapping for a server.
Exam caveat: match NAT flavor to traffic pattern—static for fixed published hosts, dynamic/PAT for many outbound clients—and remember ACLs still control which traffic is permitted after translation. Operational check: if the permits service must keep one public face, implement static inside source NAT and verify the permanent mapping end-to-end; if only outbound browsing is needed, use a pool/PAT design instead and confirm ephemeral translations.