Cyber Security Quiz: Command Line Networking Tools
10 questions · exam conditions
0:00
Command Line Networking ToolsQuestion 1 of 10

The command dig app.example.org A returns 198.51.100.44. A traceroute reaches that address but displays only the numeric address for the final hop. An administrator wants to check whether the address has a reverse-DNS name.

Which command should the administrator use, and what would a negative result establish?

Use dig -x 198.51.100.44; failure would indicate that no PTR record was found for that address.
Use dig 198.51.100.44 A; failure would indicate that the host's forward record is unreachable.
Use nslookup app.example.org; failure would indicate that the A record returned earlier is invalid.
Use ping -a 198.51.100.44; failure would indicate that reverse-DNS lookups are globally unavailable.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Command Line Networking Tools

Practice Command Line Networking Tools 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 Command Line Networking Tools, 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

The command dig app.example.org A returns 198.51.100.44. A traceroute reaches that address but displays only the numeric address for the final hop. An administrator wants to check whether the address has a reverse-DNS name.

Which command should the administrator use, and what would a negative result establish?

  1. Use dig -x 198.51.100.44; failure would indicate that no PTR record was found for that address. (correct answer)
  2. Use dig 198.51.100.44 A; failure would indicate that the host's forward record is unreachable.
  3. Use nslookup app.example.org; failure would indicate that the A record returned earlier is invalid.
  4. Use ping -a 198.51.100.44; failure would indicate that reverse-DNS lookups are globally unavailable.
Explanation: Whenever you see a question about reverse DNS, anchor yourself to one key concept: forward DNS maps names to IP addresses (A records), while reverse DNS maps IP addresses back to names using PTR records stored under the special in-addr.arpa domain. A traceroute showing only a numeric final hop is a classic hint that no PTR record exists — and your job is to verify that. The correct tool for reverse lookup is dig -x, which automatically constructs the proper in-addr.arpa query and requests the PTR record for the given IP. Running dig -x 198.51.100.44 asks the DNS system, "Does anyone have a hostname registered for this address?" If the response is NXDOMAIN or returns no answer section, that confirms no PTR record exists — exactly what answer A describes, making it correct. Answer B is wrong because dig 198.51.100.44 A treats the IP address as a domain name and queries for an A record on it, which is nonsensical — you'd be doing a broken forward lookup, not a reverse one. Answer C is wrong because nslookup app.example.org re-queries the forward DNS for the hostname you already resolved; it tells you nothing about whether the IP has a reverse record, and a failure wouldn't invalidate a previously returned A record. Answer D is wrong because ping -a attempts to resolve a hostname during a reachability test, but a failure could simply mean the host is blocking ICMP — it absolutely does not indicate that reverse DNS is globally broken. Your study tip: memorize the dig -x <IP> syntax as the reverse-lookup command. Exam questions often distract you with forward-lookup tools when the scenario clearly calls for PTR record verification.

Question 2

A technician runs traceroute to a remote server. The first probe is reported by the default gateway, later probes are reported by progressively more distant routers, and the final probes reach the server.

Which behavior primarily allows traceroute to reveal these successive hops?

  1. It sends probes with increasing IP TTL values and records Time Exceeded responses. (correct answer)
  2. It lowers the DNS record TTL until each router returns an authoritative answer.
  3. It broadcasts ARP requests with increasing sequence numbers across routed networks.
  4. It increases the packet size until each router reports a fragmentation failure.
