Examkin

Network Troubleshooting

486 questions

All types486Multiple choice248Multiple select111Matching61Ordering66
Question 101Question →

Match each physical layer cabling issue or diagnostic scenario with the most appropriate testing tool or verification technique required to identify or locate the root cause.

Click a left item, then click its matching right item

Items

Pinpointing the exact physical distance to a micro-bend anomaly on a single-mode optical fiber run spanning 12 kilometers
Detecting a split pair condition on a newly terminated Cat 6A UTP cable run that successfully passes basic DC continuity wiremap tests
Measuring absolute optical insertion loss in dB across a newly spliced multimode optical fiber link
Tracing an unmapped twisted-pair copper cable drop from a workstation outlet to its corresponding patch panel port without disconnecting active equipment

Matches

Show answer & explanation

Answer

Distance localization on long single-mode fiber matches Optical Time-Domain Reflectometer (OTDR); detecting split pairs passing DC wiremap matches Cable Certifier performing NEXT analysis; measuring insertion loss across fiber matches Optical Power Meter with Optical Light Source; tracing unmapped copper drops matches Tone Generator and Inductive Probe.
Each cabling tool serves a distinct physical layer diagnostic role: OTDR pinpoints event distances along fiber optic strands via reflections; cable certifiers perform frequency sweep NEXT tests to reveal split pair noise anomalies; OPM/light source kits quantify cumulative insertion loss in dB; and tone generator/probe sets non-intrusively trace copper wire runs.

Step-by-Step Solution

1
Analyze the long-distance optical defect localization requirement.
Determine that time-domain analysis is required to map signal reflections over distance.
An Optical Time-Domain Reflectometer (OTDR) measures Rayleigh backscattering and Fresnel reflections to locate defects along a extended fiber run.
2
Analyze split pair fault characteristics on copper twisted-pair cabling.
Recognize that split pairs pass basic continuity tests but cause severe crosstalk.
Conductors are connected to matching pin numbers on both ends (passing DC wiremap), but are split across different physical pairs. A full cable certifier performing high-frequency NEXT testing is necessary to detect the resulting interference.
3
Determine insertion loss measurement requirements for fiber optics.
Pair a light source with an optical power meter.
Insertion loss calculations rely on comparing a known reference light level against received signal power measured by an Optical Power Meter (OPM).
4
Evaluate cable identification tools for unmapped panel ports.
Select a tone generator and inductive probe.
Toning injects an audible signal onto wire conductors, allowing an inductive probe to acoustically pinpoint cable bundles and patch panel terminations.

Key Concept

Physical Cabling Diagnostic Tools and Fault Characteristics
Question 102Question →

A network technician executes the `nslookup server1.lab.local` command from a client workstation to verify hostname resolution. The command yields the following output:

Server: dns1.lab.local
Address: 10.0.0.2

*** dns1.lab.local can't find server1.lab.local: Non-existent domain

Which of the following issues is the most likely cause of this error message?

Show answer & explanation

Answer: The host record (A record) for server1.lab.local is missing from the DNS server database.

Answer

The host record (A record) for server1.lab.local is missing from the DNS server database.
The correct answer identifies that the DNS server responded with an NXDOMAIN (Non-existent domain) message, which confirms the DNS service is operational at 10.0.0.2 but lacks an active host (A) record for the requested hostname.

Step-by-Step Solution

1
Analyze the `nslookup` output lines.
The local workstation successfully contacted the DNS server named `dns1.lab.local` at IP address `10.0.0.2`.
Establishing that the server responded rules out network reachability or local service outage issues.
2
Interpret the specific error string `Non-existent domain` (NXDOMAIN).
Identified that the DNS server searched its records but found no mapping for `server1.lab.local`.
An NXDOMAIN response directly signifies that no corresponding resource record (such as an A or AAAA record) exists in the queried zone file.

Key Concept

Interpreting nslookup output and NXDOMAIN errors during name resolution troubleshooting
Question 103Question →

A network engineer is troubleshooting name resolution issues on a client workstation attempting to resolve a large DNSSEC-signed resource record hosted on an internal DNS server (192.168.10.5). The engineer runs `dig` and receives the following output:

text
$ dig @192.168.10.5 api.internal.corp +dnssec
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41052
;; flags: qr aa tc rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; Truncation occurred.
;; COMMUNICATIONS ERROR: cannot reach server over TCP (192.168.10.5:53)

Which of the following represents the most likely root cause of this failure?

Show answer & explanation

Answer: An intermediate firewall rule is dropping TCP port 53 traffic between the client workstation and the DNS server, preventing query retry after UDP truncation.

Answer

An intermediate firewall rule dropping TCP port 53 traffic between the client workstation and the DNS server, preventing query fallback after UDP payload truncation.
DNS relies on UDP port 53 for fast, low-overhead name resolution. However, when response data (such as large DNSSEC records) exceeds UDP length limits, the server truncates the response and sets the TC (Truncation) flag in the DNS header. By RFC standard, the client resolver must immediately retry the query over TCP port 53. The error message `cannot reach server over TCP` explicitly indicates that while initial UDP queries reach the server, network security filters (firewall/ACL) are blocking TCP port 53 traffic required for the fallback query.

