Cyber Security Quiz: Windows Authentication And Controls
10 questions · exam conditions
0:00
Windows Authentication And ControlsQuestion 1 of 10

An organization enables Microsoft Defender Credential Guard on supported Windows endpoints. During a penetration test, code running with high local privileges can inspect the normal LSASS process but cannot retrieve reusable domain credential material that was previously available there.

Which security mechanism most directly explains the result?

Credential Guard isolates selected secrets with virtualization-based security instead of keeping all of them accessible to normal operating-system processes.
Credential Guard replaces all domain passwords with local certificates and prevents domain controllers from accepting password-based authentication.
Credential Guard encrypts every file accessed by LSASS and releases each file only after the user completes multifactor authentication.
Credential Guard blocks all privileged code from reading process memory by removing local administrators from the endpoint's access-control lists.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Windows Authentication And Controls

Practice Windows Authentication And Controls in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Windows Authentication And Controls, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

An organization enables Microsoft Defender Credential Guard on supported Windows endpoints. During a penetration test, code running with high local privileges can inspect the normal LSASS process but cannot retrieve reusable domain credential material that was previously available there.

Which security mechanism most directly explains the result?

  1. Credential Guard isolates selected secrets with virtualization-based security instead of keeping all of them accessible to normal operating-system processes. (correct answer)
  2. Credential Guard replaces all domain passwords with local certificates and prevents domain controllers from accepting password-based authentication.
  3. Credential Guard encrypts every file accessed by LSASS and releases each file only after the user completes multifactor authentication.
  4. Credential Guard blocks all privileged code from reading process memory by removing local administrators from the endpoint's access-control lists.
Explanation: When you see a question about Credential Guard, anchor your thinking to one core idea: virtualization-based security (VBS). Credential Guard moves sensitive credential material — specifically NTLM hashes and Kerberos tickets — into an isolated virtual environment called a trustlet, running in a separate security domain that even high-privileged OS processes cannot access directly. The normal LSASS process you can inspect is essentially a proxy; the real secrets live somewhere your privileged code simply cannot reach, regardless of how elevated your token is. That makes A correct. It accurately captures the mechanism: selected secrets are isolated using VBS, so even code with high local privileges finds nothing reusable when inspecting the standard LSASS process. B is wrong because Credential Guard does not replace domain passwords with certificates or change how domain controllers authenticate users. Domain password authentication continues to work normally — Credential Guard just protects the cached credential material on the endpoint. C is wrong because Credential Guard has nothing to do with file encryption or multifactor authentication gating. It doesn't wrap LSASS file access behind MFA; it uses hardware-backed virtualization to isolate secrets in memory. D is wrong because Credential Guard doesn't remove local administrators from access-control lists or block all privileged memory reads. Admins can still inspect LSASS process space — they just find that the sensitive credential material isn't there anymore. Your study tip: remember that Credential Guard's power comes from where it stores secrets (a VBS trustlet), not from who it blocks. Distractors on this topic typically confuse it with MFA, ACL controls, or certificate-based authentication — keep those concepts clearly separated.

Question 2

An employee enrolls in Windows Hello for Business on a managed laptop and chooses a PIN. An attacker later observes the PIN but does not obtain the laptop. The attacker attempts to use the PIN to sign in from a different computer.

Why should the observed PIN alone normally be insufficient for that sign-in?

  1. The PIN is sent only to the domain controller, which accepts it exclusively from the laptop's previously assigned IP address.
  2. The PIN unlocks a device-bound cryptographic key, so it is not a reusable domain credential on another computer. (correct answer)
  3. The PIN is a shortened copy of the domain password, but Windows rejects it when the computer has a different hostname.
  4. The PIN is valid only while the laptop is offline, because online Windows sign-ins always require the full domain password.
