Cyber Security Quiz: Nat
10 questions · exam conditions
0:00
NatQuestion 1 of 10

An incident responder receives a complaint that malicious traffic originated from the company's public address at 10:15:27 UTC. Hundreds of employee devices access the Internet through one stateful PAT gateway. The complainant provides the public source address, public source port, destination address, destination port, transport protocol, and timestamp.

Which additional records are most directly needed to identify the internal device responsible for the reported connection?

DNS query logs and the gateway's current ARP table, correlated by the reported destination address
The gateway's routing table and firewall rule set, correlated by the reported public source address
Historical PAT mappings and device-assignment records, correlated by protocol, translated port, and synchronized time
Current PAT mappings and switch MAC tables, correlated only by the reported public source address
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Nat

Practice Nat in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Nat, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

An incident responder receives a complaint that malicious traffic originated from the company's public address at 10:15:27 UTC. Hundreds of employee devices access the Internet through one stateful PAT gateway. The complainant provides the public source address, public source port, destination address, destination port, transport protocol, and timestamp.

Which additional records are most directly needed to identify the internal device responsible for the reported connection?

  1. DNS query logs and the gateway's current ARP table, correlated by the reported destination address
  2. The gateway's routing table and firewall rule set, correlated by the reported public source address
  3. Historical PAT mappings and device-assignment records, correlated by protocol, translated port, and synchronized time (correct answer)
  4. Current PAT mappings and switch MAC tables, correlated only by the reported public source address
Explanation: When hundreds of devices share a single public IP through Port Address Translation (PAT), the gateway distinguishes each internal session by assigning a unique public source port. To reverse that mapping — going from "public IP + public port" back to "private IP + private port" — you need the gateway's PAT translation logs captured at the exact moment the traffic occurred. That's precisely what C describes: historical PAT mappings (the logged translations, not just current ones) combined with device-assignment records (DHCP logs or static assignments tying a private IP to a hostname or user), correlated by protocol, translated port, and a synchronized timestamp. The protocol matters because PAT tracks TCP and UDP separately; the translated port is the unique identifier linking the public session to the internal device; and synchronized time ensures you're looking at the right mapping — PAT entries expire and get reused constantly. Choice A fails because DNS query logs and ARP tables tell you what names were resolved or what MAC addresses were seen, not which internal IP was translated to which public port at a specific time. Choice B is a dead end — routing tables and firewall rule sets govern how traffic is forwarded and filtered, not how individual sessions are translated or attributed. Choice D is tempting because it mentions PAT mappings, but two flaws sink it: "current" mappings won't reflect a session from minutes or hours ago (entries expire), and correlating only by public source address is insufficient — every device on the network shares that same public address. Study tip: On networking forensics questions, always ask yourself whether you need current state or historical logs. PAT attribution almost always requires time-stamped historical records.

Question 2

An internal client sends a UDP request through a stateful NAT gateway. The gateway creates a temporary mapping and forwards the request. The mapping expires before the remote server sends its response. No static forwarding rule exists.

What is the most likely result when the delayed response reaches the gateway?

  1. The gateway drops the response because no active mapping identifies an internal destination for the packet (correct answer)
  2. The gateway recreates the mapping from the destination port and forwards the response to the original client
  3. The gateway broadcasts the response internally because the translated address belongs to multiple private hosts
  4. The gateway forwards the response after replacing its destination with the network's default gateway address
Explanation: When you see a question about NAT gateways, focus on how stateful NAT works: the gateway maintains a translation table of active mappings that pair internal private addresses with external connections. These mappings are temporary — they exist only as long as the session is considered active. Here's the core issue: when a mapping expires, the gateway has no record linking an incoming packet to any internal host. The gateway is fundamentally stateful, meaning it only forwards traffic it can match to an existing session entry. When the delayed UDP response arrives after the mapping has expired, the gateway searches its translation table, finds nothing, and drops the packet. This is option A — and it's correct. The gateway isn't being "strict" by design preference; it literally has no information about where to send the packet. Option B is tempting but wrong — the gateway cannot recreate a mapping from a destination port alone. The destination port on the incoming response points to the gateway itself, not to any internal host, and there's no reverse-lookup mechanism to rediscover the original sender. Option C describes broadcast behavior, which NAT never performs; each mapping is one-to-one between an internal host and an external endpoint, so "multiple private hosts" sharing one translation doesn't apply here. Option D is nonsensical in this context — replacing the destination with the default gateway address would create a routing loop or dead-end, and NAT has no logic to do this. Study tip: Remember that stateful NAT is entirely dependent on its session table — if the entry is gone, the connection is gone. For UDP especially, where there's no handshake to signal session end, short mapping timeouts are a common source of dropped responses.

