Free Workstation security options and hardening techniques practice questions

Current guidance favors long passphrases because length is what defeats guessing and cracking tools, and a longer secret is easier for users to remember than a short one stuffed with symbols; pairing it with account lockout slows online brute-force attempts. Forcing short complex passwords with frequent resets backfires: users fall into predictable patterns such as Summer2025! followed by Autumn2025!, which cracking tools try first. Symbol requirements on their own do not make a password hard to guess, and dropping lockout leaves an attacker free to hammer the sign-in page. Reusing one password across work and personal sites turns a breach at any one site into a compromise of the work account through credential stuffing, so uniqueness is a core password consideration. Lockout thresholds should still be set sensibly, since an overly aggressive policy lets an attacker lock users out deliberately.

Pressing Win+L instantly locks the screen while keeping the session fully running, so every open application and file remains exactly where it was left. The lock hides the session behind the login prompt and requires authentication before anyone can view or touch the workstation, which is the ideal response when the same person is coming right back. Shutting down the workstation completely also secures the machine, but it destroys the working state and closes all open applications, making it a worse choice for a brief absence. Logging off the current user account ends the session and closes applications, putting unsaved work at risk and requiring a slower fresh login when the technician returns. Switching to a different user account leaves the first session running in the background but is unnecessary here since no other user needs the machine, and it still leaves the original session's files and connections consuming resources. When a scenario describes a user stepping away briefly, the best practice is always to lock the screen, not shut down, log off, or switch users.

Logging off ends the session entirely, closing applications, releasing loaded files, and ensuring the next employee begins a fresh session under their own account with their own permissions. On shared hardware where the machine is being handed over, log-off discipline fully separates one user's activity, files, and credentials from the next. Locking the screen only hides the session while leaving it running, which blocks the next user and leaves the first user's files and credentials resident on an abandoned machine. Switching users leaves the first session running in the background, consuming memory and holding open files and connections until the original user returns, which defeats the purpose of a clean handover. Enabling a shorter automatic lock timeout addresses forgetting to lock manually, but it does not end the outgoing user's session or separate the two users' activity. The rule on shared machines is that locking is for short absences by the same user, while logging off is the correct choice when handing the machine over or leaving for the day.

In a business environment, administrators enforce inactivity locks on every machine through Group Policy, the Windows mechanism for pushing settings to domain-joined computers. If a user cannot change the timeout at all, that is the policy doing exactly what it was configured to do, overriding local user control to maintain a consistent security standard. A missing firmware update would not selectively prevent modification of a lock timeout setting; firmware issues manifest as hardware or boot problems rather than locked-down policy settings. The screen saver being disabled locally would not prevent the user from changing the setting; if anything, it would leave the setting open for adjustment rather than grayed out. A missing password manager is entirely unrelated to inactivity lock timeouts, since a password manager stores credentials in an encrypted vault and has no bearing on screen lock policy. When a workstation setting appears grayed out or unchangeable on a domain-joined machine, the enforcement almost always comes from Group Policy applied by administrators.

Full disk encryption scrambles every sector of the drive, so without the recovery key or the unlock credential the thief sees only unreadable data, whether they boot the laptop or pull the drive out. A normal operating system login does not bypass the encryption; the drive is unlocked only when the TPM and boot checks pass and the correct credential is supplied. Moving the drive to another computer is exactly the attack encryption is designed to defeat, since the key is tied to the original machine and its protectors, not to the drive alone. Nothing decrypts automatically when the drive powers on; if it did, encryption would offer no protection at all. Data-at-rest encryption is a core hardening technique precisely because it makes stolen or discarded drives useless without the key.

When enabling BitLocker, saving the recovery key to a Microsoft account or a USB drive stored separately from the device ensures that access can be restored if the passphrase is forgotten or if boot issues arise. Storing recovery keys safely, and not on the device itself, is a fundamental precaution that prevents permanent lockouts. Disabling the TPM chip before encryption would remove the hardware-backed key protection that BitLocker can leverage and would not help with recovery; the TPM actually strengthens the setup rather than hindering it. Storing the passphrase in a plaintext file on the drive is a serious security failure, since anyone who accesses the drive could read the passphrase, and if the drive is encrypted the file would be inaccessible anyway when it is needed for recovery. Turning on file-level encryption for the system folder is a different protection mechanism that encrypts select files rather than the full drive, and it does not address the need for a BitLocker recovery key. Always note and securely store the recovery key before completing BitLocker encryption.

A privacy screen, also called a privacy filter, is a film placed over the display that narrows the viewing angle so the screen is readable only from directly in front. This directly counters shoulder surfing, the low-tech attack of reading someone's screen from beside or behind them, which is exactly what the stranger on the train is attempting. A cable lock is a hardened cable that anchors a laptop to a fixed object to defeat opportunistic hardware theft; it does nothing to prevent someone from reading the screen. Enabling full disk encryption protects stored data when the device is powered off or stolen, but it offers no protection against someone visually reading an active, unlocked screen. Shortening the automatic lock timeout helps secure an unattended machine after inactivity, but it does not protect the screen while the user is actively working and viewing sensitive records. Matching the threat to the correct control is key: shoulder surfing is countered specifically by a privacy screen and by positioning monitors away from casual view.

No legitimate IT department asks a user to reveal a password by email, chat, or phone, so a message requesting a password is a phishing attempt and should be reported to IT. Reporting allows the security team to warn other employees, since the same attack is likely being sent to coworkers. Replying with the password hands credentials directly to the attacker and is exactly the outcome the phishing message is designed to produce. Clicking the link to check whether the request is legitimate is dangerous because the link may lead to a fake login page designed to capture credentials or to a site that delivers malware; the strongest passphrase becomes worthless once typed into an attacker's fake login page. Deleting the email quietly protects only the individual user and leaves the attack to continue against coworkers who may not recognize it. The correct reflex for any request for credentials is to report before you click, ensuring the organization can respond to the broader threat rather than treating it as an isolated message.

A password manager stores every credential in an encrypted vault, generates long random unique passwords on demand, and fills them in automatically. This lets the user maintain a unique password for every account while only needing to remember one strong master passphrase, ideally protected with multi-factor authentication on the vault so a stolen master passphrase alone is not enough. Writing each unique password on a note kept in a drawer exposes every credential to anyone with physical access to the desk and defeats the purpose of strong secrets. Reusing one strong password across all accounts leaves the user vulnerable to credential stuffing, where attackers take a password leaked from one breached site and try it against banks, email providers, and workplaces, turning one breach into many. Rotating slight variations of the same base password creates predictable patterns that cracking tools try first, offering little real protection. When a scenario describes a user unable to keep unique passwords across many accounts, the answer is always a password manager, not writing them down, reusing one password, or using minor variations.

On a standalone workstation, password policy settings are configured through Local Security Policy, launched with secpol.msc, under Account Policies then Password Policy. This is where minimum password length, enforce password history, maximum and minimum password age, and complexity requirements are set on a single machine. The Group Policy Management Console is used to push these same settings across an entire domain of machines from a central point, but it is not the tool for a standalone, non-domain workstation. Registry Editor can technically manipulate many settings, but it is not the correct or supported location for password policy and offers no organized policy interface. Local Users and Groups (lusrmgr.msc) is used to create user accounts, manage group membership, and enable or disable accounts such as the built-in Administrator, but it does not contain the account password policy settings. Knowing the distinction between where policy is set on a standalone machine (Local Security Policy) versus across a domain (Group Policy) is a frequently tested concept.