Explanation: When you see a question about modern passwordless authentication, focus on where the credential lives and whether it can travel between devices. That distinction is the heart of Windows Hello for Business. Windows Hello for Business works by generating a cryptographic key pair that is anchored to the specific device — typically protected by the device's TPM (Trusted Platform Module) chip. The PIN you set doesn't travel anywhere; it acts locally as a "key to unlock the key." When you enter your PIN, it releases the private key stored in that device's TPM, which then performs the authentication handshake with the domain or identity provider. Because the private key never leaves the hardware, an attacker who only knows your PIN has half the equation but none of the hardware. On any other machine, that PIN unlocks nothing — there is no corresponding private key. This is exactly what B describes, making it the correct answer. A is wrong because Windows Hello authentication is not IP-address-restricted. Domain controllers don't filter requests based on the laptop's assigned IP — that's not a real security mechanism in this context. C is wrong because the PIN is not a shortened version of the domain password at all. They are completely separate credentials. Windows Hello replaces password-based authentication rather than deriving from it. D is wrong because Windows Hello for Business works in online environments — in fact, cloud-backed deployments require connectivity. It is not limited to offline scenarios. For the exam, remember this pattern: whenever a question mentions a PIN paired with a TPM or device-bound key, the security guarantee comes from the hardware binding, not from the PIN's secrecy alone.

Question 3

An organization uses the same manually configured local Administrator password on hundreds of domain-joined workstations. After compromising one workstation, an attacker obtains that local password and successfully authenticates to administrative shares on several other workstations.

Which Windows control would most directly reduce this form of lateral movement while preserving a recoverable local administrator account?

  1. Deploy Windows LAPS so each managed computer receives a unique, regularly rotated local administrator password. (correct answer)
  2. Increase the minimum domain password length so every local administrator account inherits the stronger domain requirement.
  3. Enable UAC consent prompts so remote administrative-share connections require interactive approval on each destination.
  4. Enable Kerberos preauthentication so local accounts must obtain domain tickets before accessing administrative shares.
Explanation: When you see a question about lateral movement using stolen credentials, focus on the root cause: credential reuse. If one password works everywhere, compromising one machine compromises all of them. The fix must eliminate that reuse while keeping the account functional. A is correct because Windows Local Administrator Password Solution (LAPS) directly solves this problem. LAPS automatically generates a unique, random password for the local Administrator account on each managed machine and stores it securely in Active Directory. Even if an attacker extracts the password from one workstation, it won't work anywhere else — lateral movement via credential reuse is broken. Critically, the account still exists and is recoverable by authorized admins through AD, satisfying the "recoverable" requirement in the question. B is incorrect because domain password policies don't govern local account passwords on workstations. Local accounts are managed separately, so increasing the domain minimum length has no effect on the local Administrator password. This answer confuses domain accounts with local accounts — a common trap. C is incorrect because UAC consent prompts apply to interactive, local sessions — not to remote administrative share connections. Remote access via SMB to ADMINorC or C bypasses UAC entirely, so this control wouldn't stop the described attack. D is incorrect because Kerberos preauthentication applies to domain accounts authenticating through the KDC. Local accounts don't use Kerberos at all — they authenticate via NTLM. Requiring Kerberos tickets for local accounts isn't how Windows works. For exam questions about lateral movement, always ask: "Does this control eliminate the specific credential reuse mechanism described?" Only A does.

Question 4

Company laptops use BitLocker with TPM-only key protection. Security personnel are concerned that a stolen laptop might complete a trusted boot and release its disk key without requiring the thief to know an additional secret.

Which change most directly addresses this specific concern?

  1. Require a preboot PIN in addition to TPM validation before the BitLocker-protected operating-system volume is unlocked. (correct answer)
  2. Escrow the BitLocker recovery key in a directory so support personnel can retrieve it after verifying the user.
  3. Enable NTFS Encrypting File System for user profiles while retaining TPM-only BitLocker startup protection.
  4. Require a longer Windows account password after startup while leaving the TPM release process unchanged.
Explanation: When you see a question about full-disk encryption and theft scenarios, focus on where the vulnerability actually lives. BitLocker with TPM-only protection means the TPM automatically releases the disk encryption key during boot — no human interaction required. A thief who possesses the physical laptop gets a fully booted system without knowing any secret. The question asks what most directly closes this specific gap. Option A solves the problem precisely: adding a preboot PIN means the TPM alone is no longer sufficient. The disk key is only released when both the TPM validates platform integrity and the user supplies the correct PIN. A thief without that PIN cannot complete the unlock sequence, even with the physical hardware — directly addressing the concern. Option B, key escrow, is an administrative recovery mechanism for authorized users who forget credentials. It does nothing to stop a thief from booting; in fact, a poorly secured escrow could make things worse. Option C adds EFS encryption on top of user profile files, but BitLocker's TPM-only startup protection remains unchanged — the disk still unlocks automatically, and EFS provides only partial, file-level coverage rather than protecting the full boot process. Option D is the most misleading distractor: requiring a stronger Windows password only matters after the OS loads. Since the disk already unlocked via TPM during boot, a thief could still access the raw encrypted data through other means, or simply bypass Windows login altogether. Your takeaway: always trace the sequence of a security mechanism. Ask "at what stage does this control intervene?" — a control that fires too late in the chain cannot address an earlier vulnerability.

