Free Microsoft Command-line Tools practice questions

gpupdate /force reapplies every Group Policy setting immediately instead of waiting for the background refresh interval, which is what you run after changing a setting in the Local Group Policy Editor (some policies still need a sign-out or restart to take effect). gpedit.msc only opens the editor where the change is made; it does not push the policy. gpresult /r /v prints a verbose report of which policies are already applied, useful for verification but it triggers no refresh. sfc /verifyonly checks protected system files for corruption without repairing them and has nothing to do with Group Policy.

The hostname command answers one question with no extra noise: what is this computer called? Remote tools, asset tags, and management systems often track devices by computer name, so running hostname confirms in seconds that you are connected to the intended machine rather than accidentally working on a lab PC. The whoami command confirms the current user and security context, not the device name, so it answers who is signed in rather than which machine you are on. The winver command opens the Windows version dialog to show edition and build number, which is useful for confirming the OS build but does not identify the device. The gpresult command reports which Group Policy settings have applied, which is helpful for policy troubleshooting but does not confirm device identity. Because verifying the correct device is a low-risk, read-only identity check, hostname is the ideal first step before making any changes.

The whoami command confirms who Windows thinks you are by returning the current security principal, often in a DOMAIN\username format. When permissions fail, shared drives don't map, or a user claims to be logged in as themselves, whoami quickly reveals whether they are actually using a domain account, a local account, or a cached profile. The hostname command only returns the computer name, which does not help identify which user context is active. The net user command lists local user accounts and their details, but it shows account properties rather than confirming which principal is currently logged on and running the session. The winver command shows the Windows edition and build number, which is unrelated to identifying the signed-in user. Since mapped drive failures are frequently caused by a user signing into the wrong account type, whoami is the correct read-only tool to confirm the active security context.

Adding /? after a command name displays the built-in help, showing usage, switches, and examples that reflect what the installed Windows version actually supports. This makes /? more reliable than any external source because it matches your exact build, and it can reveal important cues such as whether a command requires administrative privileges or changes system settings. Copying a switch from an online forum post is risky because the switch may not exist in your version or may behave differently, leading to errors. Running the command with random switches to test them is dangerous because a single switch can require elevation, alter output, or change system state unexpectedly. Opening the Windows version dialog with winver only shows the edition and build number; it does not provide syntax help for any command. Using built-in help reduces reliance on memory and helps avoid mistakes, making /? the safest starting point.

net user <username> displays the details of one local account, including whether it is active, whether a password is required, password-age rules, and the last logon, which is exactly the evidence needed when a user says their account disappeared but it may simply be disabled or hidden from the sign-in screen. gpresult /r /scope:user reports which Group Policy objects applied to the signed-in user, not the status of another local account. whoami /groups /fo list shows the group memberships of the current session, which cannot describe an account the user cannot sign in to. sfc /verifyonly checks protected system files for corruption and is unrelated to account inspection. Because checking an account is a read-only task, net user <username> is the right first command before changing or escalating anything.

The sfc /scannow command runs the System File Checker, which scans protected Windows files and replaces incorrect versions when possible. It is the correct tool when built-in tools fail, apps crash without a clear cause, or Windows features stop working after a bad shutdown. It must be run from an elevated Command Prompt or PowerShell session, and the scan should not be interrupted once started. The chkdsk C: /r command locates bad sectors and recovers readable data at the file system level, which addresses disk structure and surface issues rather than corrupted protected system files. The gpupdate /force command refreshes Group Policy, which has nothing to do with repairing system files. The diskpart command manages partitions and disks and can be destructive, but it does not repair Windows system files. Because the symptoms point to system file corruption following a power loss, sfc /scannow is the appropriate repair tool.

When the target is C:, Windows often cannot dismount the volume while the operating system is running, so chkdsk will offer to schedule the check to run on the next restart. The technician should plan for downtime because repairs can take a while, especially on large drives. Immediately dismounting and repairing the volume is not possible while Windows is using the system drive, which is precisely why the scheduled-at-reboot option exists. Converting the volume to a read-only state is not something chkdsk does; read-only is a disk attribute managed with tools like DiskPart. Performing a full surface scan for bad sectors is the behavior of the /r switch, not /f; the /f switch focuses on fixing logical file system errors such as damaged indexes and incorrect links. Because C: is in use and cannot be locked, scheduling the check at the next reboot is the expected outcome of chkdsk C: /f.

The format E: /fs:exfat command formats the drive using exFAT, which supports large files and works well across both Windows and macOS, making it the correct choice for cross-platform removable storage holding large 4K video files. The format E: /fs:fat32 command would apply FAT32, which is highly compatible with older devices but enforces a 4 GB file-size limit that would make it impossible to store large video files. The format E: /fs:ntfs command applies NTFS, which is ideal for internal Windows drives and external drives that stay with Windows PCs, but NTFS does not provide seamless read/write support on macOS, so it is a poor fit for cross-platform use. The format E: /fs:mbr command is invalid because MBR is a partition style, not a file system, and the /fs: switch specifies a file system type. Because the drive must move between Windows and macOS with large files, exFAT is the correct selection.

After a cloning operation, a disk can appear offline due to a signature conflict, and the correct DiskPart sequence is to select the disk and then run online disk to restore access. This should always follow a verification routine of list, select, and detail to confirm the correct target, since USB devices and disk numbers can reorder across reboots. Selecting the disk and running clean would remove partition information and make the disk appear unallocated, which is destructive and would not simply bring an offline disk online. Selecting a volume and running assign letter=E addresses a missing drive letter, which is a different problem than a disk being offline. Selecting the disk and running attributes disk clear readonly removes a read-only flag that blocks writes, but a read-only attribute is not the same condition as an offline disk. Because the disk is specifically in an offline state after cloning, using online disk on the correctly selected disk is the appropriate fix.

The most likely reason is that the prompt is still on the C: drive. Changing directories with cd does not switch drives, so the technician must first type E: and press Enter, then run cd \Logs to reach the folder on the USB drive. A correct path on the wrong drive will always fail. Enclosing the folder name in quotation marks is only necessary when a folder name contains spaces, and \Logs has no spaces, so quotes would not resolve this problem. An elevated Command Prompt is only needed when permissions block access, and this error is about locating the path, not access being denied. The claim that cd cannot use absolute paths is false; cd \Logs is a valid absolute path from the root of the current drive, which is exactly why understanding the current drive matters. Whenever a valid-looking path fails, confirming the active drive letter is one of the first checks a technician should make.