Command-line tools are valuable because they expose system state quickly, produce repeatable output, and often work when a graphical tool is unavailable. For an A+ technician, the objective is not to memorize every switch in Windows or Linux. It is to recognize which command answers the current troubleshooting question: addressing, name resolution, reachability, route path, active connections, disk integrity, system files, identity, policy, or basic filesystem state.<\/p>\n
The current CompTIA A+ Core 2 220-1202<\/a> V15 objectives include Microsoft command-line tools such as ipconfig, ping, netstat, nslookup, net use, tracert, pathping, chkdsk, diskpart, robocopy, hostname, whoami, gpupdate, gpresult, and sfc, while also expecting recognition of common Linux commands. The best way to learn them is as a troubleshooting sequence rather than an isolated vocabulary list.<\/p>\n When multiple adapters exist, identify the one actually carrying the user’s traffic. VPN clients, virtual switches, Wi-Fi, Ethernet, and container software can create several interfaces with different addresses and routes. Reading the wrong adapter’s configuration can produce a completely incorrect theory about gateway or DNS settings.<\/p>\n When a Windows system cannot reach the network, start by identifying its current IP address, subnet mask, default gateway, DNS servers, and DHCP state. Lease-management commands such as IPv4 and IPv6 can also behave differently. A hostname may resolve to both address families, and an application can fail over one family while the other works. Use address-specific tests when dual-stack behavior is relevant instead of assuming one successful ping proves both stacks are healthy.<\/p>\n Ping sends ICMP echo requests and is most useful when the target is chosen intentionally. Pinging the loopback address tests the local TCP\/IP stack. Pinging the host’s own address verifies local binding. Pinging the default gateway tests reachability across the local segment, while pinging a remote IP tests routing beyond the gateway.<\/p>\n A hostname test adds name resolution to the path. If a remote IP responds but the hostname does not, DNS becomes a stronger suspect. If both fail, investigate routing or connectivity before changing DNS settings. If the gateway itself cannot be reached, the problem is likely local to the host, VLAN, wireless association, or access network.<\/p>\n Remember that some systems block ICMP. A failed ping is evidence, not absolute proof that the destination is down. Pair the result with application tests, ARP state, route information, or other tools when policy may suppress echo responses.<\/p>\n Capture the route during both healthy and failing periods when the problem is intermittent. Changes in upstream path, VPN state, or default gateway can explain why latency and reachability vary even though the endpoint configuration appears unchanged. A saved traceroute is more useful than relying on memory of what the path \u201cusually\u201d looks like.<\/p>\n These tools become more useful when the technician already understands the default gateway<\/a> and expected network path. Without that model, a list of router addresses is difficult to turn into a diagnosis.<\/p>\n Use the DNS server shown by the command output as part of the diagnosis. Corporate devices may query an internal resolver while unmanaged devices use a public service. Comparing answers from the expected internal server and an external resolver can reveal split-horizon DNS, internal-only names, or a stale corporate zone rather than a generic internet problem.<\/p>\n Distinguish DNS failure from application caching. If nslookup returns the correct current address but a browser still reaches an old destination, the application may maintain its own cache or use a proxy. If nslookup times out, verify the DNS server address, reachability to that server, and whether UDP or TCP port 53 is permitted as required.<\/p>\n DNS also includes more than A records. Technicians should recognize that different record types serve different purposes and that IPv6 names may return AAAA records. The command’s value is that it makes the name-resolution transaction visible instead of leaving DNS as an invisible assumption.<\/p>\n If a port is expected to listen but does not appear, verify that the service is running before changing firewall rules. Firewalls can block access to a listening service, but they do not normally create the listener. This ordering prevents technicians from modifying security controls to solve a service-start problem.<\/p>\n Port numbers should be interpreted in context. A process listening on a high-numbered local port may be normal, and an outbound session to a familiar service can use an ephemeral source port. The technician’s job is to map the socket to the owning process and expected application behavior before deciding that a connection is suspicious or broken.<\/p>\n A listening port does not prove the service is reachable from another machine. Local firewall policy, network ACLs, NAT, and application binding can still block access. Conversely, an established outbound connection can confirm that the application reached a remote service even when the user interface reports a broader error.<\/p>\n Use netstat as an observation tool before terminating processes or changing firewall rules. The objective is to see the local network state and correlate it with the application, not to treat every unfamiliar connection as malicious.<\/p>\n Command output should be preserved when it contains useful evidence. Redirecting output to a text file or capturing it in the ticket can show exactly what the system reported before a repair. This is particularly useful for filesystem errors, system-file repairs, and copy failures because later state may look normal after the corrective command changes the system.<\/p>\n The same principle applies to In managed environments, command output should be correlated with directory identity, network location, and device management. A user can have the correct local setting overwritten because organizational policy intentionally controls it.<\/p>\n Basic commands such as When recovering data, copy to a different healthy destination and log the result. Repeatedly moving files around on a suspect drive can increase risk. Use the command output to identify skipped, failed, or inaccessible files rather than assuming the copy succeeded because it completed.<\/p>\n Mapped network resources can be inspected and created with Use Linux support uses many small commands that compose well. Network troubleshooting includes tools such as Use ipconfig to establish the local network facts first<\/h3>\n
ipconfig \/all<\/code> exposes these details. An address in the 169.254.0.0\/16 range is a strong clue that the host did not obtain a normal IPv4 lease and assigned itself an APIPA address.<\/p>\nipconfig \/release<\/code> and ipconfig \/renew<\/code> are useful when DHCP is expected, but they should follow basic interface checks. Renewing cannot fix a disconnected cable, disabled adapter, wrong wireless network, or blocked DHCP path. A command is a test or action inside a diagnosis, not a substitute for knowing what service should be working.<\/p>\nipconfig \/flushdns<\/code> clears the local DNS resolver cache. Use it when cached name data may be stale, not as a universal network fix. The concept of DNS caching<\/a> explains why clearing the cache can help after a record change while doing nothing for an upstream DNS failure.<\/p>\nUse ping to separate local stack, gateway, remote IP, and DNS problems<\/h3>\n
Use tracert and pathping to investigate where a path degrades<\/h3>\n
tracert<\/code> discovers the sequence of Layer 3 hops toward a destination by sending probes with increasing TTL values. It helps identify where the path changes, where routing stops, or which network segment is farther away than expected. A timeout at one intermediate hop does not automatically mean that router is failing, because devices may deprioritize or filter traceroute responses while still forwarding traffic.<\/p>\npathping<\/code> combines path discovery with packet-loss measurement over time. It takes longer but can help identify persistent loss associated with a hop or segment. Interpret results carefully: loss reported at one hop followed by clean responses downstream may indicate control-plane filtering on that hop rather than packet loss in the forwarding path.<\/p>\nUse nslookup to test DNS separately from general connectivity<\/h3>\n
nslookup<\/code> queries DNS and reports the server used and the returned record. It can test a hostname against the configured resolver or against a specified DNS server. That makes it useful for comparing local DNS behavior with an alternate source when a name resolves incorrectly or not at all.<\/p>\nUse netstat to inspect connections and listening services<\/h3>\n
netstat<\/code> displays network connections, listening ports, protocol statistics, and routing information depending on options. It helps answer whether a local service is listening, whether an application established a connection, and which remote endpoints are active. Combined with process information, it can identify which application owns a connection.<\/p>\nUse disk and system repair commands only after understanding the risk<\/h3>\n
winver<\/code> provides a quick confirmation of the Windows edition and build, which can be important when a feature or update behaves differently across releases. Pairing the build information with the exact error and recent change history often explains a problem more efficiently than immediately running repair commands.<\/p>\nchkdsk<\/code> examines filesystem structures and can repair certain logical errors. Options that fix errors or scan for bad sectors can take significant time and should not be launched casually on a failing drive with valuable data. If physical failure is suspected, prioritize backup or imaging before a long repair operation.<\/p>\nsfc \/scannow<\/code> checks protected Windows system files and repairs damaged copies when possible. It is appropriate when system components are corrupted, not when a third-party application alone is malfunctioning. diskpart<\/code> can inspect and modify disks and partitions, but destructive commands can erase data quickly, so technicians should confirm the selected disk and action before making changes.<\/p>\nformat<\/code>. Command-line access makes powerful operations fast; it does not make them safe. A support procedure should include backup status, confirmation of the target, and clear understanding of whether the command is diagnostic, corrective, or destructive.<\/p>\nUse identity and policy commands to explain user-specific behavior<\/h3>\n
gpresult<\/code> is especially useful when a policy should apply but does not. It can reveal whether the expected Group Policy Object is in the result set rather than forcing repeated updates blindly. If the policy is absent, investigate scope, security filtering, organizational-unit placement, and domain connectivity instead of treating the endpoint as if it simply missed a refresh.<\/p>\nwhoami<\/code> identifies the current security context and can provide group or privilege information with appropriate options. hostname<\/code> confirms the computer name, which is useful when remote tools, inventory, or tickets may refer to a different device than the one in front of the technician.<\/p>\ngpupdate<\/code> requests a Group Policy refresh, while gpresult<\/code> reports policy results for the computer or user. These tools help when a setting is controlled centrally and does not match local expectations. Repeatedly forcing policy updates will not fix a policy that is scoped incorrectly or blocked by network and identity problems.<\/p>\ncd<\/code>, dir<\/code>, md<\/code>, and rmdir<\/code> help navigate and manipulate directories. robocopy<\/code> is especially useful for resilient file copying because it can preserve attributes and handle large directory trees more reliably than a simple drag-and-drop operation.<\/p>\nnet use<\/code>. If a share fails, separate name resolution, IP reachability, authentication, share path, and permissions. That layered method is more productive than repeatedly remapping the same path.<\/p>\nRecognize the Linux tools A+ technicians are expected to encounter<\/h3>\n
sudo<\/code> and su<\/code> change privilege context and should be used deliberately. A command that fails as a normal user may require administrative permission, but running every command as root can hide ownership problems and increases risk. Check permissions and the intended administrative model before escalating privileges.<\/p>\nman<\/code> or built-in help before guessing syntax on a system that matters. Linux commands are powerful and often terse; options can change behavior substantially. The ability to check authoritative local help is a practical support skill and reduces the chance of applying a destructive flag remembered from another command.<\/p>\nls<\/code>, pwd<\/code>, cp<\/code>, mv<\/code>, rm<\/code>, cat<\/code>, grep<\/code>, and find<\/code> cover navigation, file operations, viewing, and searching. ps<\/code> and top<\/code> expose process state, while df<\/code> and du<\/code> show filesystem and directory space use.<\/p>\nip<\/code>, ping<\/code>, curl<\/code>, dig<\/code>, and traceroute<\/code>. Package managers such as apt<\/code> and dnf<\/code> operate on different Linux families. Permission commands such as chmod<\/code> and chown<\/code> can fix access problems but can also create security issues if used without understanding ownership and mode bits.<\/p>\n