Cyber Security Quiz: Network Diagrams And Data Flows
10 questions · exam conditions
0:00
Network Diagrams And Data FlowsQuestion 1 of 10

External clients connect to a reverse proxy, which then creates separate TCP connections to an internal application server. The proxy does not insert an X-Forwarded-For header or use the PROXY protocol. Application logs show repeated malicious requests, all with the same source address.

Which data source is most useful for identifying the external client associated with a malicious application request?

The application log, because its source field retains the original external client address.
The reverse proxy access log, because it can map client requests to proxied requests.
The application server's ARP cache, because it records the external client's hardware address.
The internal router's route table, because it records each client's established TCP session.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Network Diagrams And Data Flows

Practice Network Diagrams And Data Flows 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 Network Diagrams And Data Flows, 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

External clients connect to a reverse proxy, which then creates separate TCP connections to an internal application server. The proxy does not insert an X-Forwarded-For header or use the PROXY protocol. Application logs show repeated malicious requests, all with the same source address.

Which data source is most useful for identifying the external client associated with a malicious application request?

  1. The application log, because its source field retains the original external client address.
  2. The reverse proxy access log, because it can map client requests to proxied requests. (correct answer)
  3. The application server's ARP cache, because it records the external client's hardware address.
  4. The internal router's route table, because it records each client's established TCP session.
Explanation: When a reverse proxy sits between external clients and an internal server, it terminates the client's TCP connection and opens a new, separate connection to the backend. This means the application server only ever sees the proxy's IP address as the source — not the real client's. The key question becomes: which component actually observed the original client? The reverse proxy did. It accepted the external client's connection directly, so its access log records both the client's real IP and the corresponding proxied request it forwarded upstream. That mapping — external client → internal request — is exactly what you need to link a malicious application-layer event back to its true origin. This makes B the correct answer. A is the trap most students fall for. Because the proxy doesn't insert X-Forwarded-For headers or use the PROXY protocol, the application server has no mechanism to learn the original client address. Its logs will show the proxy's internal IP as the source, not the attacker's. The "source field" in the application log is essentially useless for attribution here. C is wrong because ARP (Address Resolution Protocol) operates at Layer 2 and only resolves MAC addresses within the local network segment. External clients are never on the same LAN, so their hardware addresses never appear in the application server's ARP cache. D is wrong because routing tables store network paths, not session state. They tell a router where to forward packets, not who initiated which TCP connection. When you see proxy-based architectures on the exam, always ask: which component saw the original client? That component's logs hold the attribution data.

Question 2

A workstation in VLAN 10 and a server in VLAN 20 connect to the same managed switch. The switch provides only Layer 2 forwarding. A firewall connected by an 802.1Q trunk has one logical interface in each VLAN and serves as the default gateway for both hosts. Firewall policy permits the workstation to reach the server.

After resolving its default gateway's address, which path does the workstation's first routed packet take?

  1. Workstation to switch to server, because both hosts use the same physical switch.
  2. Workstation to switch to default router, then to an Internet gateway before reaching the server.
  3. Workstation to firewall to server directly, because the trunk bypasses Layer 2 switching.
  4. Workstation to switch to firewall to switch to server, because routing occurs at the firewall. (correct answer)
Explanation: Whenever you see a question mixing VLANs, Layer 2 switches, and a routed firewall, your first instinct should be to trace traffic based on where routing actually happens — because that single detail determines the entire path. Here, the switch is purely Layer 2. It cannot route between VLAN 10 and VLAN 20 on its own. The firewall is the only device performing Layer 3 routing, and it connects to the switch via an 802.1Q trunk, giving it one logical interface in each VLAN. When the workstation sends a packet destined for the server in VLAN 20, it recognizes the server is on a different subnet, so it forwards the packet to its default gateway — the firewall. That packet travels from the workstation, through the switch (Layer 2 forwarding within VLAN 10), up the trunk to the firewall. The firewall routes the packet and sends it back down the trunk tagged for VLAN 20. The switch then delivers it to the server via Layer 2 forwarding within VLAN 20. The correct path is D: workstation → switch → firewall → switch → server. A is wrong because even though both hosts share the same physical switch, the switch cannot route between VLANs — physical proximity is irrelevant to Layer 3 decisions. B introduces an Internet gateway that has no role here; inter-VLAN traffic stays entirely within the local infrastructure. C claims the trunk "bypasses" Layer 2 switching, which is false — the trunk is just a multi-VLAN link; the switch still performs normal Layer 2 forwarding on both sides. Remember this pattern: a Layer 2 switch + firewall-as-gateway always means the traffic bounces through the firewall and back through the switch — sometimes called a "hairpin" or "tromboning" path.

