Windows Access Controls practice questions

User Account Control: Detect application installations and prompt for elevation

Why it fails: This specific policy controls heuristics for identifying installation files but does not force general administrative applications to require explicit user approval for elevation across all operational scenarios. It focuses strictly on heuristic detection rather than universal elevation enforcement.

User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode

Why it fails: This setting merely dictates how the prompt is presented to users already running in Admin Approval Mode, such as prompting for credentials or consent, rather than enabling the enforcement mechanism itself. It assumes the approval mode is already active.

User Account Control: Only elevate executables that are signed and validated

Why it fails: This policy restricts elevation strictly to digitally signed binaries, which alters signature validation requirements rather than mandating universal administrator approval for all unsigned or general executable tasks needing elevated privileges.

The user is granted Read access.

Why it fails: Access is denied because the user is not in the Administrators group. Since the Share permissions only explicitly include Administrators, any domain user not in that group lacks the necessary 'Read' right at the share level, regardless of the broader NTFS permissions assigned to Everyone.

The user is granted Full Control access.

Why it fails: Full Control is only available to the Administrators group. Domain users who are not part of this group cannot inherit higher permissions than those assigned at the share level. The effective permission is the most restrictive of the two layers, preventing any elevated access for standard users.

The user is granted Write access.

Why it fails: The user cannot be granted Write access because the NTFS permission is limited to Read. Furthermore, the Share permission does not include the user at all. This scenario fails both the NTFS Read/Write requirement and the fundamental Share permission requirement for any access to the resource.

Explicit permissions are listed as 'Inherited' in the GUI.

Why it fails: Explicit permissions are those directly applied to the specific object and are never labeled as inherited. Inherited permissions are explicitly marked as such in the advanced security settings dialog, allowing administrators to distinguish between local rules and those imposed by parent folder settings during security audits.

Inherited permissions automatically disappear after 30 days.

Why it fails: Windows permissions do not expire automatically. Once set, they remain in effect until a system administrator explicitly modifies them. Relying on an assumption of automated removal creates significant security risks, as access could persist indefinitely for users who should no longer have rights to the data.

Inherited permissions cannot be viewed in the GUI.

Why it fails: Inherited permissions are fully visible in the Advanced Security Settings tab of the file properties. They are clearly identified by the 'Inherited from' column, which specifies the parent container from which the permission entry originates, assisting in the troubleshooting of complex directory-level access control policies.

The user is a member of the 'Everyone' group.

Why it fails: The 'Everyone' group usually has limited permissions. Even if included, it rarely grants Full Control by default. Assuming 'Everyone' implies absolute control is a common misconception that leads to insecure configuration practices and vulnerabilities within the Windows permission hierarchy for shared file server environments.

The user has bypassed Group Policy.

Why it fails: Group Policy cannot be used by standard users to grant themselves permissions on specific files. Bypassing GPO requires elevated privileges or a direct compromise of the domain controller. Local file ownership is a distinct mechanism that functions independently of the domain-wide Group Policy Object enforcement structure.

The file is encrypted with EFS.

Why it fails: Encrypting File System (EFS) protects the content of the file from unauthorized reading but does not grant the user permission to modify the ACL. Ownership and encryption are separate security domains; EFS does not grant administrative rights or the ability to alter access control list entries.

Deny permissions can be overridden by explicit Allow entries.

Why it fails: Deny permissions are authoritative and cannot be overridden by any Allow entry. If a user is denied, they are denied, regardless of how many groups they belong to that have 'Allow' access. This priority logic is why administrators should favor removing users from groups rather than applying Deny.

Deny entries are best practice for general access management.

Why it fails: General access management should rely on Allow entries for authorized groups. Using Deny entries indiscriminately causes complex troubleshooting scenarios, as an accidental Deny can lock out administrators or users. It is far better to manage access by carefully curating group memberships instead of using negative permissions.

Deny permissions only apply to local users.