Question 5

A Windows server permits Remote Desktop connections only from clients that support Network Level Authentication. A vulnerability scanner reports that unauthenticated clients no longer receive a full interactive sign-in desktop, but a tester with valid stolen credentials can still establish a session.

Which interpretation of Network Level Authentication is most accurate?

  1. It allows only domain administrators to use Remote Desktop, although local users may still reach the interactive sign-in desktop.
  2. It encrypts Remote Desktop traffic only after the desktop appears, preventing credential theft but not session creation.
  3. It authenticates the user before creating a full remote session, reducing preauthentication exposure without invalidating stolen credentials. (correct answer)
  4. It verifies the connecting device's patch level before authentication, but it does not evaluate the user's credentials.
Explanation: When you see a question about Remote Desktop security controls, focus on when authentication happens and what the control actually prevents — those two dimensions separate NLA from other protections. Network Level Authentication shifts credential verification to before the full remote session is established. Normally, RDP would spin up a complete virtual desktop environment just to display the Windows login screen — meaning unauthenticated users were already consuming server resources and exposing attack surface. NLA forces the client to authenticate via CredSSP first, so the server only builds a full session for users who pass that gate. This is exactly what C describes: reduced preauthentication exposure, but no magic defense against stolen credentials. If an attacker has valid credentials, NLA has no mechanism to know they were stolen — it simply checks whether the credentials are valid, and they are. Answer A is wrong because NLA says nothing about which users (admins vs. locals) may connect — it's about when authentication happens, not who is authorized. Answer B has the timeline exactly backwards: NLA encrypts and authenticates before the desktop appears, not after. It also conflates session creation with credential theft prevention, which are separate concerns. Answer D describes something closer to Network Access Control (NAC) or endpoint compliance checking — NLA does not inspect patch levels or device health; it authenticates the user, not the machine's security posture. A useful rule of thumb: NLA = "authenticate first, render desktop second." It shrinks the attack window for unauthenticated exploits but provides zero protection once an attacker holds legitimate credentials.

Question 6

A user belongs to the local Administrators group on a Windows workstation. The user signs in normally and launches an administrative utility. The utility cannot change a protected system setting until the user approves a User Account Control prompt.

Which statement best explains this behavior?

  1. The account receives only standard-user group memberships until approval permanently restores its Administrators membership.
  2. The account normally uses a filtered access token, and approval allows the process to start with the elevated token. (correct answer)
  3. The utility authenticates to the domain again, and the domain controller temporarily grants local administrator privileges.
  4. The protected setting is encrypted by Windows, and approval supplies a key derived from the user's sign-in password.
Explanation: When you see a question about Windows UAC behavior, you should be thinking about how Windows manages privilege levels at the token level, not the account level. Windows implements UAC through a mechanism called token filtering. When a member of the local Administrators group signs in, Windows actually creates two access tokens: a full elevated token (with administrative privileges intact) and a filtered standard token (with those privileges stripped out). By default, all processes the user launches run under the filtered token — meaning even administrators operate with standard-user privileges in their day-to-day session. When an administrative utility triggers a UAC prompt and the user approves, Windows allows that specific process to launch using the elevated token instead. This is precisely what choice B describes, making it the correct answer. Choice A is wrong because group membership never changes. The user remains in the Administrators group throughout the entire session — UAC doesn't add or remove group memberships. That's a fundamental misunderstanding of how token filtering works. Choice C is wrong because UAC is entirely a local mechanism. No domain controller is consulted, no re-authentication occurs, and no temporary privilege grant is issued from the network. This describes something closer to Kerberos delegation, which is a completely different concept. Choice D is wrong because protected system settings aren't encrypted with password-derived keys. Encryption keys and UAC elevation are separate security mechanisms — UAC is about privilege, not cryptographic access control. For the exam, remember this pattern: UAC = two tokens, one session. Questions about UAC almost always hinge on understanding the filtered vs. elevated token distinction rather than authentication or encryption.