Explanation: When you see a question about how a network diagnostic tool "discovers" intermediate routers, think about how IP's Time-To-Live (TTL) field works. Every IP packet carries a TTL value that each router decrements by one. When a router decrements TTL to zero, it discards the packet and sends an ICMP "Time Exceeded" message back to the source — and critically, that message reveals the router's IP address. Traceroute exploits this behavior deliberately. It sends the first probe with TTL=1, so the default gateway decrements it to zero and replies with Time Exceeded, exposing itself. The next probe uses TTL=2, reaching the second router before expiring. By incrementing TTL with each successive probe, traceroute peels back the network one hop at a time until the final probe reaches the destination and returns a normal reply. This is exactly what answer A describes — and why it's correct. Answer B is a common terminology trap. DNS TTL controls how long a resolver caches a record; it has nothing to do with routing path discovery or router identification. Answer C is wrong on two counts: ARP operates only within a single broadcast domain (Layer 2) and cannot cross routed network boundaries, making it useless for discovering distant hops. Answer D confuses path MTU discovery with traceroute — increasing packet size until fragmentation fails reveals the smallest MTU along a path, not the identity of individual routers. For your exam, remember that "TTL" appears in two completely different contexts: IP packet TTL (hop counter) and DNS record TTL (cache timer). Questions that mix these contexts are testing whether you can keep them separate.

Question 3

A DNS query for dual.example.net returns both an A record and an AAAA record. Running ping dual.example.net selects the IPv6 address and fails with a network-unreachable message. Running ping -4 dual.example.net selects the IPv4 address and receives replies.

Which action and interpretation best follow from these results?

  1. Delete the A record; the IPv4 reply proves the server must use only IPv6.
  2. Flush the DNS cache; the A and AAAA answers prove the resolver is corrupted.
  3. Run an IPv4 traceroute; the evidence points to failure on the working IPv4 path.
  4. Run an IPv6 traceroute; the evidence points to an IPv6 routing or connectivity problem. (correct answer)
Explanation: When troubleshooting dual-stack connectivity (where a host supports both IPv4 and IPv6), your goal is to isolate which stack is failing and then investigate that specific path. The evidence here is clean: IPv6 fails with "network-unreachable," while IPv4 succeeds. That asymmetry tells you exactly where to look. D is correct because the symptom — IPv6 unreachable, IPv4 working — points to a problem in the IPv6 routing infrastructure, not the server or DNS. A traceroute using IPv6 (traceroute6 or traceroute -6) will reveal where along the path connectivity breaks down: your local interface, the default gateway, an upstream router, or a missing route. That's the logical next diagnostic step. A is wrong because deleting the A record is destructive and backwards — IPv4 is the working stack, so removing it would break what's functional. The reasoning ("server must use only IPv6") directly contradicts the evidence. B is wrong because having both an A and AAAA record is completely normal for a dual-stack host — that's exactly how it's supposed to be configured. Nothing about the DNS response suggests corruption; the resolver is doing its job correctly. C is wrong because it proposes investigating the IPv4 path, which is already confirmed working. Running an IPv4 traceroute wastes time examining a path that has no problem. Study tip: On networking and security questions, always match your diagnostic action to the failing component, not the working one. "What's broken?" and "What do I investigate?" should point at the same stack.

Question 4

A traceroute displays the following abbreviated path:

1 10.0.0.1

2 198.51.100.1

3 * * *

4 198.51.100.18

5 203.0.113.40

What is the most accurate interpretation of hop 3?

  1. Hop 3 failed completely, so hop 4 was reached through a backup route.
  2. Hop 3 forwarded the probes but did not return visible traceroute responses. (correct answer)
  3. Hop 3 had no DNS record, so traceroute could not display its address.
  4. Hop 3 dropped every probe, and hop 4 reconstructed the missing packets.
Explanation: When reading a traceroute output, you need to understand what each hop actually represents — and crucially, what the asterisks (* * *) do and don't tell you. A traceroute works by sending probes with incrementally increasing TTL values, then recording the ICMP "Time Exceeded" messages that routers send back. The key insight is that asterisks only mean no response was received — they say nothing about whether the router actually forwarded the packets. Answer B is correct because hop 3's device almost certainly did forward the probes onward (since hop 4 responded normally), but it simply didn't generate or return a traceroute-visible response. Many routers are explicitly configured to suppress ICMP Time Exceeded messages — either for security reasons, rate-limiting policies, or firewall rules — while still routing traffic normally. The path continued to hops 4 and 5, which proves forwarding happened. Answer A is wrong because traceroute doesn't use backup routes when a hop goes silent. There is no failover mechanism being triggered here — traffic followed the same path throughout. Answer C is a common misconception: DNS resolution failure would display the IP address directly rather than asterisks, so missing DNS records produce something like 203.0.113.1 (203.0.113.1), not * * *. Answer D is entirely fabricated — routers don't "reconstruct" missing packets, and packet reconstruction isn't a router function in this context. Your study tip: whenever you see * * * in a traceroute, resist the urge to conclude the hop is "down." Ask yourself — did traffic continue past it? If yes, the hop forwarded packets but filtered responses, which is the far more common real-world scenario.

