An FMC-managed FTD publishes an API server at 10.5.20.10, whose object already carries static auto NAT to 203.0.113.10 for every source. Traffic from the partner subnet 198.51.100.0/24 must reach the same server through 203.0.113.14 instead, with no extra hardware allowed. Which NAT design in the FMC NAT policy guarantees both mappings?

The required design is a source-qualified static translation for traffic from 198.51.100.0/24 to the server’s alternate public address, 203.0.113.14. A manual NAT rule can specify that source and destination mapping, and manual rules are evaluated before object-based auto NAT, so the partner traffic matches the exception before the broader server mapping to 203.0.113.10. The existing auto NAT can continue serving other sources with the original address. A second object-based auto NAT is not suitable because object NAT is tied to the real server object and does not provide the needed source-qualified mapping to distinguish the partner subnet for that same server. A source-specific manual NAT rule placed after the object’s auto NAT has the right kind of match, but the auto NAT can match first and translate the traffic to .10 before the exception is considered. Dynamic PAT to 203.0.113.14 translates source addresses for outbound sessions; it does not publish the server at .14 for inbound connections, so it fails to provide the required destination mapping. Exam caveat: FMC NAT ordering and section placement matter; verify how FTD evaluates the rules rather than relying only on their apparent policy position. Practical check: deploy the policy and use packet-tracer or equivalent connection testing with partner and non-partner sources, confirming the partner maps to .14 and the other source maps to .10.