BitLocker on the OS drive uses the TPM to securely store the encryption keys and to verify boot integrity. The TPM provides hardware-backed protection so the encryption key remains with the hardware, making it much harder for an attacker to access the data if the drive is moved to another system or tampered with during boot. Because of this, the BIOS/UEFI must have the TPM enabled and activated (and initialized) so Windows can take ownership of the TPM and use it to protect the BitLocker key. That’s why turning on and activating TPM security is the required step. Enabling Secure Boot helps with boot integrity and overall security, but BitLocker can work without it, so it’s not strictly required to enable BitLocker. Disabling the TPM would prevent TPM-backed protection, potentially forcing BitLocker into a less secure software-only mode. Setting the BIOS to Legacy Boot bypasses UEFI features that BitLocker often relies on, and is not necessary for enabling BitLocker on the OS drive.

NTFS permissions revolve around two control lists attached to every file or folder. The DACL, or Discretionary Access Control List, defines who is allowed or denied access and what they can do with the object. Each entry specifies a user or group and the rights granted or denied (such as read, write, modify, or full control). The system evaluates a user’s identity and group memberships against this list, applying deny entries first and then allow entries, with the owner or an administrator able to modify the DACL at will. That flexibility is why it’s called discretionary. The SACL, or System Access Control List, handles auditing. It lists which access attempts should be recorded in the security audit log and whether successes, failures, or both should be logged. Importantly, the SACL does not change whether access is granted or denied; it only determines what events are remembered for monitoring and forensic purposes. So the key difference is that the DACL controls access decisions—who can do what with the object—while the SACL controls auditing of those access attempts. The other statements mix up these roles or introduce unrelated concepts like encryption or static behavior, which do not describe what DACLs or SACLs do.

Restricting where a user can log on is controlled by a per-user setting that specifies which machines they may log on from. This is configured on the Account tab of the user’s properties, using the Log On To option to list the computers the user is allowed to log on to. This directly enforces login restrictions to designated devices. By comparison, Logon Hours controls when logon is allowed, not where; the Security tab focuses on permissions and access rights, not the computers a user can log on from; and a separate Login Restrictions path on the User tab isn’t the mechanism used here. So to limit a user’s logon to specific computers, use the Log On To setting on the Account tab.

This tests how strict the allowlist (safe senders list) policy is in email filtering. The safe senders list is an allowlist of trusted addresses. The Exclusive setting enforces a deny-all-else approach, meaning only emails from addresses on that safe senders list are allowed and anything not on the list is blocked. The other levels are less strict, letting non-listed senders through under some conditions, so they don’t guarantee that only safe-sender messages pass. So the setting that achieves an only-allowlisted pass is Exclusive.