Question 5

A user reports intermittent application delays. Over the same minute, ping to the local default gateway shows no loss, while ping to the application server shows 40% echo-request loss. A traceroute still reaches the application server.

Which conclusion is justified by these command results alone?

  1. The application is losing exactly 40% of its TCP traffic beyond the gateway.
  2. The local network is healthy because the gateway answered every echo request.
  3. ICMP loss occurs toward the remote target, but its location and application impact remain unproven. (correct answer)
  4. The final router is overloaded because traceroute nevertheless reached the application server.
Explanation: When troubleshooting connectivity, you must resist the urge to over-interpret diagnostic tools. ping and traceroute use ICMP, which many routers and servers deliberately de-prioritize or rate-limit — meaning ICMP behavior doesn't always reflect what TCP application traffic is actually experiencing. Here's why C is the justified conclusion: the data shows ICMP echo-request loss specifically toward the application server. That's real and meaningful — something between you and that server is dropping ICMP packets. However, you cannot yet determine where on the path the loss is occurring (traceroute reaching the destination doesn't pinpoint a lossy hop), nor can you confirm whether TCP application traffic is suffering the same fate, since ICMP and TCP are handled independently by network devices. A is a trap because it extrapolates from ICMP behavior to TCP behavior — two different protocols with different handling priorities. You have no evidence the application's TCP sessions are losing exactly 40% of anything. B overreaches in the other direction: a healthy gateway ping only confirms the local segment is functioning, not the broader network path to the server. The delays could still originate anywhere beyond the gateway. D is a logical non-sequitur — traceroute completing successfully actually suggests the path is reachable, not that any specific router is overloaded. Reaching a destination and being congested are not contradictory states. The study tip here: on exam questions involving ping and traceroute, always ask yourself which protocol is being tested and whether conclusions about application behavior are truly supported. ICMP evidence ≠ TCP evidence.

Question 6

The command dig files.example.net A returns status: NOERROR, an empty ANSWER section, and an SOA record in the AUTHORITY section. No timeout occurs.

What is the best interpretation and next command?

  1. The response is equivalent to NXDOMAIN; repeating the same A query with a different resolver should force the authoritative server to create the missing record.
  2. The DNS server was unreachable when the query was sent; issuing a ping to the DNS server's address will retrieve the missing answer from its cache.
  3. No A data was returned for the name, but the name itself may exist with a different record type; querying its AAAA record is a useful next step. (correct answer)
  4. The SOA record in the AUTHORITY section contains the host's IP address; running traceroute to the SOA serial number will confirm reachability.
Explanation: When you run a DNS query and receive NOERROR with an empty ANSWER section, you're seeing a condition called a "no-data" response — distinct from NXDOMAIN. NXDOMAIN means the name doesn't exist at all; NOERROR with no answers means the name does exist in DNS, but simply has no record of the type you asked for. The SOA record appearing in the AUTHORITY section is the authoritative server's way of saying "I'm responsible for this zone, and I'm definitively telling you there's no A record here" — this is completely normal, expected behavior. That's why C is correct. The hostname files.example.net likely exists but may only have an AAAA (IPv6) record, a CNAME, or another record type. Querying dig files.example.net AAAA is the logical next diagnostic step. A is wrong on two counts: this response is not equivalent to NXDOMAIN (that would show status: NXDOMAIN), and DNS resolvers cannot instruct authoritative servers to "create" records — that's controlled by zone administrators, not query behavior. B is wrong because the question explicitly states no timeout occurred, meaning the server was reachable and responded normally. A clean NOERROR response rules out unreachability entirely. D is wrong because SOA records contain administrative metadata — the zone's primary nameserver, responsible email, and serial/refresh numbers — not IP addresses. Running traceroute to a serial number is nonsensical. Study tip: Memorize the NOERROR + empty answer combination as "name exists, record type doesn't" — it's a common trap question that exploits confusion between NXDOMAIN and no-data responses.