Question 3

All workstations in an office reach a cloud application through a source NAT gateway. The application records only the apparent client IP address and applies a per-IP login-failure threshold. After several employees mistype their passwords, every employee is temporarily blocked.

Which explanation and mitigation best address the behavior?

  1. NAT removed the usernames from the application requests; disabling address translation will restore account-level authentication
  2. NAT changed each destination address to the gateway address; adding internal DNS records will separate employee sessions
  3. NAT made clients share one visible source address; use authenticated identity or trusted per-client metadata for rate limiting (correct answer)
  4. NAT merged the clients' transport sessions into one connection; increasing the gateway's session timeout will separate the users
Explanation: Whenever you see a question involving NAT (Network Address Translation) and access controls, focus on what the application actually sees — not what's happening internally on the network. Source NAT works by replacing each client's private IP address with a single public IP before packets leave the gateway. This means the cloud application has no way to distinguish between employees — every request appears to originate from the same IP address. When the application enforces a per-IP login-failure threshold, failed attempts from any employee drain a shared counter, and once that threshold is hit, the single visible IP gets blocked, locking out everyone simultaneously. The correct answer is C because it accurately identifies the root cause (shared visible source address) and prescribes a meaningful fix: shift rate limiting away from IP address toward authenticated identity (usernames, tokens, session cookies) or trusted per-client metadata injected by the gateway. A is wrong on two counts — NAT operates at the network layer and never touches usernames or application-layer credentials, and disabling NAT would expose private internal addresses, not fix the rate-limiting logic. B confuses source NAT with destination NAT (DNAT); source NAT changes the source address, not the destination, so adding internal DNS records is completely irrelevant here. D reflects a misconception about how NAT works — source NAT rewrites addresses, not sessions; individual TCP/UDP sessions remain separate, so adjusting session timeouts has no effect on the application's IP-based blocking. As a study tip, remember that NAT problems almost always hinge on what the receiving system sees — train yourself to trace the packet from sender to receiver and ask what information survives the translation.

Question 4

A company uses dynamic NAT with a pool of public addresses rather than PAT. Each active internal host temporarily receives one public address from the pool. A partner reports suspicious activity from one pool address, but the company's current translation table assigns that address to a different host than it did earlier.

Which evidence provides the strongest basis for historical attribution?

  1. Time-synchronized historical address-allocation logs showing which internal host held that public address during the event (correct answer)
  2. The current translation table showing which internal host holds that public address at the time of investigation
  3. The pool configuration showing every internal host that was eligible to receive that public address during operations
  4. The partner's reverse-DNS lookup showing the organization that registered the reported public address block
Explanation: When investigating incidents involving dynamic NAT, the core challenge is temporal attribution — connecting a public IP address to a specific internal host at the exact moment the suspicious activity occurred. NAT pools constantly reassign addresses as sessions open and close, meaning the same public IP can represent many different internal hosts over time. The critical word in every attribution question is "when." This is exactly why A is correct. Time-synchronized historical allocation logs create an immutable, timestamped record mapping each public address to its internal host during a specific window. If the partner can tell you the suspicious activity happened at 14:32 UTC on Tuesday, those logs let you pinpoint which internal host held that address at precisely that moment — that's actionable, forensically sound attribution. B is the most tempting trap: the current translation table only reflects right now, not during the incident. Because dynamic NAT reassigns addresses continuously, today's mapping is forensically irrelevant to yesterday's event. This is exactly the scenario the passage describes — the address has already moved to a different host. C tells you who could have used that address, not who did. Eligibility lists cover every host in the NAT pool, which could be hundreds of machines — that's not attribution, it's a suspect list with no useful filtering. D identifies the organization that owns the IP block, not the individual internal host responsible. Reverse-DNS attribution only gets you as far as "this company's address range," which the partner likely already knew. The study tip here: whenever NAT and incident attribution appear together, always ask "does this evidence include a timestamp tied to the event?" If not, it cannot reliably identify who did what when.