Question 3

Client HTTPS traffic reaches a load balancer that terminates TLS, applies an HTTP security policy, and then establishes a new TLS session to each application server. A passive sensor monitors the link before the load balancer, and another passive sensor monitors the link between the load balancer and the servers. Neither sensor has TLS session keys.

Which component can inspect the HTTP request path and headers in plaintext?

  1. The external passive sensor, because it observes the original client TLS session.
  2. The internal passive sensor, because it observes traffic after the first TLS session ends.
  3. The load balancer, because plaintext exists between TLS termination and re-encryption. (correct answer)
  4. Both passive sensors, because TLS termination exposes plaintext on adjacent network links.
Explanation: When you see a question involving TLS termination at a load balancer, ask yourself: where does plaintext actually exist? TLS encryption protects data in transit, but something must decrypt it to do anything useful — and that decryption point is where plaintext lives. In this architecture, the load balancer performs TLS termination: it decrypts the incoming client TLS session, processes the raw HTTP request, applies the security policy, then re-encrypts the traffic before forwarding it to the application servers. That processing window — between decryption and re-encryption — is the only place where plaintext HTTP exists. The load balancer can therefore inspect the full request path, headers, cookies, and anything else in the HTTP layer. That makes C correct. A is wrong because the external passive sensor sits on the wire before the load balancer, where traffic is still protected by the original client TLS session. Without the session keys, a passive sensor cannot decrypt the traffic — it only sees ciphertext. B is wrong for a similar reason. The internal link carries a new TLS session that the load balancer established to the backend servers. That traffic is re-encrypted, so the internal passive sensor also sees ciphertext without the keys. TLS termination does not mean the downstream link is unencrypted. D is wrong because it conflates TLS termination with plaintext appearing on the network links. Plaintext is exposed inside the load balancer's memory, not on adjacent wires. Your study tip: always trace where plaintext exists in TLS architectures by following the encrypt → decrypt → re-encrypt chain. The inspection capability belongs to whoever holds the keys and performs the decryption — not whoever passively observes the wire.

Question 4

A remote laptop uses a split-tunnel VPN. Only destinations in 10.0.0.0/8 are sent through the tunnel. The laptop is configured to use corporate DNS server 10.2.0.53. A public software service resolves to 203.0.113.80, and the user accesses it over HTTPS.

Which path description correctly represents the resulting DNS and HTTPS flows?

  1. Both the DNS query and HTTPS connection traverse the VPN because corporate DNS resolved the name.
  2. The DNS query traverses the VPN, while the HTTPS connection uses the local Internet path. (correct answer)
  3. The DNS query uses the local Internet path, while the HTTPS connection traverses the VPN.
  4. Both the DNS query and HTTPS connection use the local path because the service is public.
Explanation: When analyzing split-tunnel VPN behavior, you need to trace each flow independently based on routing rules — don't assume that because one flow uses the tunnel, the other must as well. In a split-tunnel VPN, only traffic destined for specified subnets (here, 10.0.0.0/8) travels through the tunnel; everything else exits directly to the Internet. The corporate DNS server sits at 10.2.0.53, which falls within 10.0.0.0/8. Therefore, the DNS query is routed through the VPN tunnel to reach that server. Once the DNS response comes back with 203.0.113.80 — a public IP address — the laptop now needs to send HTTPS traffic to that destination. Since 203.0.113.80 does not fall within 10.0.0.0/8, the routing policy sends it straight out the local Internet connection, bypassing the tunnel entirely. This confirms B as correct: DNS through the tunnel, HTTPS over the local path. Answer A is wrong because it assumes that wherever the name was resolved, the resulting connection follows the same path. That's not how routing works — destination IP address determines the path, not who resolved the name. Answer C inverts the flows entirely, incorrectly claiming the DNS query skips the tunnel while HTTPS uses it. Since 203.0.113.80 isn't in 10.0.0.0/8, HTTPS would never enter the tunnel. Answer D correctly identifies that the HTTPS traffic takes the local path, but wrongly claims DNS does too — it ignores that the DNS server itself lives inside the tunneled subnet. A reliable study pattern: always evaluate DNS and data flows separately by checking whether each destination IP matches the tunnel's routing policy.