Question 7

A workstation produces these results:

ping 203.0.113.25 returns four replies.

ping portal.example.net reports that the host name cannot be resolved.

dig @1.1.1.1 portal.example.net A returns 203.0.113.25.

Which conclusion is best supported by these results?

  1. The portal is rejecting ICMP echo requests sent using a DNS name.
  2. The workstation's configured name-resolution path should be investigated. (correct answer)
  3. The workstation lacks basic IP connectivity to the portal's network.
  4. The portal's authoritative DNS server has no record for the host.
Explanation: When troubleshooting connectivity problems, always separate the layers: IP reachability, DNS resolution, and application behavior. These three test results tell a clear story when you read them together. The workstation successfully pings 203.0.113.25, proving raw IP connectivity works fine — packets are reaching the portal and returning. Then dig @1.1.1.1 portal.example.net A returns that same IP address, proving the authoritative record exists and a public resolver can find it. The only failure is ping portal.example.net — the workstation cannot resolve the hostname on its own. That gap points directly to the local name-resolution path: whatever DNS servers, hosts files, or resolver settings the workstation is using are failing to translate that name. Answer B is therefore the best conclusion — the local resolution configuration needs investigation. Answer A is wrong because the ping using the IP address succeeds, which rules out ICMP being blocked. If the portal were rejecting ICMP, the IP-based ping would also fail — not just the name-based one. Answer C is wrong for the same reason: a successful ping to 203.0.113.25 is direct proof of IP-level connectivity. Claiming the workstation "lacks basic connectivity" contradicts the first test result entirely. Answer D is wrong because dig @1.1.1.1 explicitly confirms the A record does exist on the authoritative infrastructure. The problem is not with the portal's DNS records — it's with how the workstation resolves names locally. Study tip: When you see split results like "IP ping works, name ping fails," your first instinct should always be DNS resolver configuration on the client side, not the server or the network.

Question 8

After a DNS record is changed, an administrator observes:

dig @ns1.example.net vpn.example.net A returns 203.0.113.80 with a TTL of 300.

dig @10.0.0.53 vpn.example.net A returns 198.51.100.80 with a TTL of 18.

A second query to 10.0.0.53 ten seconds later returns the old address with a TTL of 8.

Which explanation best accounts for the different answers?

  1. The recursive resolver is serving an older cached record that is nearly expired. (correct answer)
  2. The authoritative server is converting the private address through destination NAT.
  3. The recursive resolver is performing a reverse lookup instead of an A-record query.
  4. The authoritative server is unreachable, so dig generated a substitute address.
Explanation: When you see DNS queries returning different IP addresses from different servers, your first instinct should be to think about caching. DNS resolvers store records temporarily based on their Time-To-Live (TTL) values, and a mismatch between what an authoritative server says versus what a recursive resolver returns almost always points to a stale cache. Here, the authoritative server (ns1.example.net) returns the new address 203.0.113.80 with a fresh TTL of 300 seconds — exactly what you'd expect after a DNS record update. The internal recursive resolver (10.0.0.53), however, returns the old address 198.51.100.80 with a TTL of 18 seconds. Ten seconds later, that same resolver returns the same old address with a TTL of 8 seconds — counting down from 18, confirming the record is actively expiring from cache. This countdown behavior is the signature of a cached record nearing its end of life, making A the correct answer. B is a trap that conflates DNS with NAT. NAT translates IP addresses at the network layer during packet forwarding — it has no role in what DNS records are served. C is wrong because a reverse lookup queries PTR records (in the in-addr.arpa zone), not A records, and the dig command shown explicitly requests an A record. D is fabricated behavior — dig does not generate substitute addresses when a server is unreachable; it simply returns an error or no response. As a study tip: when TTL values are counting down between repeated queries to the same resolver, that's a reliable indicator of a cached response — not authoritative data.

