Access Controls Concepts practice questions

1 failed attempt

Why it fails: Too strict; likely to lock out legitimate users.

No lockout, only logging

Why it fails: Logging alone does not prevent brute-force attacks.

20 failed attempts

Why it fails: Too high; allows many brute-force guesses.

Separation of duties

Why it fails: Separation of duties requires multiple people for tasks.

Need-to-know

Why it fails: Need-to-know is about data access.

Least privilege

Why it fails: Least privilege is about permissions, not visitor control.

Separation of duties

Why it fails: Separation of duties divides tasks among individuals, not access methods.

Need-to-know

Why it fails: Need-to-know restricts data access, not physical entry methods.

Least privilege

Why it fails: Least privilege limits permissions, not the number of authentication factors.

LDAP

Why it fails: LDAP is the access protocol clients use to query and modify directory data, not the store itself; it defines how requests travel to the directory. LDAP would be the correct answer if the question asked how applications authenticate against or search Active Directory.

Group Policy Object (GPO)

Why it fails: A Group Policy Object is a container of configuration settings applied to users and computers; it holds no directory objects and no hierarchy. GPOs would be the correct answer if the question asked how password length, desktop restrictions or software deployment are enforced across a domain.

Domain controller

Why it fails: A domain controller is the server hosting the directory database and processing authentication, not the hierarchical data store the question describes. Domain controllers would be the correct answer if the question asked which server validates logons or replicates directory changes between sites.

Biometric reader on a server room door

Why it fails: A biometric reader authenticates identity through a physical characteristic, making it a physical control guarding a door, not a logical one restricting data or system access. It is tempting because biometrics also feature in logical authentication, such as fingerprint logins to an operating system.

Fencing around a building

Why it fails: Fencing is a physical deterrent controlling access to a site's perimeter, not a logical control governing access to systems or data. It tempts candidates because perimeter security is a recognised control category, and fencing would be correct when the question asks for a physical access control.

Security guards

Why it fails: Security guards are personnel exercising physical control over premises, not logical controls over systems or information. They tempt candidates because guards are a legitimate control type, and would be the correct answer if the question asked for a physical or administrative safeguard rather than a logical one.

Requiring visitors to provide a biometric scan

Why it fails: Biometric scanning is disproportionate for visitors and creates unnecessary personal data processing; visitor policies require identification, sign-in and escorting. Biometrics is tempting because it strongly authenticates identity, and would be correct for high-security areas where identity assurance outweighs privacy and throughput costs.

Performing background checks on all visitors

Why it fails: Background checks on every visitor are impractical and legally fraught for routine guests; visitor management instead verifies identity and records entry. Checks are tempting because vetting reduces insider risk, and would be correct for contractors or long-term on-site personnel rather than short-stay visitors.

Issuing temporary visitor badges

Why it fails: Badges are common but not always essential; sign-in and escort are more fundamental.

Security guards

Why it fails: Security guards are a physical access control, enforcing access to premises rather than to data or systems; logical controls include permissions, ACLs and authentication mechanisms. Guards are tempting because they verify identity and authorisation, and they would be correct where the question asked about controlling entry to a building or data centre.

Perimeter fencing

Why it fails: Perimeter fencing is a physical control, restricting bodily access to a site rather than governing how subjects interact with data or systems. It is tempting because fencing genuinely deters intrusion and defines a secure boundary, and would be the right answer if the question asked for a physical or deterrent control instead.

Biometric reader on server room door

Why it fails: A biometric reader authenticates identity through a physical characteristic and controls entry to a room, making it a physical control, not a logical one governing data or system access. It is tempting because biometrics also appear in logical authentication, and would be correct if the question concerned physical access to a facility.

Defense in depth

Why it fails: Defense in depth layers multiple controls; it is not the principle governing permission scope. Least privilege is violated because read access to sales figures exceeds the customer-contact data the role needs. Defense in depth is tempting as a general security concept, and would be correct when assessing overlapping safeguards.

Least privilege

Why it fails: Least privilege is the principle being violated, not a wrong answer, so it cannot be the option that fails the scenario. It is tempting because it sounds like a plausible distractor, yet it correctly describes granting only the access the employee's job requires — here, contact information rather than sales figures.

Separation of duties

Why it fails: Separation of duties splits a sensitive task across multiple people to prevent fraud, so it does not describe granting one employee excessive read permissions. It is tempting because it is a recognised access control principle, and it would be correct if the scenario involved one person both approving and paying invoices.

UID=jsmith

Why it fails: UID=jsmith is a relative distinguished name, not a component of a full DN; it identifies an entry only within its parent container. It is tempting because UID attributes do appear as RDN values in DN paths, and would be correct if the question asked for an RDN rather than a DN component.