Question 5

A security gateway has these routes: 172.16.0.0/16 through a site-to-site VPN, 172.16.8.0/24 through an inspection firewall, and a default route to the Internet edge. The inspection firewall permits TCP port 443 to 172.16.8.0/24 but denies TCP port 22. A workstation sends an SSH packet to 172.16.8.9.

Which path and outcome should be expected?

  1. The packet enters the VPN using the /16 route and reaches the destination over TCP port 22.
  2. The packet reaches the inspection firewall using the /24 route and is translated to TCP port 443.
  3. The packet follows the default route to the Internet edge and is denied as private-address traffic.
  4. The packet reaches the inspection firewall using the /24 route and is denied by policy. (correct answer)
Explanation: When a router or security gateway must forward a packet, it always selects the most specific matching route — the one with the longest prefix (highest subnet mask value). This is the foundational concept being tested here, combined with firewall policy enforcement. For a packet destined to 172.16.8.9, the gateway compares all available routes. The /16 route (172.16.0.0/16) matches, but so does the /24 route (172.16.8.0/24). Because /24 is more specific than /16, the gateway forwards the packet toward the inspection firewall, not the VPN. Once it arrives at the inspection firewall, the policy is applied: TCP port 443 is permitted, but TCP port 22 (SSH) is explicitly denied. The packet is dropped — making D the correct answer. Choice A is wrong because it assumes the /16 VPN route wins, ignoring the longest-prefix rule. The /24 route is always preferred over /16 when both match. Choice B introduces a concept — port translation — that has no basis in the scenario. Firewalls don't silently reroute denied traffic to a different port; they permit or deny it. Choice C would only apply if no more-specific route existed and the packet fell through to the default route, but both the /16 and /24 routes match 172.16.8.9, so the default route is never consulted. Study tip: Whenever you see overlapping routes in a question, immediately identify the longest prefix match first — routing decisions happen before firewall policy. Lock in the path, then apply the rules.

Question 6

Two employee endpoints in the same VLAN communicate through a single access switch. The switch uplinks to a core switch, which connects to the Internet firewall. A network intrusion detection sensor currently monitors only the firewall's external interface. Investigators need visibility into suspected lateral scanning between the two endpoints.

Which monitoring change is most likely to provide the required visibility?

  1. Mirror the endpoint VLAN's access-switch ports or VLAN to an internal sensor. (correct answer)
  2. Move the existing sensor from the external interface to the firewall's Internet gateway.
  3. Mirror only the core switch's link to the Internet firewall to the existing sensor.
  4. Enable additional logging on the perimeter router's public-facing routing protocol.
Explanation: When investigating lateral movement — malicious traffic between internal hosts rather than traffic crossing the network perimeter — your first instinct should be to ask: where does that traffic actually flow? Internal host-to-host communication never reaches the firewall's external interface, so any sensor positioned at the perimeter is blind to it. In this scenario, both endpoints share the same VLAN on the same access switch. Their traffic flows entirely within that switch — it never travels up to the core switch or out to the firewall. The only place to capture it is at the source: the access switch itself. Answer A is correct because port mirroring (SPAN) on the access switch — either on the specific ports or across the entire VLAN — sends a copy of that intra-VLAN traffic to an internal sensor, giving investigators exactly the visibility they need. Answer B is wrong because moving the sensor to the firewall's Internet gateway still positions it at the perimeter; lateral scanning traffic between internal hosts will never reach that point. Answer C fails for the same reason — the core-switch-to-firewall link only carries traffic destined for or arriving from the Internet, not internal east-west traffic between two hosts in the same VLAN. Answer D is a red herring entirely; perimeter router routing-protocol logs track routing adjacencies and path advertisements, not host-level scanning behavior inside the LAN. Study tip: On network security questions, always mentally trace the traffic path before choosing a monitoring point. East-west (lateral) traffic demands internal visibility; north-south (perimeter) traffic demands external visibility — they require different sensor placements.