Step-by-Step Solution

1
Analyze the DNS header flags in the `dig` command output.
The `tc` (Truncated) flag is set in the header (`flags: qr aa tc rd ra`), indicating that the complete DNS payload exceeds the maximum allowable UDP packet size (typically 512 bytes without EDNS0 or exceeding negotiated EDNS limits).
When a DNS response is too large to fit in a single UDP datagram, the server truncates the response and sets the TC flag to notify the client.
2
Evaluate the client resolver behavior following UDP truncation.
Standard DNS protocol behavior dictates that upon receiving a response with the TC flag set, the resolver MUST re-issue the query using TCP on port 53.
TCP provides stream-based delivery that accommodates large response payloads (such as DNSSEC keys/signatures or extensive record sets).
3
Interpret the specific communications error in the output.
`COMMUNICATIONS ERROR: cannot reach server over TCP (192.168.10.5:53)` demonstrates that UDP port 53 communication succeeded, but TCP port 53 transport failed.
This distinct differential failure (UDP working, TCP failing) points directly to a firewall/ACL rule blocking TCP port 53 while permitting UDP port 53.

Key Concept

DNS Transport Protocols and TCP Fallback upon Response Truncation (TC Flag)
Question 104Question →

During a data center upgrade, a network engineer is investigating why a newly provisioned storage switch fails to synchronize fabric configuration files with the primary core switch. The engineer performed diagnostic packet captures and verified that the underlying cause is an MTU mismatch across the interconnecting trunk link, which causes jumbo frames to be dropped. According to the CompTIA troubleshooting methodology, which of the following actions should the network engineer perform NEXT?

Show answer & explanation

Answer: Develop a plan of action to adjust the trunk interface MTU settings and evaluate the change's potential impact on active fabric traffic.

Answer

Develop a plan of action to adjust the trunk interface MTU settings and evaluate the change's potential impact on active fabric traffic.
The scenario states that the engineer has already tested and confirmed the root cause (an MTU mismatch dropping jumbo frames), completing Step 3 (Test the theory to determine cause). According to the CompTIA troubleshooting methodology, the immediate next step is Step 4: Establish a plan of action to resolve the problem and identify potential effects. Developing a plan to adjust MTU while assessing risks to active fabric traffic strictly fulfills this phase.

Step-by-Step Solution

1
Identify the completed methodology phase from the scenario context.
The engineer performed packet captures and confirmed the MTU mismatch as the root cause, indicating that Step 3 (Test the theory to determine cause) is complete.
CompTIA troubleshooting requires determining the current phase before identifying the immediate next step.
2
Determine the next sequential phase in the CompTIA 7-step model.
Following Step 3 (Test theory), the technician must perform Step 4: Establish a plan of action to resolve the problem and identify potential effects.
Planning and risk assessment must precede actual implementation to avoid creating secondary network outages.
3
Select the option matching Step 4 requirements.
Developing a plan of action to adjust MTU while evaluating potential impacts on active fabric traffic directly matches Step 4.
This option explicitly fulfills both key components of Step 4: action planning and impact assessment.

Key Concept

CompTIA Troubleshooting Methodology Step Order (Testing Theory -> Plan of Action & Identifying Potential Effects)
Question 105Question →

A network administrator configures a new client subnet on VLAN 40 (10.40.0.0/2210.40.0.0/22) serviced by a central Layer 3 core switch. The central DHCP server (10.10.1.5010.10.1.50) resides on VLAN 10. Users on VLAN 40 report they cannot access internal servers or the internet. Executing `ipconfig /all` on a affected workstation returns the following output:

text
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :
Link-local IPv4 Address . . . . . : 169.254.109.88
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . :

The administrator verifies that the DHCP server scope for 10.40.0.0/2210.40.0.0/22 is active, enabled, and currently has over 500 available leases. Which of the following represents the most likely root cause of this failure?

Show answer & explanation

Answer: The Layer 3 interface for VLAN 40 lacks a DHCP relay agent (IP helper address) configuration pointing to 10.10.1.50.

Answer

The Layer 3 interface for VLAN 40 lacks a DHCP relay agent (IP helper address) configuration pointing to 10.10.1.50.
Because DHCP requests originate as Layer 2 broadcast traffic (destination MAC FF:FF:FF:FF:FF:FF), routers and Layer 3 switches will not forward these frames across subnets. Configuring a DHCP relay agent (IP helper address) on the interface serving VLAN 40 allows the switch to encapsulate the broadcast request as a unicast packet sent directly to the DHCP server at 10.10.1.50.

Step-by-Step Solution