Why it fails: Deny permissions apply to any identity, whether local or domain-based, if that identity is present in the ACL. Windows does not distinguish between local and domain SIDs when evaluating Deny entries; the security monitor treats all identities equally when calculating the effective access for the requestor.

The NTFS permissions for Project_Staff include a Deny Delete subfolder permission that takes precedence over her Modify permission from Project_Managers.

Why it fails: Explicit Deny permissions do override Allow permissions, but the scenario states that Project_Staff has Read & Execute, not a Deny. There is no mention of a Deny permission. Assuming a Deny where none is specified is incorrect; the problem must be diagnosed from the given permissions. Moreover, Read & Execute does not include Delete, but that alone would not cause an Access Denied if she also has Modify from another group.

The Share permissions are limiting her to Change, which does not include delete.

Why it fails: Share-level Change permission includes the ability to delete files and subfolders. Therefore, the Share permission is not restricting Maria from deleting the file. The effective permissions are the intersection of Share and NTFS permissions, and since Share allows Change, the issue must originate from NTFS permissions or another factor, not the Share permission itself.

The file is marked with the Read-only attribute, which prevents deletion even with Modify NTFS permissions.

Why it fails: The Read-only attribute on a file does not prevent deletion when the user has the Delete permission (or Delete Subfolders and Files on the parent folder). Windows allows deletion of read-only files if the user has sufficient NTFS permissions; the attribute only prevents modification of content. Thus, this is not the cause of the Access Denied error.

Bob will be unable to save the file because the Everyone group does not have Modify share permissions.

Why it fails: The reason Bob cannot save is not that Everyone lacks Modify, but that the share permission is explicitly Read, which is insufficient for writing. The statement correctly identifies the outcome but misattributes the cause: the share permission is Read, not merely the absence of Modify. The effective denial is due to the restrictive share permission.

Bob will be able to save the file because he is a member of SalesGroup, which has Modify NTFS permissions.

Why it fails: Group membership grants NTFS Modify, but share permissions are evaluated independently. The share permission for Everyone is Read, which blocks write operations. The effective permission is the intersection of share and NTFS permissions, so Bob's group membership does not bypass the share-level restriction. This illustrates why share permissions must be configured to allow write if needed.

Bob will be able to save the file because NTFS permissions take precedence over share permissions.

Why it fails: NTFS and share permissions are both enforced; the most restrictive effective permission applies. Here, the share permission for Everyone is Read, which does not include Write. Therefore, Bob cannot save the file, even though NTFS grants Modify. NTFS does not override share permissions; they are cumulative in a restrictive manner.

The account can restore files and directories, and it can also take ownership of files and other objects if the 'Restore files and directories' right is assigned.

Why it fails: The 'Back up files and directories' right alone does not grant the ability to restore files or take ownership. Restoring requires the 'Restore files and directories' user right, which is separate. Taking ownership requires the 'Take ownership of files or other objects' right. Therefore, this statement is incorrect because it conflates multiple user rights.

The account can read any file on the system, regardless of NTFS permissions, by using the Backup Operators group membership.

Why it fails: The 'Back up files and directories' user right allows bypassing NTFS permissions for backup purposes, but it does not grant the ability to read files arbitrarily without using backup semantics. The account must use a backup application that enables the backup privilege (SeBackupPrivilege) to read files. Simply being a member of Backup Operators does not automatically allow reading files without that privilege being enabled in the process token.

The account can modify the permissions of any file it backs up, because the backup right includes the WRITE_DAC permission.

Why it fails: The 'Back up files and directories' right does not include the ability to modify permissions (WRITE_DAC). It only allows reading files for backup by bypassing NTFS permissions. Modifying permissions requires the WRITE_DAC permission, which is not granted by this user right. Therefore, this statement is false.

The Deny permission only applies if Carol accesses the subfolder over the network, not locally.