Question 7

An Internet-facing firewall translates public address 198.51.100.20 to DMZ web server 10.20.30.10. The appliance performs destination NAT before evaluating its external-to-DMZ security policy, and its rules reference post-NAT addresses. A rule currently permits inbound TCP port 443 to 198.51.100.20, but connection attempts are denied by policy.

Which rule change should permit the published HTTPS service while preserving the narrowest access?

  1. Permit external sources to 198.51.100.20 on TCP port 443 in the external zone.
  2. Permit external sources to 10.20.30.10 on TCP port 443 in the DMZ zone. (correct answer)
  3. Permit the DMZ server to external sources on TCP port 443 in the external zone.
  4. Permit external sources to 10.20.30.10 on all TCP ports in the DMZ zone.
Explanation: When a firewall performs destination NAT before policy evaluation and its rules reference post-NAT addresses, you must write rules against the translated (real) address, not the original public-facing one. This is the core concept being tested: understanding at which point in the packet-processing pipeline NAT occurs relative to policy lookup. Because the firewall translates 198.51.100.20 → 10.20.30.10 before checking its security policy, by the time the firewall evaluates any rule, the destination in the packet is already 10.20.30.10. The correct fix is B — permit external sources to 10.20.30.10 on TCP 443 in the DMZ zone. This matches exactly what the firewall "sees" after NAT, in the correct zone where the server actually lives, and restricts access to only port 443, preserving the narrowest possible access. A is wrong because it references the pre-NAT public address (198.51.100.20). Since policy is evaluated after translation, no packet will ever match a rule targeting that address — which is precisely why connections are currently being denied despite the existing rule. C reverses the traffic direction entirely, permitting the server to initiate outbound traffic to external hosts. That's the opposite of what's needed and would expose nothing useful. D matches the correct post-NAT address and zone but opens all TCP ports to the server rather than just 443, violating the principle of least privilege and widening the attack surface unnecessarily. Study tip: Whenever you see NAT + firewall policy questions, always ask: does the platform evaluate policy pre-NAT or post-NAT? That single answer determines which address your rules must reference.

Question 8

A public client reaches a web server through FW-A. The web server has a default route through FW-B. FW-A and FW-B are independent stateful firewalls and drop packets that do not belong to sessions observed locally. The client sends a TCP SYN through FW-A, and the server replies with a SYN-ACK through FW-B.

Which outcome is most likely, and what is the most direct network correction?

  1. FW-B drops the SYN-ACK; route the server's return traffic through FW-A. (correct answer)
  2. FW-A drops the original SYN; route the client's outbound traffic through FW-B.
  3. FW-B forwards the SYN-ACK; add a static route on the client through FW-A.
  4. FW-A forwards the full session; configure the server to use both gateways equally.
Explanation: When you see a question involving stateful firewalls and asymmetric routing, focus on one core principle: a stateful firewall only forwards packets that belong to sessions it has already observed. If the outbound and return paths pass through different firewalls, each firewall sees only half the conversation — and that's a problem. Here's what happens in this scenario. FW-A sees the client's TCP SYN and records it as a new session. So far, so good. But the server's SYN-ACK travels back through FW-B, which never saw the original SYN. From FW-B's perspective, this SYN-ACK belongs to no known session, so it drops it. The TCP handshake never completes, and the connection fails. The fix is straightforward: route the server's return traffic back through FW-A, the firewall that has session state for this connection. That makes answer A correct. Answer B is wrong because FW-A successfully forwards the original SYN — it has no reason to drop outbound traffic from a new connection. The problem lies entirely on the return path, not the outbound path. Answer C is wrong because FW-B doesn't forward the SYN-ACK; it drops it, since it has no session context. Answer D is wrong because FW-A never sees the full session under the current topology — load-balancing across both gateways equally would actually worsen asymmetric routing problems, not resolve them. As a study tip, remember this pattern: asymmetric routing + stateful firewall = broken sessions. Whenever you see two separate firewalls on inbound and outbound paths, immediately suspect that return traffic will be dropped.