1
Analyze the client command output symptoms.
The IPv4 address starts with 169.254.x.x with a 255.255.0.0 mask, identifying an Automatic Private IP Addressing (APIPA) lease assignment due to DHCP failure.
When a DHCP client fails to receive a DHCPOFFER response to its DHCPDISCOVER request, the operating system assigns an APIPA address.
2
Evaluate network boundary topology and DHCP broadcast behavior.
The client resides on VLAN 40 (10.40.0.0/22) while the DHCP server resides on VLAN 10 (10.10.1.50). Routers and Layer 3 switches drop Layer 2 broadcast frames by default.
DHCPDISCOVER messages are broadcast frames (255.255.255.255) and cannot cross the Layer 3 boundary between VLAN 40 and VLAN 10 without assistance.
3
Determine the missing network configuration requirement.
An IP helper address (DHCP relay) must be configured on the VLAN 40 switch virtual interface (SVI) or router gateway interface.
The relay agent intercepts client broadcast DHCP requests and forwards them as unicast packets to the central DHCP server at 10.10.1.50.

Key Concept

DHCP Relay Agent (IP Helper Address) placement across Layer 3 boundaries
Question 106Question →

A network administrator has confirmed through testing that an exhausted DHCP IP address scope was the root cause of network connectivity failures affecting wireless inventory scanners in a warehouse. According to the CompTIA troubleshooting methodology, which of the following actions should the administrator perform NEXT? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Establish a plan of action to expand the available IP address pool on the DHCP server.; Assess potential impacts and side effects on other subnets before applying the scope changes.

Answer

The administrator should establish a plan of action to expand the DHCP pool scope and evaluate the potential effects of the change prior to implementation.
After confirming the root cause during testing (Step 3), the technician must proceed to Step 4 of the CompTIA troubleshooting methodology: Establish a plan of action to resolve the problem and identify potential effects. Formulating the configuration strategy and evaluating potential adverse side effects on other network segments directly fulfill this step.

Step-by-Step Solution

1
Identify the currently completed step in the troubleshooting scenario.
The administrator has completed Step 3 (Test the theory to determine cause) by confirming that an exhausted DHCP scope caused the failure.
Determining the completed step identifies where the administrator currently resides within the methodology sequence.
2
Determine the immediate next phase defined by the CompTIA troubleshooting methodology.
Step 4 is 'Establish a plan of action to resolve the problem and identify potential effects.'
The CompTIA methodology dictates formulating a resolution plan and identifying potential impacts prior to implementing any changes.
3
Select the specific actions that belong to Step 4.
Creating a plan to adjust the DHCP pool and identifying potential effects on connected subnets.
Both actions directly align with establishing a plan of action and considering potential consequences.

Key Concept

CompTIA Troubleshooting Methodology Step 4: Establish a Plan of Action and Identify Potential Effects
Estimated Time:1m 0s
Question 107Question →

A network engineer is conducting physical layer diagnostics across diverse enterprise copper and optical fiber cabling infrastructures. Match each physical layer testing tool on the left with the specific failure symptom or diagnostic requirement on the right.

Click a left item, then click its matching right item

Items

Time-Domain Reflectometer (TDR)
Optical Power Meter (OPM) with Light Source
Category 6A Cable Certifier
Tone Generator and Inductive Probe

Matches

Show answer & explanation

Answer

Time-Domain Reflectometer (TDR) matches with calculating the precise distance to a conductor break or short on copper runs; Optical Power Meter (OPM) with Light Source matches with measuring dB signal attenuation across single-mode fiber links; Category 6A Cable Certifier matches with detecting split pairs, NEXT, and return loss compliance; Tone Generator and Inductive Probe matches with tracing unlabelled cables to their punch-down block termination.
Each physical layer troubleshooting tool serves a distinct role: TDR utilizes electrical reflectometry timing to calculate fault distances in copper cabling; an OPM paired with a light source measures light attenuation in optical fiber runs; cable certifiers evaluate complex high-frequency parameters like NEXT and split pairs per TIA standards; and tone generator probe kits trace unlabelled conductors through patch panels using inductive audio detection.

Step-by-Step Solution

1
Identify the diagnostic tool required for measuring physical distance to copper cabling faults.
TDR sends electrical pulses and calculates time-of-flight reflections to pinpoint distance to opens, shorts, or bends.
Only TDRs measure signal reflection delays to determine exact distance to copper physical layer anomalies.
2
Determine the tool used for evaluating optical fiber signal loss.
An OPM paired with a light source quantifies decibel (dB) insertion loss across optical fiber links.
Optical power meters directly measure light intensity emitted by a calibrated light source through fiber media.
3
Identify the equipment required to verify high-frequency parameters and split pairs.
Cable certifiers perform full-frequency testing to detect split pairs, NEXT, FEXT, and return loss.
Standard wiremappers only check pin-to-pin continuity and cannot detect split pairs or measure high-frequency crosstalk.
4
Select the tool dedicated to tracing individual unlabelled conductors through wiring panels.
A tone generator injects an audio frequency onto the cable, which an inductive probe detects audibly.
Toning kits are specifically designed for physical cable tracing and wire identification across high-density patch blocks.

Key Concept

