Free Microsoft Windows OS Security Settings practice questions

Reviewing Threat history is the correct first step because it shows the detections over time, including what Defender found, when it found it, and what action it took. This lets you confirm the name, time, and status of any detection without guessing, and it also reveals repeats such as a tool that reappears after each reboot. Disabling real-time protection is inappropriate as a first step because it immediately removes a major barrier against new downloads and malicious scripts, increasing risk without giving you any information about what already occurred. Restoring the quarantined file reintroduces the very threat that Defender isolated, and restoring should only ever happen after a careful verification routine checking the source and digital signature. Adding an exclusion tells Windows to trust a file and should be treated as a documented security exception, not a diagnostic first move. The professional habit is simple: always confirm what Defender did in Threat history before changing any settings, so your response is based on evidence rather than assumption.

Tamper Protection is the correct answer because it can block changes to Defender settings even when a local administrator attempts them. If policy allows, the proper workflow is to temporarily turn off Tamper Protection, make the real-time protection change for testing, then re-enable Tamper Protection immediately afterward. Controlled folder access is a ransomware protection feature that limits which apps can modify protected folders such as Documents or Pictures; it does not lock the real-time protection toggle. Quick scan scheduling only determines when common hiding spots are scanned and has no effect on whether settings can be changed. Security intelligence updates refer to the malware definition data that keeps Defender current against new threats; outdated definitions can miss malware but they do not gray out or lock the protection toggles. Remember that grayed-out toggles are a signal, not a glitch, and can also indicate a third-party antivirus, a managed device, missing permissions, or Group Policy/MDM enforcement. When any temporary change is made, set a short time window and document the reason, time disabled, and time re-enabled.

A new security intelligence version paired with a recent last updated timestamp is the correct proof because these fields change when definitions are refreshed, especially if the device was behind. Together they confirm the system is actually protected with current threat data rather than merely appearing healthy. The engine version and platform version change far less often, so they are unreliable as your main proof that today's definitions installed. A green checkmark on the status panel indicates overall health but can display even when definitions are stale, which is exactly the false confidence that outdated signatures create. A completed Quick scan with no threats only tells you that common hiding spots were checked at that moment; it does not verify that the definition set used for the scan was current. The practical checkpoint is a new security intelligence version plus a fresh last updated time, because a successful update is defined by those concrete values, not by a feeling or a color on the dashboard.

Keeping the network Public and leaving sharing disabled is correct because a coffee shop Wi-Fi is shared with strangers, and file and printer sharing exposes discovery and sharing services that are risky on untrusted networks. The Public profile means "I don't trust this network," and it should remain strict in that environment. Switching the profile to Domain is inappropriate because Domain applies only to networks where the PC is joined to and authenticated by an organizational domain, which is not the case on public Wi-Fi. Setting the network to Private and turning off the firewall is doubly wrong: Private marks the network as trusted enough for discovery, and disabling the firewall removes the gatekeeper for network traffic on an untrusted network. Opening the sharing ports inbound on the Public profile directly contradicts least-privilege and exposes services to everyone on the shared network. The safe judgment is to reserve Private and sharing features for trusted home or small office networks and to keep Public restrictive, restoring connectivity later through the narrowest possible rule when the user is on a network they actually trust.

Restricting the rule to the local subnet and the needed profile is correct because it limits scope so the whole internet cannot reach the service, and it applies least-privilege by tightening the rule rather than leaving it wide open. When a service truly requires inbound access, you open the port but narrow it to the necessary protocol, direction, and profile. Opening the port on all profiles to avoid future tickets creates an open door on untrusted networks like Public and directly violates least-privilege. Disabling the firewall while the application is in use removes the gatekeeper for all traffic, exposing every service on the machine, not just the one that needs access. Allowing both TCP and UDP for the entire port range broadens exposure far beyond what the application needs and makes the rule harder to audit. Good firewall judgment also includes documenting the port number, protocol, direction, profile, and justification, because port rules outlive the original ticket. Whenever possible, prefer a VPN so the device sits inside the trusted network and avoids exposing inbound ports to untrusted networks entirely, and close any port that was opened only for testing.