Question 9

An organization uses split DNS. The internal DNS server is 10.20.0.53, while remote users normally use a public resolver. An administrator wants to determine whether the internal server returns a private address for payroll.corp.example without changing the workstation's DNS settings.

Which command most directly performs the required test?

  1. dig @10.20.0.53 payroll.corp.example A (correct answer)
  2. dig payroll.corp.example A +short
  3. dig -x 10.20.0.53 +short
  4. traceroute 10.20.0.53
Explanation: When working with DNS troubleshooting questions, ask yourself two things: which server should answer the query, and what type of query is needed? Split DNS means the internal and external servers return different answers for the same hostname — so testing it requires explicitly targeting the internal server. A is correct because dig @10.20.0.53 payroll.corp.example A does exactly what the scenario requires. The @ syntax in dig lets you direct your query to a specific DNS server — in this case the internal resolver at 10.20.0.53 — without touching your workstation's /etc/resolv.conf or network settings. The A record type requests the IPv4 address, so you'll see whether the internal server hands back a private IP (like 10.x.x.x) rather than a public one. B is wrong because omitting @10.20.0.53 means the query goes to your default resolver (the public one), which defeats the entire purpose. The +short flag just compresses output — it doesn't change which server is queried. C is a classic trap: dig -x performs a reverse DNS lookup (PTR record), converting an IP address back to a hostname. Here it would ask "what hostname resolves to 10.20.0.53?" — querying the wrong thing entirely, not testing payroll.corp.example. D is completely off-target. traceroute is a network path tool that maps routing hops to a destination IP; it performs no DNS resolution testing whatsoever. Study tip: Memorize dig @<server> <hostname> <type> as your go-to pattern for targeting a specific DNS server on the exam — the @ symbol is the key detail that separates a targeted query from a default one.

Question 10

Users receive inconsistent DNS results for api.example.com. The host's authoritative server returns the intended address when queried directly, but the administrator suspects that the public delegation chain points some resolvers to an outdated authoritative server.

Which command is most useful for examining the delegation path from the DNS root toward the host's authoritative server?

  1. ping -c 4 api.example.com
  2. dig @ns1.example.com api.example.com A
  3. dig -x api.example.com +short
  4. dig +trace api.example.com A (correct answer)
Explanation: When troubleshooting DNS delegation issues, think about where in the resolution chain the problem lives. If inconsistent results are coming from different resolvers — not the authoritative server itself — you need to trace the full delegation path from the root down, not just query one specific server. That's exactly what D, dig +trace api.example.com A, does. The +trace flag forces dig to bypass your local resolver entirely and walk the delegation chain step by step: starting at a root nameserver, following referrals to the .com TLD servers, then to example.com's nameservers. This exposes exactly which nameservers are being delegated to at each level — making it immediately visible if the public delegation is still pointing to an outdated authoritative server. A (ping -c 4 api.example.com) only tests ICMP reachability and resolves the hostname using your local resolver. It tells you nothing about the delegation chain and doesn't isolate DNS behavior at all. B (dig @ns1.example.com api.example.com A) queries a specific nameserver directly — bypassing delegation entirely. The scenario already tells you the authoritative server returns the correct answer when queried directly, so this confirms what you already know without diagnosing the actual problem. C (dig -x api.example.com +short) attempts a reverse DNS lookup on the hostname rather than an IP, which is semantically incorrect and unrelated to delegation tracing. For exam questions about DNS troubleshooting, ask yourself: am I testing one server, or tracing the whole path? +trace is your tool whenever the question involves delegation chains, referrals, or root-to-authoritative resolution.