Selecting appropriate copper and fiber diagnostic tools based on physical failure symptoms and signal integrity metrics.
Estimated Time:3m 0s
Question 108Question →

A network administrator is troubleshooting an industrial sensor deployment on the 2.4 GHz spectrum experiencing heavy packet loss and poor signal quality. An RF audit reveals that surrounding access points are configured on channels 2, 4, and 9 using 40 MHz channel widths. Which of the following actions should the administrator take to resolve the wireless interference issues? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Reassign access point radio frequencies to non-overlapping channels 1, 6, and 11; Reduce the channel width configuration on the 2.4 GHz radios from 40 MHz to 20 MHz

Answer

The administrator should reassign access point radio frequencies to non-overlapping channels 1, 6, and 11, and reduce the 2.4 GHz channel width configuration from 40 MHz to 20 MHz.
Reassigning 2.4 GHz radios to channels 1, 6, and 11 removes adjacent channel overlap, while lowering the channel width from 40 MHz to 20 MHz limits spectral footprint so channels do not bleed into neighboring frequencies.

Step-by-Step Solution

1
Identify non-overlapping channel configuration requirements in the 2.4 GHz frequency band
Channels 2, 4, and 9 overlap with adjacent channels, creating severe radio frequency interference. Reassigning them to channels 1, 6, and 11 eliminates adjacent-channel interference.
In 802.11 2.4 GHz deployments, only channels 1, 6, and 11 provide sufficient spectrum separation without overlapping.
2
Analyze channel width settings for 2.4 GHz wireless networks
40 MHz channel bonding occupies 8 out of 11 available 2.4 GHz channels, making non-overlapping channel planning impossible. Reducing width to 20 MHz frees up spectrum.
Standard 20 MHz channels are essential in 2.4 GHz to maintain channel isolation and prevent co-channel/adjacent-channel degradation.

Key Concept

2.4 GHz Wireless Channel Planning and Channel Bonding Constraints
Question 109Question →

A system administrator is troubleshooting outbound connectivity on a Linux server. The server shows the following IPv4 network configuration:

- IP Address: 172.16.50.22172.16.50.22
- Subnet Mask: 255.255.255.0255.255.255.0 (/2424)
- Default Gateway: 172.16.51.1172.16.51.1

The server can successfully communicate with local hosts on the 172.16.50.0/24172.16.50.0/24 network but cannot reach any external subnets or the internet. Which of the following best explains why the server cannot reach remote networks?

Show answer & explanation

Answer: The default gateway is configured on a different IP subnet than the server's IP address.

Answer

The server cannot communicate outside its local network because the default gateway (172.16.51.1172.16.51.1) is on a different subnet than the server (172.16.50.22/24172.16.50.22/24).
For a host to communicate with remote networks, its default gateway must reside within the exact same IP subnet as the host's network interface. Given an IP address of 172.16.50.22172.16.50.22 and a subnet mask of 255.255.255.0255.255.255.0 (/2424), the valid local host addresses span from 172.16.50.1172.16.50.1 through 172.16.50.254172.16.50.254. The configured default gateway address of 172.16.51.1172.16.51.1 is on a completely separate subnet (172.16.51.0/24172.16.51.0/24). As a result, the server cannot send ARP requests to discover the router's MAC address, preventing all traffic destined for external networks.

Step-by-Step Solution

1
Determine the usable host IP address range for the server's configured network interface.
With IP 172.16.50.22172.16.50.22 and Subnet Mask 255.255.255.0255.255.255.0 (/2424), the subnet network address is 172.16.50.0172.16.50.0 and usable host IP addresses range from 172.16.50.1172.16.50.1 to 172.16.50.254172.16.50.254.
A default gateway must reside on the same logical Layer 3 IP subnet as the host interface so the host can resolve the gateway's MAC address via ARP.
2
Compare the configured default gateway address with the local subnet range.
The configured default gateway (172.16.51.1172.16.51.1) belongs to the 172.16.51.0/24172.16.51.0/24 subnet, which is outside the local 172.16.50.0/24172.16.50.0/24 range.
Because the gateway is on a foreign subnet, the server cannot ARP for the gateway directly on its local broadcast domain.
3
Identify the corrective action required to restore remote connectivity.
Update the server's default gateway setting to a valid router IP address on the 172.16.50.0/24172.16.50.0/24 subnet (such as 172.16.50.1172.16.50.1).
Ensuring IP and gateway subnet alignment permits proper ARP resolution and packet forwarding to remote networks.

Key Concept

Default Gateway Subnet Alignment
Question 110Question →

A network administrator is systematically troubleshooting a client workstation that cannot resolve the internal domain name `app.company.local`. Arrange the following troubleshooting steps in the correct logical sequence, starting from local host verification to testing remote authoritative DNS resolution.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of troubleshooting steps begins with verifying local network and DNS server configuration, followed by checking local client files and clearing local DNS cache, then testing name resolution against the configured local DNS server, and finally querying the authoritative DNS server directly.
A structured DNS troubleshooting approach moves logically from local host settings to client-side caching, local recursive server testing, and finally authoritative DNS server validation. Verifying IP configuration first ensures valid DNS servers are targeted. Flushing local cache removes client-side stale records. Querying the local DNS server tests normal client operation, while querying the authoritative DNS server isolates server-side record configuration.