Why it fails: NTFS Deny permissions apply both locally and over the network. Share permissions only apply over the network, but the scenario is about NTFS permissions on a subfolder. The Deny is an NTFS ACE, so it is enforced regardless of access method. Carol will be denied write access locally as well as remotely.

Carol will still have write access because her user account has Full Control, which is an explicit Allow that overrides group Deny.

Why it fails: A user account's explicit Allow does not override a group's explicit Deny. Deny always takes precedence over Allow, regardless of whether the Allow is explicit or inherited. Carol's Full Control on the parent folder is inherited to the subfolder, but the group Deny on the subfolder blocks write access. The Deny wins.

Carol's Full Control permission will be removed from the subfolder because inheritance is enabled and the Deny permission breaks inheritance.

Why it fails: A Deny ACE does not break inheritance or remove inherited permissions. It simply overrides the specific permission it denies. Carol's Full Control remains inherited on the subfolder, but the Write portion is effectively denied. The Deny does not alter the ACL structure or remove inherited ACEs; it only affects the effective access for that permission.

Alice can write the file because Deny ACEs on groups are ignored when the user has an explicit Allow.

Why it fails: Windows does not ignore group Deny ACEs when the user has an explicit Allow. In fact, explicit Deny ACEs, whether applied to a user or a group the user belongs to, are evaluated first and take precedence over any Allow ACEs. The presence of an explicit Allow on the user does not nullify a Deny inherited through group membership; the Deny will still block the requested access.

Alice cannot write the file because NTFS permissions are cumulative and the most restrictive permission wins, which is Deny Write from the group.

Why it fails: NTFS permissions are not simply cumulative with the most restrictive winning. Instead, Windows uses a specific evaluation order: explicit Deny ACEs are checked first, then explicit Allow ACEs, and finally inherited ACEs. The Deny does take precedence, but not because of a 'most restrictive wins' rule; it is due to the explicit Deny being evaluated before the Allow.

Alice can write the file because her explicit Allow Modify ACE takes precedence over the group Deny.

Why it fails: Windows access control evaluation always processes explicit Deny ACEs before Allow ACEs, regardless of whether the Deny is assigned to a user or a group. An explicit Allow on the user does not override a Deny that also applies to that user through group membership. The system checks all ACEs that match the user's token and if any explicit Deny is found, access is denied immediately.

User Account Control (UAC)

Why it fails: UAC primarily manages administrative elevation prompts and integrity levels for applications. It does not control low-level file system access permissions for standard users, nor does it impact the intersection between NTFS and Share permissions during remote or local folder access requests for standard data files.

BitLocker Drive Encryption

Why it fails: BitLocker provides full-volume encryption to protect data at rest against physical theft. It operates at the storage layer and does not perform access control checks based on user identity once the volume is unlocked and the operating system has successfully mounted the file system.

Group Policy Object (GPO) Inheritance

Why it fails: GPO inheritance dictates configuration settings and registry keys pushed from a domain controller. While GPOs can restrict software execution or modify user rights, they do not directly evaluate or override individual folder-level access control entries during standard file system navigation operations.

Only existing files are modified.

Why it fails: These flags apply to both existing and future objects created within the container. If it only applied to existing objects, administrators would need to manually re-run the command every time a new file was added, creating significant management overhead and increasing the risk of security misconfiguration.

The permissions are applied to C:\Data only, not children.

Why it fails: The flags specifically instruct Windows to propagate the Access Control Entry to child objects. If the flags were omitted, the permissions would be applied only to the C:\Data folder itself, leaving the contents vulnerable or inaccessible depending on the existing inherited or explicit permission settings.

The user cannot delete the folder.

Why it fails: The (M) flag stands for Modify, which includes the ability to read, write, and delete files. These flags do not restrict deletion; rather, they define the scope of inheritance. The deletion capability is a function of the modify permission itself, not the inheritance flags applied to the ACL.

Access-Based Enumeration (ABE)