Question 5

A home router normally blocks unsolicited inbound traffic while providing PAT for internal devices. A compromised internal media device uses an automatic port-mapping protocol to request a persistent inbound mapping. The router grants the request.

Which conclusion is most accurate?

  1. The device remains protected because only mappings entered manually by an administrator can accept unsolicited inbound connections on any port
  2. The granted mapping can expose the device's service to unsolicited inbound traffic, even though other unmatched inbound traffic remains blocked (correct answer)
  3. The mapping allows only return traffic because every PAT entry requires the internal device itself to initiate each external session first
  4. The mapping exposes all internal devices because PAT cannot associate an inbound destination port with a single specific host
Explanation: When you see a question mixing PAT (Port Address Translation) with automatic port-mapping protocols like UPnP (Universal Plug-and-Play), focus on what a router's NAT table actually controls: which inbound destination port maps to which internal host. Under normal PAT, the router only creates table entries when an internal device initiates outbound traffic, so unsolicited inbound packets have no matching entry and are silently dropped. The critical twist here is that UPnP allows devices to request the router create a persistent mapping without any outbound session — bypassing that protection entirely. B is correct because once the router grants the mapping, inbound packets arriving on that specific destination port are forwarded directly to the compromised device. The rest of the NAT table is unaffected, so other unmatched inbound traffic is still blocked — but for that one mapped port, the device is now reachable from the internet without any prior internal initiation. A is wrong because it assumes only administrator-configured mappings can accept inbound connections. UPnP (and similar protocols like NAT-PMP) exist precisely to let devices create mappings programmatically, without manual admin intervention. C is wrong because it describes normal PAT behavior — return traffic only, requiring internal initiation first. A UPnP-granted persistent mapping breaks that rule; inbound traffic arrives without the device initiating the session. D is wrong because PAT absolutely can associate an inbound destination port with a single specific internal host. That is the core function of port forwarding; it doesn't expose all devices, only the mapped one. Study tip: Remember that UPnP effectively gives untrusted devices the power to poke holes in your firewall. On exam questions, whenever a device "requests" or "negotiates" a mapping, treat that as equivalent to manual port forwarding in terms of inbound exposure.

Question 6

A perimeter device applies a static one-to-one NAT mapping from a public address to a private server address. The device's security policy separately permits only TCP port 443 to that mapped server and denies other unsolicited inbound traffic.

What does the static mapping alone imply about the server's exposure?

  1. It exposes every listening service because a one-to-one mapping bypasses the device's security policy
  2. It establishes an address translation, while the separate security policy still determines which inbound services are reachable (correct answer)
  3. It prevents all unsolicited connections because private addresses cannot receive traffic initiated from a public network
  4. It exposes only services previously contacted outbound because static mappings behave like temporary PAT entries
Explanation: Whenever you see a question mixing NAT with firewall policy, keep two functions mentally separate: address translation and access control. These are distinct mechanisms that work in layers — one does not override the other. Static one-to-one NAT simply creates a persistent, bidirectional mapping between a public IP and a private IP. It tells the device where to forward packets, but says nothing about which packets are allowed through. The security policy — the permit/deny ruleset — is what actually governs which traffic reaches the server. Because the scenario explicitly states a separate policy permitting only TCP 443, that policy remains fully in effect. This is exactly what B captures: the static mapping handles address translation, while the security policy independently controls reachability. A is wrong because it invents a bypass that doesn't exist. Static NAT does not override or circumvent the device's security policy — both rules coexist and are enforced together. This is a classic trap that conflates "reachable by address" with "permitted by policy." C describes a property of private RFC 1918 addresses on an un-NATted network, but once a static public-to-private mapping exists, external hosts absolutely can initiate connections — the NAT itself creates that reachability. The security policy is what limits it, not address privacy. D confuses static NAT with dynamic PAT entries. PAT (port address translation) creates temporary, state-table-driven mappings for outbound sessions. Static NAT is permanent and not session-dependent. On security exams, always ask yourself: "Is this question about translation or access control?" Treat them as separate layers — NAT maps addresses; firewall rules permit or deny traffic.