Step-by-Step Solution

1
Verify client network settings using `ipconfig /all`.
Confirms the workstation has proper IP configuration and valid primary/secondary DNS server IP addresses assigned.
Troubleshooting must start at the local host level to eliminate basic IP configuration or missing DNS server assignment issues.
2
Check the `HOSTS` file and clear local DNS cache with `ipconfig /flushdns`.
Eliminates misconfigurations caused by static local overrides or outdated DNS entries cached on the host.
Local OS resolution checks the `HOSTS` file and local DNS resolver cache prior to querying network DNS servers.
3
Test name resolution using `nslookup app.company.local`.
Determines whether the client's configured default DNS server can successfully resolve the target hostname.
This tests the standard recursive query path used by client applications under normal operating conditions.
4
Query the authoritative DNS server directly using `nslookup app.company.local <authoritative_ip>`.
Isolates whether the record is missing on the authoritative server or failing due to intermediate recursion/forwarding/firewall issues.
Direct targeting of the authoritative server provides definitive confirmation of record existence and DNS zone health.

Key Concept

Systematic DNS Troubleshooting Methodology
Question 111Question →

A network engineer is troubleshooting persistent connection drops and low throughput reported by wireless barcode scanners in a high-density logistics warehouse. A site survey reveals that neighboring 2.4 GHz access points (APs) are currently assigned to channels 2, 4, and 6, resulting in significant adjacent channel interference. Furthermore, large metal storage racks are generating severe multipath distortion in central aisles. Which of the following remediation steps should the engineer implement to resolve these signal and connectivity issues? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Reassign the 2.4 GHz AP channel plan to exclusively use non-overlapping channels 1, 6, and 11.; Reposition access points and deploy directional patch antennas directed down narrow aisles to mitigate multipath reflection.

Answer

The network engineer should reassign the 2.4 GHz channel plan to use non-overlapping channels (1, 6, and 11) and reposition APs using directional patch antennas to control multipath reflection.
To resolve adjacent channel interference in 2.4 GHz deployments, access points must be configured using the non-overlapping channel set (channels 1, 6, and 11). Additionally, using directional antennas in environments with high physical reflection (such as metal warehouse shelving) focuses signal propagation and minimizes multipath delay spread.

Step-by-Step Solution

1
Analyze the 2.4 GHz channel assignments (channels 2, 4, and 6).
Identified adjacent channel interference (ACI) caused by overlapping frequency sidebands.
Channels 2, 4, and 6 overlap in frequency, causing destructive interference and corrupted Wi-Fi preambles.
2
Select a proper non-overlapping channel scheme for 2.4 GHz.
Reassign access points to channels 1, 6, and 11.
In North America and international 802.11 standards, channels 1, 6, and 11 have 20 MHz spacing with zero spectral overlap.
3
Evaluate the RF reflection environment (metal storage racks causing multipath distortion).
Deploy directional antennas pointed down aisles.
Directional propagation prevents RF signals from bouncing off surrounding metallic obstacles, reducing delay spread.

Key Concept

Mitigating 2.4 GHz channel overlap and physical RF multipath interference in high-density environments.
Estimated Time:2m 0s
Question 112Question →

A network technician is troubleshooting a newly installed Category 6 (Cat6) twisted-pair cable run that fails to establish an Ethernet link. The technician suspects there may be a physical break in the copper conductor along the wall run or an incorrect wire pinout at the RJ-45 wall jack. Which TWO of the following tools should the technician use to accurately locate the physical cable fault distance and verify pin mapping?

Select all that apply

Show answer & explanation

Answer: Time-Domain Reflectometer (TDR); Wiremap tester

Answer

The technician should use a Time-Domain Reflectometer (TDR) to determine the exact distance to any physical break or short in the copper line, and a wiremap tester to confirm correct pinout layout and continuity across all conductors.
A Time-Domain Reflectometer (TDR) sends signals down a copper cable to measure reflection time, pinpointing the precise location/distance of a break or short. A wiremap tester evaluates individual conductors to verify proper pin-to-pin continuity and sequence (e.g., T568A vs T568B). Together, these tools address both fault location and wiring pinout verification.

Step-by-Step Solution

1
Select the tool appropriate for locating physical fault distance on copper media.
Identify the Time-Domain Reflectometer (TDR), which measures signal reflection timing to determine fault location.
Simple continuity testers or tone probes cannot calculate signal distance down a cable.
2
Select the tool appropriate for evaluating pin-to-pin wiring configuration.
Identify the wiremap tester, which checks pin continuity and reveals improper wiring standards or split pairs.
A wiremap tester directly tests pinout integrity at both ends of a twisted-pair connection.

Key Concept