Why it fails: ABE hides files and folders that users do not have permission to access. It is a user experience and security feature that prevents users from seeing resources they cannot open, but it does not evaluate or enforce fine-grained attribute-based access control policies on the files themselves.

NTFS Permissions

Why it fails: Standard NTFS permissions are based solely on security identifiers (SIDs) and static groups. They lack the ability to inspect attributes or claims to make dynamic authorization decisions, making them insufficient for scenarios that require context-aware access control based on changing user or document metadata properties.

User Account Control (UAC)

Why it fails: UAC is a privilege management feature designed to prevent unauthorized administrative changes to the system configuration. It does not provide mechanisms for data-level access control based on attributes, department membership, or project codes, as its primary scope is local process isolation and system integrity protection.

The 'Deny' permission only applies if Elena is directly listed, not via group membership.

Why it fails: Windows evaluates group memberships for both Allow and Deny permissions. An explicit Deny applied to a group affects all members of that group. Therefore, Elena's membership in 'Contractors' triggers the Deny. The statement is false; group-based Deny is effective and common in access control.

The 'Write' permission is not included in the 'Modify' permission, so the Deny for Write does not affect Modify.

Why it fails: The 'Modify' permission includes Write (and Read & Execute, among others). Therefore, a Deny on Write directly conflicts with the Write component of Modify. The Deny will block the Write capability, effectively preventing modification. This option misstates the composition of the Modify permission.

The 'Modify' permission from 'Project_X' is inherited and therefore is overridden by the explicit 'Deny'.

Why it fails: While it is true that the Deny overrides, this option incorrectly states that the Modify permission is inherited. The scenario does not specify inheritance; it says Elena has Modify via group membership. Even if inherited, inheritance alone does not cause it to be overridden; it's the Deny precedence that matters. The key issue is Deny > Allow.

The 'Full Control' permission from 'Managers' does not include the 'Delete' permission.

Why it fails: Full Control includes all permissions, including Delete. Therefore, this statement is incorrect. If Bob truly had Full Control without any Deny, he would be able to delete files. The issue must be due to a conflicting Deny or another restriction. This option misrepresents the scope of Full Control.

Bob's user account has an explicit 'Deny' for 'Delete' that is inherited from the parent folder.

Why it fails: While an explicit Deny for Bob would indeed block deletion, the scenario does not indicate that Bob's account has such a Deny. It only mentions group memberships. The most likely cause is a Deny on one of the groups, not on Bob directly. This option introduces an unsupported assumption.

The 'Read & Execute' permission from 'Sales' is more restrictive and overrides the 'Full Control' from 'Managers'.

Why it fails: Windows permissions are additive: a user receives the union of all Allow permissions from all groups, unless a Deny is present. Read & Execute does not override Full Control; instead, the user would have Full Control if no Deny exists. This option incorrectly suggests that a less permissive Allow can override a more permissive Allow.

The file's Share permissions are more restrictive than its NTFS permissions, preventing access.

Why it fails: The question focuses on NTFS permissions (icacls shows NTFS ACLs). Share permissions are separate and would not be visible via icacls. While share permissions can restrict access, the explicit Deny on the NTFS ACL is sufficient to block access. The scenario does not indicate share-level restrictions.

Alice's group membership has not been refreshed in her current logon token, so the Modify permission is not applied.

Why it fails: While group membership changes require a new logon to update the token, the scenario states Alice is a member of the group and the analyst sees the group has Modify permission. The explicit Deny on her account is a more direct and definitive cause. Token refresh issues would affect all group-based access, not specifically a file with an explicit Deny.

The 'Modify' permission assigned to Alice's group is inherited from a parent folder and is therefore ignored.

Why it fails: Inherited permissions are not ignored; they are effective unless blocked or overridden by an explicit Deny. In this scenario, the group's Modify permission could be inherited or explicit, but the presence of an explicit Deny on Alice's account is what blocks access. Inheritance alone does not cause permissions to be disregarded.