Question 7

A workstation is behind an office NAT gateway, and the office gateway is behind an Internet provider's carrier-grade NAT. A remote service reports abuse from the provider's public address and supplies the translated source port, protocol, destination tuple, and an exact UTC timestamp.

Which investigation method is most likely to identify the workstation?

  1. Query only the office gateway's current session table, since the provider's public tuple and port together uniquely point to the internal workstation without requiring the provider's records
  2. Query only the provider's subscriber records, since carrier-grade NAT preserves each workstation's private source address in the outer IP header for attribution purposes
  3. Correlate the reported tuple directly with the office DHCP logs, since both NAT layers retain the workstation's original source port unchanged through each translation boundary
  4. Correlate the provider's historical mapping to the office connection using the reported tuple and timestamp, then correlate the office gateway's historical mapping to the workstation using that intermediate tuple (correct answer)
Explanation: When abuse is reported through double NAT — carrier-grade NAT (CGNAT) at the provider level, then a second NAT at the office gateway — no single log can bridge both translation layers at once. You need to walk the chain backward, one hop at a time, using timestamps to anchor each correlation. This is exactly what D describes. First, you bring the reported tuple (public IP, translated port, protocol, destination, timestamp) to the provider, who maps it to the office gateway's external IP and the specific port/session active at that moment. That gives you the intermediate tuple — the office gateway's outbound connection as seen by the provider. Then you bring that intermediate tuple and timestamp to the office gateway's NAT logs, which maps it back to the internal workstation's private IP. Two hops, two lookups, correct attribution. A fails because the office gateway's current session table only reflects live connections — historical abuse won't appear there. More critically, without the provider's log, you don't even know which office connection corresponds to the reported public address. B is wrong because CGNAT does not preserve or expose a subscriber's private source address in any outer IP header. The provider only sees its own public address pool; internal addressing is invisible to them. C is a subtle trap. Each NAT boundary rewrites source ports — they are not preserved end-to-end. DHCP logs record IP lease assignments, not port translation mappings, so they cannot directly correlate the reported translated port. Study tip: Whenever you see layered NAT in an investigation scenario, mentally draw each translation boundary and ask which log owns the mapping at that specific hop — no single source spans all layers.

Question 8

An organization is migrating a public service from IPv4 behind destination NAT to globally addressed IPv6. The administrator assumes that removing NAT will automatically make the IPv6 service reachable from the Internet, but the perimeter firewall still denies unsolicited inbound IPv6 traffic.

Which statement best evaluates the administrator's assumption?

  1. It is correct because globally unique IPv6 addressing automatically overrides stateful firewall rules at the perimeter
  2. It is correct because NAT is the only mechanism that can prevent unsolicited traffic from reaching a public service
  3. It is incorrect because removing translation changes addressing, while firewall policy independently controls inbound reachability (correct answer)
  4. It is incorrect because IPv6 hosts require destination NAT before globally addressed services can accept inbound traffic
Explanation: When you see a question mixing IPv6 migration with firewall behavior, the key is recognizing that network addressing and access control are independent layers. Changing how traffic is addressed does not automatically change whether that traffic is permitted. In IPv4 environments, destination NAT often creates an implicit dependency — the NAT device sits at the perimeter and only forwards traffic it's been explicitly configured to translate, which incidentally blocks everything else. Administrators sometimes mistake this side effect for intentional security. When migrating to IPv6 with globally routable addresses, NAT disappears, but the perimeter firewall remains a completely separate enforcement point with its own ruleset. If that firewall is configured to deny unsolicited inbound traffic (a common default-deny stance), it will continue doing so regardless of whether addresses are translated or not. Answer C captures this precisely: removing NAT changes the addressing mechanism, while firewall policy independently governs inbound reachability. The administrator must explicitly update firewall rules to permit the new IPv6 traffic. A is wrong because globally unique IPv6 addresses carry no special privilege that "overrides" stateful firewall rules — firewalls evaluate policy, not address scope. B is wrong because it embeds the exact misconception the question is testing: NAT is not the only mechanism preventing unsolicited traffic; stateful firewalls serve this function independently, and in IPv6 environments they are the primary mechanism. D is wrong because IPv6 was specifically designed to eliminate the need for NAT; requiring destination NAT for globally addressed IPv6 services contradicts the entire architecture. As a study tip, remember: NAT ≠ firewall. On security exams, any answer conflating translation with access control is almost always a trap.