Cabling Diagnostic Tools (TDR and Wiremap)
Estimated Time:1m 0s
Question 113Question →

A network technician has completed testing a theory and confirmed that a duplicate IP address assignment is the root cause of an executive's laptop connectivity issue. According to the CompTIA troubleshooting methodology, which of the following actions should the technician perform NEXT?

Show answer & explanation

Answer: Establish a plan of action to resolve the problem and identify potential effects.

Answer

Establish a plan of action to resolve the problem and identify potential effects.
Once a theory of probable cause has been tested and confirmed (Step 3), the technician must proceed to Step 4 of the CompTIA troubleshooting methodology, which is establishing a plan of action to resolve the problem and identifying potential effects before implementing the resolution.

Step-by-Step Solution

1
Identify the current step completed in the scenario.
The technician confirmed the root cause via testing, which completes Step 3 (Test the theory to determine the cause).
Accurate identification of the current phase determines the correct subsequent action.
2
Determine the next sequential step in the CompTIA 6-step troubleshooting methodology.
Following Step 3 is Step 4: Establish a plan of action to resolve the problem and identify potential effects.
CompTIA methodology dictates a strict chronological sequence from problem identification through documentation.

Key Concept

CompTIA Troubleshooting Methodology Order
Estimated Time:45s
Question 114Question →

A user on a Windows client workstation reports being unable to connect to an internal web application at `intranet.corp.local` after the server was migrated to a new IP address (`192.168.1.50`). A technician executes `ipconfig /displaydns` on the client workstation and receives the following output:

text
Record Name . . . . . : intranet.corp.local
Record Type . . . . . : 1
Time To Live . . . . : 86400
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 192.168.1.250

Which TWO of the following actions or events will resolve this name resolution issue on the client workstation? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Run the `ipconfig /flushdns` command on the client workstation.; Wait for the 86400-second Time To Live (TTL) period of the cached entry to expire.

Answer

The issue is resolved by running `ipconfig /flushdns` to immediately purge the stale cached record, or by allowing the entry's Time To Live (TTL) duration to naturally expire.
The client workstation is resolving the hostname to an outdated IP address because the entry is saved in the local OS DNS resolver cache. Executing the command to flush the DNS cache immediately purges all cached entries, forcing the workstation to perform a fresh DNS query against the server. Alternatively, allowing the Time To Live (TTL) timer of 86,400 seconds to naturally expire will cause the operating system to automatically remove the stale entry from memory.

Step-by-Step Solution

1
Analyze the `ipconfig /displaydns` output.
The workstation has cached an A record for `intranet.corp.local` pointing to the old IP address (`192.168.1.250`) with a TTL of 86,400 seconds (24 hours).
When a host has an entry stored in its local DNS resolver cache, it uses that cached mapping without querying the configured DNS server.
2
Identify methods to remove stale DNS resolver cache entries.
Manually clearing the cache via `ipconfig /flushdns` or waiting for the TTL timer to count down to 0 will remove the outdated entry.
Removing the stale entry forces the client operating system to send a fresh DNS query to the DNS server, returning the updated IP address (`192.168.1.50`).

Key Concept

Stale DNS Resolver Cache and TTL Management
Question 115Question →

A system administrator is troubleshooting DNS resolution issues on a Linux workstation. Standard hostname lookups for small A records succeed without issue. However, when requesting DNSSEC-signed responses from an internal DNS server, queries fail. The administrator runs the following command to diagnose the problem:

$ dig +dnssec @192.168.10.5 security-test.lab.internal
;; Truncated, retrying in TCP mode.
;; connection timed out; no servers could be reached

Which TWO of the following statements accurately identify the root cause of this failure and the appropriate corrective action?

Select all that apply

Show answer & explanation

Answer: An intermediate firewall rule is permitting UDP port 53 traffic but blocking TCP port 53 traffic.; The administrator must update security group/firewall rules to allow outbound TCP port 53 traffic to the DNS server.

Answer

The failure is caused by an intermediate firewall blocking TCP port 53 traffic, which is required when DNSSEC responses set the Truncation (TC) bit. The issue is resolved by updating firewall rules to permit TCP port 53 traffic between the host and DNS server.
DNS queries operate primarily over UDP port 53. However, when responses (such as DNSSEC keys and signatures) exceed MTU or EDNS0 payload buffer limits, the server returns a response with the Truncation (TC) bit set. The resolver then retries over TCP port 53. If an intermediate firewall permits UDP port 53 but blocks TCP port 53, the client experiences a connection timeout during the retry. Permitting TCP port 53 on network firewalls resolves this truncation fallback failure.

Step-by-Step Solution