Question 7

A user accesses a Windows folder through an SMB share. The share permissions grant the user Change through one group. NTFS permissions grant Modify through another group, but a third group containing the user has an explicit NTFS Deny Write entry. No other deny entries apply.

Which outcome is most consistent with Windows permission evaluation for this network access?

  1. The user has full control because the NTFS Modify permission is broader than Share Change, causing the share permission to be disregarded during effective-access evaluation.
  2. The user can modify files because share and NTFS allow entries are combined first, and deny entries are applied only if the accumulated allows fall below the requested access level.
  3. The user has no access because Windows treats any explicit deny entry as a global denial, removing all other permissions granted through different groups.
  4. The user can read existing files but cannot create files or save changes because the explicit NTFS Deny Write overrides the write-related allow entries from other groups. (correct answer)
Explanation: When you see a question combining SMB share permissions with NTFS permissions, remember the golden rule: Windows applies both layers independently, then enforces the more restrictive result. For network access, the effective permission is the intersection of share permissions and NTFS permissions — whatever is stricter wins. Within the NTFS layer itself, explicit Deny entries take precedence over Allow entries, regardless of which group grants them. Here's how the layers resolve in this scenario. The share grants Change (read + write + delete, but not full control). NTFS allows Modify through one group — nearly equivalent. Combining those two layers, the user would normally land somewhere around Modify-level access. However, the explicit NTFS Deny Write entry kicks in within the NTFS evaluation. Because deny overrides allow at the NTFS level, write operations are stripped out. What remains is read access — the user can open and read existing files but cannot write, create, or save changes. That makes D the correct outcome. A is wrong because share permissions are never "disregarded" — they always participate in the intersection calculation. B describes a fictional evaluation model; Windows does not defer deny entries until allows fall below a threshold. Deny always wins over allow in the same permission layer. C overstates the scope of a deny entry. An explicit Deny Write does not revoke all permissions globally — it only denies write operations, leaving read access intact. As a study tip, remember the two-step mental model: first intersect share and NTFS allows, then apply NTFS denies. Explicit deny is surgical, not a blanket revocation.

Question 8

A domain-level Group Policy Object configures Windows Defender Firewall as disabled, and its domain link is marked Enforced. A non-enforced GPO linked to a child organizational unit configures the firewall as enabled. The child OU also has Block Inheritance enabled. A workstation in that child OU processes both policy locations without errors.

What firewall state should an administrator expect from these Group Policy settings?

  1. Enabled, because a GPO linked closer to the workstation always overrides a domain-level GPO.
  2. Enabled, because Block Inheritance prevents every domain-linked GPO from reaching the child OU.
  3. Disabled, because the enforced domain link crosses Block Inheritance and cannot be overridden by the child GPO. (correct answer)
  4. Unconfigured, because conflicting settings from different GPO links cancel each other during policy processing.
Explanation: When you see a question about Group Policy precedence, your mental model should include two key mechanics: Block Inheritance and Enforced links — and critically, how they interact with each other. In Windows Group Policy, Block Inheritance prevents GPOs from higher-level containers (like the domain) from flowing down to a child OU. However, this protection has one important exception: an Enforced (formerly "No Override") GPO link bypasses Block Inheritance entirely. Enforced links are specifically designed to guarantee that certain policies — like security baselines — cannot be blocked or overridden by lower-level configurations. In this scenario, the domain GPO disabling the firewall carries an Enforced link, so it punches straight through the child OU's Block Inheritance setting. Even though the child OU's local GPO enables the firewall, that setting loses the conflict because the Enforced domain policy takes precedence. The firewall ends up disabled — making C correct. Answer A is wrong because proximity to the workstation (OU-level GPO) only wins in normal precedence order; it does not override an Enforced link. Answer B contains a half-truth — Block Inheritance does block most domain-level GPOs — but it fatally ignores the Enforced exception, which is exactly the scenario being tested. Answer D invents a behavior that doesn't exist; conflicting GPO settings do not "cancel out." The last applied, highest-precedence policy wins, period. For your exam, remember this pairing: Enforced beats Block Inheritance, every time. If a question gives you both, Enforced always wins — that's the intended override of the override.