Question 9

A law-enforcement request identifies abusive traffic from an address assigned to an Internet service provider's carrier-grade NAT gateway. The request includes the destination address and an approximate five-minute time window but does not include the observed public source port.

Why may the provider be unable to attribute the traffic to a subscriber with confidence?

  1. Carrier-grade NAT replaces destination ports, so the provider would instead need the client's private destination port
  2. Carrier-grade NAT encrypts transport headers, so only the destination service can identify the subscriber
  3. The public address permanently identifies the gateway hardware rather than any subscriber connected through it
  4. Multiple subscribers can share the address concurrently, and the missing source port prevents selection of one translation (correct answer)
Explanation: Whenever you see a question involving carrier-grade NAT (CGNAT) and attribution problems, focus on how NAT works mechanically: it maps (private IP, private port) → (public IP, public port) for each active connection. A single public IP address can represent thousands of simultaneous subscribers, each distinguished only by their assigned public source port. That's exactly why D is correct. During any five-minute window, dozens or hundreds of subscribers may be sharing the same CGNAT public address concurrently. The translation table entry that links a specific subscriber to a specific session is keyed on the public source port — without it, the provider cannot isolate which of those many subscribers generated the traffic. The time window narrows things somewhat, but not to a single subscriber when port information is absent. A is wrong because CGNAT replaces source ports (on outbound traffic), not destination ports. The destination port belongs to the remote server and is untouched by the gateway. Asking for a "private destination port" reflects a fundamental misunderstanding of how NAT operates. B is wrong because CGNAT does not encrypt anything. It is a network-layer address translation mechanism, not a cryptographic one. Transport headers remain fully visible to the provider — the problem is ambiguity, not concealment. C is wrong because CGNAT public addresses are dynamically shared across subscribers, not permanently tied to hardware. Even if they were hardware-bound, that still wouldn't identify a subscriber. For exam strategy, remember that CGNAT questions almost always hinge on the many-to-one address sharing problem — the source port is the critical disambiguator, and its absence is the classic attribution gap.

Question 10

A small business router performs source NAT for outbound traffic. An administrator adds a destination NAT rule forwarding public TCP port 8443 to TCP port 443 on an internal management server. The router's inbound policy permits traffic matching configured forwarding rules.

Which statement best describes the server's resulting exposure?

  1. The server remains unreachable because source NAT prevents Internet hosts from initiating connections to private addresses
  2. The management service becomes reachable through the public port because destination NAT and the permit policy create an inbound path (correct answer)
  3. The entire server becomes directly Internet-addressable because destination NAT assigns it the router's public address
  4. The service accepts only response traffic because every NAT mapping must originate with an outbound internal connection
Explanation: When a question involves NAT and firewall policy together, resist the temptation to think about each in isolation — the real exposure comes from how they interact as a system. Here, the router runs two distinct NAT functions. Source NAT (SNAT) rewrites the source address on outbound packets so internal hosts appear to come from the public IP — this has no effect on inbound reachability. Destination NAT (DNAT), on the other hand, rewrites the destination address on inbound packets, redirecting traffic arriving at a public IP and port toward an internal host. When the administrator adds a DNAT rule mapping public TCP 8443 → internal TCP 443, the router now has a defined path to forward those inbound packets to the management server. Combined with the inbound policy that permits traffic matching forwarding rules, a complete inbound path exists. Answer B correctly captures this: the service is reachable through the public port because DNAT translates the destination and the policy allows it through. Answer A confuses SNAT with DNAT. SNAT only affects outbound traffic — it does nothing to block inbound connections that DNAT is explicitly designed to handle. Answer C overstates the effect of DNAT; it doesn't make the entire server Internet-addressable or assign it the public IP. Only the specific port being forwarded is exposed — the server keeps its private address. Answer D describes stateful NAT behavior for outbound-initiated sessions (like typical web browsing), not DNAT port forwarding, which explicitly allows external hosts to initiate connections. As a study tip, always ask two questions when evaluating NAT exposure: which direction does the rule act on? and does the firewall policy permit the resulting traffic? Both conditions must be satisfied for a path to exist.