After applying inside source NAT on the clinic edge, public health staff want proof that clerk traffic is creating translations. What should they verify?

After applying inside source NAT on the clinic edge, proof that clerk traffic is creating translations means inspecting the NAT translation table for entries that map inside local addresses to inside global addresses as outbound flows occur. Those entries are the direct operational evidence the edge is rewriting addresses for public-health staff Internet use, and they confirm the ACL, pool or PAT, and inside/outside interface roles are interacting as designed for municipal egress.

Checking only the Spanning Tree root priority on the access switch fails by concept: STP root priority governs Layer-2 loop prevention and root bridge selection; it does not show NAT bindings or prove address translation. Checking only wireless PSK length on the guest SSID fails by concept: Wi-Fi authentication secrets protect air access and are unrelated to NAT translation state on the clinic WAN edge. Checking only the EtherChannel LACP system priority on the core fails by concept: LACP priority affects EtherChannel actor selection and bundle formation, not whether inside source NAT is creating translations.

Exam caveat: successful browsing suggests NAT may work, but the translation table is the definitive associate-level verification artifact—and empty tables after traffic usually point to mis-marked inside/outside interfaces, ACL mismatch, or missing pool/overload configuration. Operational check: clear or note existing translations if appropriate, generate clerk outbound traffic from an inside host, then use NAT show commands to confirm inside local → inside global entries and matching hit counters on the clinic edge.