A transit authority must let guest users share a public IPv4 address outbound while publishing one civic web portal on a fixed public IP. Which NAT combination matches those goals?
Select an answer to reveal the explanation.
Short Explanation
Guests share the on-ramp with PAT—many insides, one (or few) public outsides. The portal needs a reserved parking spot: static NAT to a fixed public IP. Mix those two and you cover casual browsing plus a published service.
Full Explanation
Transit guest users sharing one public IPv4 outbound while a civic web portal needs a fixed public IP calls for PAT (NAT overload) for guest Internet egress plus static NAT for the published portal. Overload conserves scarce public IPv4 for many guests; static NAT gives the portal a stable outside mapping. That combination matches the two distinct goals in the stem.
Static NAT for every guest device wastes public addresses and reverses the design. Dynamic NAT pools without overload for guests plus no portal mapping fails both conservation and publishing requirements. Refusing NAT and assigning globally routable IPv4s to every guest laptop is usually impractical and ignores the stated sharing requirement.
Exam caveat: static NAT for servers and PAT for clients often coexist on the same outside interface; order and ACL match matter for overlapping interest in the same ports. Operational check: configure PAT for the guest pool and static NAT for the portal, verify guest many-to-one translations and portal inbound mapping with show nat/xlate equivalents, and test browse and publish paths. Transit NAT designs should reserve portal static mappings outside the PAT pool range and document hairpinning needs for internal clients reaching the public VIP.