User rights combined with User Account Control is correct because installing a driver is a system-level action, not access to a specific file or folder. When a standard user attempts an admin-only task, User Account Control steps in and requests admin approval, creating a speed bump between routine work and high-impact changes. The fact that the user can open documents but cannot install the driver points to a rights/elevation boundary rather than a resource-access problem. NTFS permissions on the shared folder control access to files and folders, and since the user can already open documents there, permissions are clearly not the blocker. Controlled folder access is a Defender ransomware feature that limits which apps can modify protected folders such as Documents or Pictures; it would not produce a credential prompt for a driver install. A metered connection can slow or block large downloads but would not generate a UAC credential request for local driver installation. The quick diagnostic rule is: if the problem is about a specific folder or file, think permissions; if it is about a system action, think user rights and elevation through UAC.

Local accounts are the best fit because their credentials live in the PC's local security database and do not depend on an internet connection or a cloud identity provider. This keeps the lab functional when external services are blocked and fits environments where devices re-image frequently and profiles reset often. Microsoft accounts tie identity to Microsoft's online services and require connectivity for many features and recovery, which conflicts with a blocked-cloud, frequently-reimaged lab. A single shared Microsoft account destroys accountability because you cannot easily prove who did what, and it still depends on cloud services. Guest accounts are high risk and weaken accountability, and modern Windows setups typically keep Guest disabled; if occasional shared access is truly needed, a named temporary standard account is safer. The guiding question is whether identity and recovery should live mostly on the PC or follow the user through the cloud. For kiosks, training labs, and offline systems, local accounts provide the control and predictability those environments require, and named local accounts preserve accountability even on standalone machines.

Disabling the account and removing it from sensitive groups is correct because disabling immediately cuts the user's ability to sign in while preserving the account for audit history and any needed investigation. Removing it from sensitive groups also ensures any residual access granted through group membership is revoked. Deleting the account and its profile immediately destroys audit history and can remove data that the organization may still need, making it a poor first choice during an offboarding. Changing the account to a Guest account is inappropriate because Guest is a legacy, high-risk option that weakens accountability and does not represent a controlled offboarding action. Resetting the password and leaving the account active keeps a valid, sign-in-capable identity on the system, which does not cut access and leaves an unnecessary attack surface. The professional pattern for a departing user is to disable rather than delete, remove access-granting group memberships, and retain the record so that changes remain explainable during audits or incident response.

Adding the user to the Remote Desktop Users group is correct because it allows sign-in through Remote Desktop when RDP is enabled without granting administrative rights. This satisfies the requirement of remote access while keeping the user from changing system security settings, and it aligns with least-privilege. Adding the user to the Administrators group would grant broad control, including the ability to change security settings, which directly contradicts the requirement and greatly increases risk. Adding the user to the Power Users group relies on a legacy compatibility group that is not the appropriate mechanism for enabling RDP and should not be assigned unless policy specifically requires it. Adding the user to the Backup Operators group grants backup and restore capabilities rather than remote sign-in, so it does not meet the RDP requirement. Because RDP increases attack exposure if mismanaged, membership in Remote Desktop Users should still be reviewed carefully, but it remains the targeted, minimal group that provides remote sign-in without elevating the user to administrator.

When a user accesses a folder over the network, Windows combines share permissions and NTFS permissions, and the effective access is the most restrictive result of the two layers. Since the share is set to Read and NTFS grants Modify, the network user is limited to Read because the share layer blocks writes and deletes. Locally, only NTFS applies, so the user keeps Modify access. The idea that NTFS permissions are corrupt is incorrect because the local Modify access works perfectly, proving NTFS is intact. The Read-only attribute is incorrect because attributes are labels, not security controls, and they do not explain why local access works while network access fails. An explicit Deny entry is incorrect because a Deny would block access from both local and network paths, yet the user can fully edit files locally. The distinguishing detail is the path used: local access checks only NTFS, while network access checks the share door first, then the NTFS door. Because share permissions can only reduce access and never expand it, setting the share to Read caps everyone at Read regardless of the underlying NTFS Modify rights.