A city clerk needs inside private desk addresses translated to public addresses from a configured pool for Internet access from city hall. Which NAT approach fits?
Select an answer to reveal the explanation.
Short Explanation
City hall desks share a pool of public addresses like a shared visitor badge drawer—inside source NAT hands one out when someone browses out. You do not need a permanent public IP carved for every clerk chair.
Full Explanation
A city clerk needing inside private desk addresses translated to public addresses from a configured pool for Internet access is describing dynamic inside source NAT with an address pool. Many inside local hosts obtain temporary inside global addresses from that pool as outbound sessions form, which fits shared civic egress without carving a permanent public IP per desk. That many-to-pool model is the NAT approach that matches the requirement.
Static one-to-one NAT only, mapping each desk to a unique permanent public IP forever, fails by concept for this goal: it wastes scarce public space and is unnecessary for ephemeral clerk browsing. Destination PAT that rewrites only inbound HTTPS without any inside source translation fails by concept: outbound desk Internet access needs inside source translation, not inbound-only destination framing. Disabling NAT and assigning public IPs directly to every clerk PC on the access VLAN fails by concept: it abandons private addressing policy and is rarely feasible or desirable for city-hall access VLANs.
Exam caveat: pool-based dynamic inside source NAT serves outbound clients; static NAT reserves fixed mappings for published servers—choose by whether fixed public identity is required. Operational check: configure inside/outside interfaces, define the public pool and ACL matching clerk subnets, generate outbound traffic, and verify translations appear mapping inside locals to pool globals.