Question 9

A domain locks an account after five failed sign-in attempts within a 15-minute observation window. An attacker tests one commonly used password against each of 1,000 accounts, waits 20 minutes, and then tests a different password against the same accounts. Few accounts become locked.

Which explanation and response best fit this observation?

  1. The observation window counts only successful authentications, so failed attempts expire immediately; increasing password length activates failure counting.
  2. Lockout counts are maintained per source address, so changing passwords resets the count; blocking the attacker's current address fully addresses it.
  3. Account lockout applies only to local Windows accounts, so domain users remain unaffected; applying the same policy to domain controllers fixes it.
  4. Lockout counts are generally maintained per account, so the spray stays below the threshold; cross-account detection and MFA would better address it. (correct answer)
Explanation: When you see a question about account lockout policies, focus on how the counter works — specifically, what resets it and what it's tied to. That framing unlocks this entire question. Standard account lockout policies track failed attempts per account, not per attacker or per source IP. Here, the attacker tries one password against 1,000 accounts, then waits 20 minutes before the next round. Because the observation window is only 15 minutes, each account's failed-attempt counter resets before the second attempt arrives. Each account sees just one failed attempt per window — well below the five-attempt threshold. This is the classic password spray attack: staying under the radar by spreading attempts across many accounts rather than hammering one. Answer D correctly identifies both the mechanism (per-account counters) and the appropriate defenses — cross-account anomaly detection (flagging when one source hits many accounts) and MFA (making stolen passwords insufficient). Answer A invents a fictional rule where only successful logins are counted. No standard authentication system works this way — failed attempts are exactly what lockout policies are designed to track. Answer B misattributes the counter to the source IP address. Standard domain lockout policies don't work that way, and simply blocking one IP doesn't stop an attacker who can rotate addresses or use a botnet. Answer C is a common misconception worth dispelling: Active Directory domain lockout policies absolutely apply to domain accounts — that's their primary purpose, not an exception. For the exam, remember that password spraying exploits the per-account nature of lockout counters — the fix requires visibility across accounts, not just within them.

Question 10

A domain-joined workstation accesses an internal file server successfully by using \filesrv.corp.example\data. When the same user accesses the server by using \10.20.30.40\data, the connection succeeds but monitoring shows NTLM rather than Kerberos.

Which explanation best accounts for the change in authentication protocol?

  1. Kerberos normally requires a service principal name matching the target name, and the IP-based request may therefore fall back to NTLM. (correct answer)
  2. Kerberos is used only for interactive sign-in, while access to SMB shares must use NTLM regardless of the server name.
  3. Using an IP address causes Windows to treat the server as untrusted, so the client sends the user's plaintext domain password.
  4. NTLM is selected because DNS resolves hostnames after authentication, whereas IP addresses are evaluated before authentication begins.
Explanation: When you see authentication questions involving Windows environments, focus on how Kerberos tickets are issued — specifically, that Kerberos relies on Service Principal Names (SPNs) to identify targets. An SPN is a unique identifier registered in Active Directory that ties a service to a hostname (e.g., cifs/filesrv.corp.example). When your client requests a Kerberos ticket, the Key Distribution Center (KDC) looks up the SPN matching your target. If you connect using a hostname, Windows constructs that SPN cleanly and Kerberos works. When you connect using a raw IP address, Windows cannot reliably map that IP to an SPN, so no valid Kerberos ticket can be obtained — and the client falls back to NTLM automatically. That makes A correct. B is factually wrong — Kerberos absolutely supports network resource access including SMB shares. It is not limited to interactive logon. C invents a concept that doesn't exist: using an IP address does not cause Windows to transmit plaintext passwords. Windows still uses challenge-response mechanisms even when falling back to NTLM; plaintext credentials are never sent in standard configurations. D reverses the actual relationship between DNS and authentication in a misleading way — DNS resolution happens before the authentication handshake in both scenarios, so the timing argument in D has no basis in how the protocols actually work. As a study tip, remember the phrase "Kerberos needs a name, not a number." Any time you see IP-based access alongside an authentication protocol question, immediately think SPN lookup failure and NTLM fallback.