SN=Smith

Why it fails: SN (Surname) is not a standard DN component in typical LDAP implementations.

GID=1234

Why it fails: GID=1234 is a POSIX group identifier, not an LDAP DN component; DNs are built from RDNs such as CN, OU and DC. It is tempting because GID genuinely appears in directory-integrated Unix attributes (for example, gidNumber in RFC 2307 schemas), where it would be the right answer if the question asked about POSIX group mapping.

Biometric reader on a door

Why it fails: A biometric reader on a door governs physical entry to a facility, not access to systems or data, so it fails the "logical" requirement. It is tempting because biometrics authenticate identity strongly, and such a reader would be the right choice when the scenario asks for a physical access control protecting a server room.

Fencing around a building

Why it fails: Fencing is a physical control, restricting bodily entry to a site rather than governing a subject's access to data or systems, so it cannot be a logical control. It is tempting because perimeter fencing genuinely enforces authorisation at the physical layer, and would be the right answer if the question asked for a physical or environmental control instead.

Security guards

Why it fails: Security guards enforce physical access to premises, making this a physical control, not a logical one. It is tempting because guards perform access control and identity checking, but they act on people and places; it would be correct if the control restricted access to systems or data.

Require a mix of uppercase, lowercase, numbers, and symbols, and force password changes every 30 days

Why it fails: NIST SP 800-63 advises against composition rules and forced periodic rotation, since complexity encourages predictable patterns and frequent changes degrade password quality. It is tempting because this matches longstanding conventional guidance, and would be correct under older policies rather than the current NIST standard.

Require a minimum length of 6 characters with no other requirements

Why it fails: 6 characters is insufficient; NIST recommends at least 8, preferably 15+.

Require a minimum length of 8 characters and check against breached password lists

Why it fails: Eight characters is below the fifteen-character minimum NIST SP 800-63 recommends for single-factor passwords, though breached-list checking is correct. It is tempting because it combines length with blocklist screening, and would be correct if the stated minimum matched NIST's fifteen-character guidance.

Biometric authentication

Why it fails: The scenario combines a possession factor (the card) with a knowledge factor (the PIN), which is multifactor authentication. Biometric authentication verifies an inherent physical trait such as a fingerprint or iris pattern, and would be the correct choice only where access is granted by scanning such a characteristic.

Single sign-on

Why it fails: Single sign-on lets a user authenticate once and then reach multiple independent applications without re-entering credentials. Here each entry requires two separate factors at one door, with no session token shared across systems, so SSO would be correct only for federated access across several applications.

Single-factor authentication

Why it fails: The card and PIN are two different factors, something held and something known, so this satisfies multi-factor authentication. Single-factor authentication applies when only one credential type is presented, such as a password alone or a card alone.

Separation of duties

Why it fails: Separation of duties divides a single process among multiple people so no one completes it alone, such as splitting payment approval from payment creation. Using separate admin and daily accounts is the principle of least privilege, limiting each account to only the rights its tasks require.

Defense in depth

Why it fails: Defense in depth layers multiple independent controls so one failure does not expose the asset. Separate administrator and daily-use accounts implement least privilege by restricting each identity's rights, not by adding overlapping layers of protection around the same resource.

Need-to-know

Why it fails: Need-to-know restricts access to information based on relevance to a specific task or project, typically for classified data. Separate admin and daily accounts limit the permissions each identity holds, which is least privilege, not an information-relevance restriction.

Password complexity requirements

Why it fails: Password complexity governs logical authentication to systems and accounts; it exerts no control over who physically crosses a doorway. A building-entrance control is a badge reader, turnstile, lock or reception check. Password complexity would be correct when hardening credential strength for user logins under an identity or password policy.

Biometric reader on a server room door

Why it fails: A biometric reader on a server room door controls entry to an internal high-security area, not the building entrance named in the question. The entrance control is the perimeter door itself, such as a badge reader or turnstile. This biometric deployment would be correct where the requirement is restricting access to the server room.

Account lockout policy

Why it fails: An account lockout policy is a logical control that disables credentials after failed logins; it cannot govern physical movement through a doorway. Building-entrance control requires a physical mechanism such as a badge reader, lock or turnstile. Account lockout would be correct when mitigating brute-force password guessing against authentication systems.

A fence around a building

Why it fails: A fence is a physical barrier controlling movement through a site boundary, not a logical control operating on data or systems. It is tempting because perimeter fencing genuinely restricts who can reach assets, but logical access controls govern authentication, authorisation and permissions rather than physical entry.

A security guard

Why it fails: A security guard is a physical control verifying people at a site, not a logical control governing system or data access. It is tempting because guards do enforce access decisions, but they operate on physical presence, whereas logical access controls authenticate identities and authorise resource use electronically.