Question 9

Client VLANs may send UDP and TCP port 53 only to an internal recursive DNS resolver. The resolver may send UDP port 53 to Internet authoritative DNS servers. The firewall is stateful. Most lookups succeed, but responses requiring truncation and TCP retry consistently fail.

Which firewall change most directly restores those lookups without allowing clients to query external DNS servers directly?

  1. Allow client VLANs to send outbound TCP port 53 to any Internet DNS server.
  2. Allow Internet DNS servers to initiate TCP port 53 sessions toward all client VLANs.
  3. Allow the resolver to send outbound TCP port 53 to Internet DNS servers. (correct answer)
  4. Allow the resolver to receive new inbound UDP port 53 sessions from the Internet.
Explanation: When DNS responses exceed 512 bytes (common with DNSSEC or large record sets), the authoritative server sets the TC (truncation) bit and the client retries over TCP port 53. In this scenario, that retry happens between the resolver and the Internet authoritative servers — not between clients and the Internet. So when you see TCP/53 failures paired with truncation, your first instinct should be: which device is doing the TCP retry, and what rule is blocking it? The resolver is already permitted to send UDP port 53 outbound to Internet servers, but there's no rule allowing it to send TCP port 53 outbound. Since the firewall is stateful, allowing the resolver to initiate TCP port 53 outbound automatically permits the return traffic — no separate inbound rule needed. That's exactly what C does, and it's the most direct, minimal fix. A is wrong because it grants clients direct TCP access to external DNS servers, which explicitly violates the policy of keeping client queries internal. B is a significant security hole — it allows any Internet host to initiate inbound TCP sessions toward all client VLANs, which is both dangerous and architecturally backwards (clients don't receive DNS via inbound sessions). D addresses inbound UDP from the Internet to the resolver; while return UDP traffic is already handled by the stateful firewall for existing sessions, this rule would allow unsolicited external UDP queries to reach the resolver, which is unnecessary and risky. As a study tip: always trace which device generates the retry traffic and which protocol it uses — firewall rules fail silently when you fix the wrong hop.

Question 10

The network is segmented as follows: Internet clients may reach a DMZ application server on TCP port 443. The DMZ application server may initiate connections to an internal database on TCP port 5432. Administrators may reach the application server on TCP port 22 only from a management subnet. All other interzone traffic is denied.

If the application server is compromised, which data flow is already permitted by the network controls?

  1. A connection from the application server to the database on TCP port 5432. (correct answer)
  2. A connection from the application server to management hosts on TCP port 22.
  3. A connection from an Internet client directly to the database on TCP port 5432.
  4. A connection from the database to the application server on arbitrary TCP ports.
Explanation: When analyzing network segmentation and firewall rules, your job is to read the existing policy carefully and identify which flows are explicitly permitted — not which flows seem logical or desirable. A compromised host can only abuse flows the firewall already allows. The passage defines three permitted flows: Internet → DMZ on 443, DMZ application server → internal database on 5432, and management subnet → application server on 22. If an attacker gains control of the application server, they inherit whatever outbound connections that server is already authorized to make. Because the policy explicitly permits the application server to initiate connections to the database on TCP port 5432, that path is immediately available to the attacker — no firewall bypass required. This is the core danger of a DMZ compromise: the server becomes a pivot point into the internal network using legitimate, approved channels. A is correct. B is wrong because the policy only permits connections from the management subnet to the application server on port 22, not the reverse. The compromised server reaching out to management hosts on port 22 is a different direction entirely, and "all other interzone traffic is denied" blocks it. C is wrong because Internet clients are restricted to reaching the DMZ on port 443 only — direct Internet-to-database connections are explicitly blocked by the segmentation design. This is precisely why a DMZ exists. D is wrong because the database initiating arbitrary connections back to the application server is not described anywhere in the policy; no such rule exists. For exam questions like this, always map out direction and port for each stated rule. Attackers exploit permitted flows — treat every allowed path as a potential lateral movement vector.