1
Analyze the CLI output header
The message ';; Truncated, retrying in TCP mode.' indicates that the DNS response exceeded UDP buffer limits, causing the server to set the TC (Truncation) header bit.
When the TC bit is set, RFC standards require DNS clients to fail over from UDP port 53 to TCP port 53 to transmit the complete payload.
2
Evaluate the subsequent failure message
The line ';; connection timed out; no servers could be reached' shows that the workstation attempted a TCP handshake to 192.168.10.5:53 but received no response.
Successful UDP resolution combined with TCP connection timeouts strongly points to firewall rules or access control lists filtering TCP port 53 while leaving UDP port 53 open.
3
Determine the necessary remediation step
Modify network and host firewall policies to permit TCP port 53 traffic.
Allowing TCP port 53 alongside UDP port 53 enables fallback resolution for large resource records like DNSSEC and TXT records.

Key Concept

DNS Truncation (TC Bit) and TCP Port 53 Fallback
Estimated Time:2m 30s
Question 116Question →

A network administrator is investigating a name resolution issue on a server attempting to query an internal DNS zone for DNSSEC-signed records. When executing `dig @10.10.1.5 api.partner.corp +dnssec`, the command returns the following output:

text
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48219
;; flags: qr rd ra tc; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;api.partner.corp. IN A

;; Query time: 12 msec
;; SERVER: 10.10.1.5#53(10.10.1.5)

Subsequent attempts by applications to resolve `api.partner.corp` time out or fail. Which of the following is the most likely root cause of this failure?

Show answer & explanation

Answer: An intermediate network security rule is blocking TCP port 53 traffic, preventing the client from retrying the truncated query over TCP.

Answer

An intermediate network security rule is blocking TCP port 53 traffic, preventing the client from retrying the truncated query over TCP.
The `dig` output highlights the `tc` (truncated) flag in the header. When DNSSEC signatures or large resource record sets cause a DNS response to exceed the standard UDP buffer size (512 bytes), the DNS server truncates the response and sets the `tc` bit. Standard DNS clients upon seeing `tc` automatically re-query the DNS server using TCP port 53. If a firewall or security group permits UDP 53 but blocks TCP 53, the client's secondary query fails, preventing name resolution.

Step-by-Step Solution

1
Analyze the header flags in the `dig` command output.
The `flags: qr rd ra tc` line contains the `tc` (Truncated) flag, indicating the server truncated the response because it exceeded the maximum allowed UDP packet payload size (512 bytes without extended EDNS0 buffering).
Identifying DNS truncation is essential to understanding why full record payloads (such as large DNSSEC responses) cannot be transmitted over UDP.
2
Determine the standard client behavior following a DNS truncated response.
When a client receives a response with the `tc` flag set, RFC standard behavior dictates that the client must re-issue the DNS query over TCP port 53.
TCP provides stream-based transmission capable of handling larger payloads beyond the UDP MTU limit.
3
Diagnose why subsequent application resolution attempts time out.
If TCP port 53 is blocked by a network access control list (ACL) or firewall between the client and server, the TCP fallback fails, causing resolution timeouts.
Both UDP port 53 and TCP port 53 must be open across firewalls to support large DNS responses and DNSSEC.

Key Concept

DNS Truncation (TC Flag) and TCP Port 53 Fallback
Question 117Question →

A network specialist investigating a high-availability BGP routing incident has completed testing a hypothesis in a sandbox environment, confirming that an unannounced AS-path prepending modification by an upstream provider caused asymmetric routing drops. Having confirmed the root cause, the specialist is preparing for the next phase of the CompTIA troubleshooting methodology. Which TWO of the following actions should the specialist perform during this next phase? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Evaluate potential impacts on downstream network traffic and create a detailed procedure for applying the route-map adjustment.; Schedule and execute the route-map configuration change according to change management control procedures.

Answer

The specialist should evaluate potential impacts on downstream traffic while formulating the detailed modification steps, and schedule and execute the route-map configuration change within established change control procedures.
After testing a theory to confirm the root cause (Step 3), the technician must advance to Step 4 of the CompTIA troubleshooting methodology: establishing a plan of action to resolve the problem and identifying potential effects, then implementing the solution. Evaluating potential downstream traffic impacts during procedure creation and executing the route-map modification under change control procedures are the direct components of Step 4.

Step-by-Step Solution

1
Identify the completed stage in the CompTIA troubleshooting framework.
Testing the hypothesis in the sandbox environment to confirm the root cause represents Step 3 (Test the theory to determine cause).
Determining which step has just finished sets the baseline for identifying the immediate next step in the standard sequence.
2
Determine the next sequential phase of the methodology.
The next step is Step 4: Establish a plan of action to resolve the problem and identify potential effects, followed by implementing the solution or escalating as necessary.
CompTIA methodology strictly follows: 1. Identify problem → 2. Establish theory → 3. Test theory → 4. Plan of action & implement → 5. Verify system functionality → 6. Document findings.
3
Select the specific actions that belong within Step 4.
Formulating the plan while evaluating potential downstream impacts and executing the implementation through change management are the two correct actions for Step 4.
Planning for side effects and carrying out the implementation under change control directly fulfill the requirements of Step 4.

Key Concept

CompTIA Troubleshooting Methodology - Plan of Action and Implementation
Estimated Time:1m 30s
Question 118Question →