A biometric reader on a door

Why it fails: A biometric reader on a door controls physical entry to a space, not logical access to systems or data. It is tempting because biometrics also authenticate users for logins, but here the mechanism releases a door strike, making it a physical control rather than a logical one.

Require at least one uppercase, one lowercase, one digit, and one special character

Why it fails: Composition rules reduce the search space attackers must cover, but they push users toward predictable patterns like Password1! and are no longer recommended. They tempt because they appear to strengthen passwords, yet length and breach screening deliver the entropy that character-class mandates only simulate.

Require passwords to be changed every 30 days

Why it fails: Frequent changes are discouraged unless compromised.

Attribute-Based Access Control (ABAC), because the decision uses department and managerial attributes.

Why it fails: ABAC evaluates many attributes of the subject, object, action, and environment through policies, which can resemble this scenario superficially. However, the described mechanism attaches rights directly to each record and checks them at open time under a classification scheme, which is characteristic of MAC labels rather than dynamic attribute evaluation. No contextual attributes such as time or location are mentioned.

Role-Based Access Control (RBAC), because Treasury staff share a department role.

Why it fails: RBAC assigns permissions to roles and then assigns users to those roles, so rights follow the job function rather than the individual record. In this scenario permissions are attached to each wire-transfer record and evaluated at access time, which is not how RBAC structures authorization. Department membership alone does not make this RBAC, because the decisive factor is the permission stored on the object.

Discretionary Access Control (DAC), because record owners set the permissions on their files.

Why it fails: DAC allows the owner of a resource to decide who may access it, which is not described here. Instead, the firm's classification policy dictates that Treasury staff may view and only the manager may approve, and the system enforces those rules. Owner discretion is absent from the scenario, so DAC does not fit even though users access records they do not own.

Federated identity with single sign-on, because the token is issued by a trusted identity provider.

Why it fails: Federation and single sign-on let users authenticate once with an external identity provider and access multiple services, typically involving human users and interactive sessions. Here a machine workload receives a short-lived token without a human logging in, and the emphasis is on cryptographic validation per request. While an identity provider may issue the token, the scenario's core mechanism is not federated SSO.

Passwordless authentication, because no static password is stored in the script.

Why it fails: Passwordless authentication replaces a user's password with another factor such as a security key or biometric, but it still concerns human login. The scenario involves a non-human automation service and a machine-issued token, not a person authenticating without a password. Removing static credentials is a benefit, yet the underlying access control concept being demonstrated is not passwordless login.

Rule-based access control, because the platform applies rules to each storage request.

Why it fails: Rule-based access control triggers on conditions such as time of day or network zone, and it is common in network devices like firewalls. Although the platform evaluates a policy when the request arrives, the distinguishing feature here is the short-lived cryptographic identity token rather than a static rule set. The scenario's purpose is credentialless machine identity, so rule-based access control is not the primary concept.

Configure the accounts to use a shared password stored in a team vault

Why it fails: Shared credentials destroy individual accountability because activity cannot be attributed to a specific administrator, and they expand the blast radius if the vault is breached. This weakens rather than strengthens authentication assurance. Privileged access should use unique per-person credentials with auditable actions, so a shared vault password is the opposite of the required improvement.

Increase the minimum password length from 12 to 16 characters

Why it fails: Longer passwords raise the cost of offline cracking and guessing, but they remain a single factor. If the password is phished or captured by malware, the attacker authenticates successfully regardless of length. Because the requirement is to improve authentication assurance for privileged accounts, a length change alone does not add a second verification method and is insufficient here.

Reduce the account lockout threshold from 10 to 5 failed attempts

Why it fails: A tighter lockout threshold slows online password guessing, but it does not verify who is authenticating once the correct password is known. An attacker holding valid credentials is unaffected by the lockout counter. Because the goal is stronger assurance for privileged accounts, lockout tuning is a useful hardening step but not a direct authentication-assurance improvement.

Defense in depth

Why it fails: Defense in depth layers multiple independent controls so no single failure exposes the system; it does not limit each user's permissions. Least privilege is the principle that grants only the minimum access needed. Defense in depth would be correct when designing overlapping controls such as firewalls, MFA and endpoint protection.

Separation of duties

Why it fails: Separation of duties splits critical tasks across multiple people to prevent fraud, rather than restricting each user's permissions to the minimum. Least privilege governs permission scope. Separation of duties would be correct when, for example, the person approving payments must differ from the person creating them.

Need-to-know

Why it fails: Need-to-know restricts access to specific data based on relevance to a task, not the breadth of permissions granted. Least privilege is the principle limiting permissions to the minimum required for a job function. Need-to-know is tempting because it also limits access, and would be correct when compartmentalising classified information by project.