Write

Why it fails: The Write permission allows creating and modifying files but does not include Read & execute. Users would be unable to read files they need to work with. The scenario requires read and write access, so Write alone is insufficient. It also lacks Delete, which may be needed for normal file management.

Read & execute

Why it fails: Read & execute allows viewing and running files but not modifying them. SalesTeam members need to write files, so this permission is too restrictive. It would prevent them from saving changes or creating new files. The administrator needs a permission that includes both read and write capabilities.

Full Control

Why it fails: Full Control grants all permissions, including Change permissions and Take ownership. This would allow SalesTeam members to modify ACLs and take ownership, which exceeds the requirement. The administrator explicitly wants to prevent those actions, so Full Control is too permissive and would violate the principle of least privilege.

The contractor user has the 'Modify' permission, but a Deny entry for 'Write' is present.

Why it fails: If Modify were assigned, the user would have Write unless a Deny for Write existed. However, the scenario does not mention any Deny entries, and the listed advanced permissions are all read-related. The absence of Write-related permissions in the DACL entry is sufficient to prevent writing. A Deny would be an additional layer, but it is not indicated here.

The contractor user is a member of the 'Users' group, which has the Read & execute permission by default.

Why it fails: While the Users group often has Read & execute on many system folders, the scenario describes a specific DACL entry for the Contractors group with advanced permissions. The behavior is directly explained by that entry, not by default group membership. The question asks for the concept that best explains the behavior, which is the specific permission set assigned to the group.

The contractor user has been assigned the Write basic permission, but inheritance is blocked on the folder.

Why it fails: The Write permission would allow creating files and modifying data. The contractor cannot do these things, so Write is not assigned. Blocking inheritance would not remove Write permissions if they were explicitly assigned; it would only prevent inheritance from parent folders. The observed behavior is consistent with Read & execute, not Write.

Group Policy Object (GPO)

Why it fails: A Group Policy Object is used to define and enforce configuration settings for users and computers in an Active Directory environment. While GPOs can affect security settings, they do not generate the data structure used for access checks at logon. The access token is generated by the Local Security Authority (LSA) based on the user's credentials and group memberships.

Security Descriptor

Why it fails: A Security Descriptor is associated with an object (like a file or registry key) and contains the owner SID, group SID, and discretionary and system access control lists. It defines who can access the object, but it is not the data structure generated at logon for the user. The user's access is evaluated against the Security Descriptor using the access token.

Security Identifier (SID)

Why it fails: A Security Identifier (SID) is a unique value that identifies a security principal (user, group, or computer). While SIDs are included in the access token, the SID itself is not the data structure that holds the user's group memberships and privileges for access checks. The SID is an identifier, not the container for the user's security context.

Members of Temp_Contractors will be denied access to the entire C: drive because Deny permissions propagate upward.

Why it fails: Deny permissions do not propagate upward to parent folders. They apply only to the object where they are set and can be inherited by child objects if inheritance is enabled. Since the Deny is set on C:\Audit, it does not affect the parent C:\ or other folders. Therefore, access to the rest of the C: drive remains unchanged.

The Deny permission will be ignored because inherited Allow permissions take precedence over explicit Deny permissions.

Why it fails: In Windows access control, explicit Deny permissions take precedence over inherited Allow permissions. When evaluating access, the system checks for any Deny entries that match the user's SIDs; if found, access is denied regardless of Allow entries. Therefore, the explicit Deny on C:\Audit will override the inherited Allow from C:\.

Members of Temp_Contractors will still have access to C:\Audit because they are also members of the Users group, which has inherited Allow permissions.

Why it fails: Even if a user is a member of a group with Allow permissions, an explicit Deny for any group the user belongs to will override those Allows. The presence of the Users group with Allow does not negate the Deny for Temp_Contractors. The access check will find the Deny and reject access, so they will not have access.