A network technician is troubleshooting a connectivity issue where a host with IP address 192.168.10.15/24 cannot communicate with servers on remote networks. Which TWO of the following issues are the most likely causes of this communication failure?

Select all that apply

Show answer & explanation

Answer: The default gateway address on the host is set to 192.168.20.1, placing it on a different subnet than the host.; An Access Control List (ACL) applied to the router's outbound interface lacks an explicit permit rule for the host's subnet and drops traffic due to the implicit deny.

Answer

The two correct causes are assigning a default gateway on a different subnet than the host (192.168.20.1 vs 192.168.10.0/24) and an Access Control List (ACL) blocking traffic via its implicit deny rule.
For a host to communicate outside its local subnet, its default gateway must be on the exact same local IP subnet so the host can resolve the gateway's MAC address. Additionally, any Access Control List (ACL) along the path must explicitly permit the traffic, otherwise the implicit deny rule at the end of the ACL will silently drop the packets.

Step-by-Step Solution

1
Analyze host IP address and default gateway configuration.
Host IP is 192.168.10.15 with a /24 subnet mask (subnet 192.168.10.0/24). Gateway 192.168.20.1 belongs to subnet 192.168.20.0/24.
A host cannot ARP for or send packets to a default gateway that is not on its local IP subnet.
2
Evaluate router security filtering (ACLs).
Unmatched traffic hitting an ACL is dropped by the final implicit deny statement.
ACLs require explicit permit statements; without one, outbound host traffic is blocked at the router interface.

Key Concept

Troubleshooting Routing, Default Gateways, and ACLs
Question 119Question →

A security operations analyst is investigating why a corporate workstation cannot reach a newly provisioned internal web application at `api.corp.local`. The analyst executes two diagnostic diagnostic commands from the client terminal:

text
C:\Users\Analyst> nslookup api.corp.local
Server: router.home.gateway
Address: 192.168.1.1

Non-authoritative answer:
Name: api.corp.local
Address: 203.0.113.45

C:\Users\Analyst> dig @10.20.4.5 api.corp.local A +short
10.20.4.200

Based on the output above, which of the following is the most likely root cause of this name resolution discrepancy?

Show answer & explanation

Answer: The client network interface is statically configured to query an improper local gateway address rather than the internal corporate DNS server.

Answer

The client network interface is statically configured to query an improper local gateway address rather than the internal corporate DNS server.
The nslookup output indicates that the workstation's default DNS server is configured as 192.168.1.1, which returns an incorrect/external IP address (203.0.113.45). When the analyst explicitly queries the corporate DNS server at 10.20.4.5 using dig, it returns the correct internal IP address (10.20.4.200). This proves the internal DNS server is working properly, but the workstation is querying the wrong DNS server due to an incorrect network adapter DNS configuration.

Step-by-Step Solution

1
Analyze the default resolver output from the standard name lookup utility
The workstation automatically sent the query for api.corp.local to 192.168.1.1 (a default gateway/SOHO router) and received a non-authoritative public IP (203.0.113.45).
By default, OS lookup utilities query the primary DNS server configured on the client's network adapter.
2
Analyze the targeted lookup command specifying an explicit server address
Directly querying the enterprise DNS server at 10.20.4.5 using dig returned the correct private IP address (10.20.4.200).
Specifying @10.20.4.5 bypasses local client resolver settings to query the designated server directly.
3
Synthesize the results to determine the configuration error
Because the enterprise DNS server holds the correct record but the client defaults to querying 192.168.1.1, the client's network settings (DHCP or static assignment) have the incorrect DNS server IP configured.
Aligning client DNS adapter configuration with internal corporate DNS servers resolves split-horizon or rogue DNS lookup behavior.

Key Concept

DNS Client Resolver Configuration & Targeted CLI Diagnostics
Estimated Time:2m 0s
Question 120Question →

A network technician is investigating a total signal loss along a long optical fiber cable run connecting two data center racks. Which diagnostic tool should the technician use to measure the exact distance to the location of the physical fiber break?

Show answer & explanation

Answer: Optical Time-Domain Reflectometer (OTDR)

Answer

Optical Time-Domain Reflectometer (OTDR)
An Optical Time-Domain Reflectometer (OTDR) sends light pulses down an optical fiber and analyzes the backscattered light. By measuring the elapsed time of reflections, it accurately calculates the precise distance to splices, bends, or physical breaks along the cable.

Step-by-Step Solution

1
Identify the diagnostic requirement
The requirement is to locate the exact physical distance to a break in a fiber optic cable run.
The scenario specifically requests measuring the distance to a fault in optical fiber.
2
Select the appropriate physical layer fiber diagnostic tool
An Optical Time-Domain Reflectometer (OTDR) measures reflected light pulses over time to calculate the distance to optical cable splices and breaks.
OTDR is the standard instrument used for distance-to-fault measurements on fiber cabling.

Key Concept

Using an OTDR to measure distance to optical fiber cabling faults
PreviousPage 6 / 25Next
Network Troubleshooting Practice Questions — CompTIA Network+ — Page 6 | Examkin