Control Implementation practice questions

The interface is not assigned to a security zone

Why it fails: ASA interfaces are assigned to security levels, not zones.

The traffic is encrypted by VPN

Why it fails: VPN traffic is processed by the crypto map, but rules are still applied post-decryption.

Missing 'permit ip any any' at the top

Why it fails: This would permit everything, bypassing the intent of the rules.

Disable logging on the domain controller

Why it fails: This prevents monitoring of critical security events.

Delete logs after ingestion

Why it fails: This violates audit trail integrity requirements.

Increase log rotation frequency

Why it fails: This impacts storage management but not log noise reduction.

CNAME

Why it fails: A CNAME record maps an alias to a canonical name.

A

Why it fails: An A record maps a domain to an IP address.

MX

Why it fails: An MX record points to mail servers.

Modify permission

Why it fails: Modify permission includes the right to change or delete files.

Full Control

Why it fails: Full Control allows deletion and modification.

Write permission

Why it fails: Write permission allows changing content and often deletion.

Full disk encryption (FDE) on the database server

Why it fails: FDE protects data if the physical disk is stolen, but it does not protect against unauthorized access through the database application or misconfigured permissions. In a cloud environment, the physical disk is managed by the provider, so FDE is less relevant than field-level encryption and access controls.

Network segmentation to isolate the CRM database

Why it fails: Network segmentation reduces the attack surface but does not directly protect data at rest. It is a preventive control for network-level threats, not a data-at-rest protection mechanism. While valuable, it does not fulfill the specific requirement for protecting stored data.

TLS 1.3 for data in transit between the web server and database

Why it fails: TLS 1.3 protects data in transit, not at rest. While important for securing communications, it does not address the requirement to protect stored data in the CRM database. Therefore, it is not the most appropriate control for data at rest.

Network segmentation between the POS system and corporate network

Why it fails: Network segmentation is a network security control that limits the scope of the cardholder data environment, but it is not a logical access control. It does not manage user authentication or authorization. While valuable for PCI DSS, it is not the correct category for this question.

Security cameras monitoring the POS area

Why it fails: Security cameras are a physical detective control, not a logical access control. They can deter and record physical incidents but do not control logical access to POS systems. Therefore, they do not meet the requirement for logical access controls in this scenario.

Physical locks on POS terminals

Why it fails: Physical locks are a physical security control, not a logical access control. While important for protecting terminals from tampering, they do not govern logical access to systems or data. The question specifically asks for logical access controls, so this option is incorrect.

Conducting annual security awareness training for all employees.

Why it fails: Security awareness training is an administrative control that educates staff but does not technically enforce protection of NPI. It may reduce human error, but it does not directly prevent unauthorized access through technical means. GLBA technical controls are implemented via systems, not training programs, so this option is not appropriate here.

Performing quarterly vulnerability scans of the network.

Why it fails: Vulnerability scanning is a technical control that identifies weaknesses but does not directly protect NPI; it is a detective rather than preventive measure. While valuable, it does not mitigate unauthorized access by itself. GLBA technical controls should include preventive measures like encryption or access enforcement, making this option less suitable than the correct choices.

Implementing mandatory vacation policies for employees with access to NPI.

Why it fails: Mandatory vacation is an administrative control that reduces the risk of fraud by requiring employees to take time off, but it does not technically prevent unauthorized access. It relies on human resource processes rather than automated enforcement. GLBA technical controls must directly protect NPI through technology, so this option is not a technical control.

Create a Path Rule for C:\Program Files\*

Why it fails: A path rule allows any executable in that folder regardless of signature, so unsigned binaries placed there would run. It is tempting because path rules are the simplest AppLocker rule type; they suit locking down known, trusted directory locations rather than enforcing publisher signatures.

Configure the 'Audit only' mode in Group Policy

Why it fails: Audit-only mode logs what would be blocked without enforcing anything, so unsigned binaries still execute. It is tempting as a safe first step to validate rules before enforcement; it would be correct during a pilot phase, not when signed-only execution must actually be enforced.

Create a Hash Rule for every existing executable

Why it fails: Hash rules match specific file contents, so any new or updated binary is unmatched and every executable must be re-hashed manually, which cannot enforce signed-only execution. It is tempting because hashes are precise; they suit fixed, unchanging files rather than a publisher-signature requirement.

BitLocker

Why it fails: BitLocker is Microsoft's Windows-native full disk encryption feature and does not encrypt Linux volumes; the requirement is FDE on a Linux server. Tempting because BitLocker satisfies PCI-DSS FDE on Windows hosts, which would be the correct choice had the server run Windows.

IPsec

Why it fails: IPsec encrypts network traffic between hosts or gateways, not data at rest on the disk, so it cannot satisfy the PCI-DSS FDE requirement. Tempting because IPsec protects database data in transit, which is the right control when the requirement is securing communications rather than stored volumes.

VeraCrypt

Why it fails: VeraCrypt is typically used for container-based or partition-based encryption, not system-wide FDE.

Outbound Rule: Type HTTPS, Port 443, Destination 0.0.0.0/0

Why it fails: Outbound rules govern traffic leaving the instance, not inbound HTTPS from the internet, so this cannot permit client connections. It is tempting because 0.0.0.0/0 as a destination mirrors the any-source pattern used for public-facing access, but that pattern belongs on an inbound rule.

Inbound Rule: Type All Traffic, Port All, Source 0.0.0.0/0

Why it fails: Allowing All Traffic on every port from 0.0.0.0/0 opens the instance to every protocol, violating the requirement to restrict all other traffic. It is tempting because it guarantees HTTPS works, and a broad allow is occasionally used in lab environments, but production compliance demands port 443 alone.

Inbound Rule: Type HTTPS, Port 443, Source 127.0.0.1/32

Why it fails: Source 127.0.0.1/32 restricts the inbound rule to the loopback address, so only traffic originating on the instance itself matches; internet clients are dropped. It is tempting because loopback scoping is a legitimate hardening technique for management interfaces, but a public web server needs 0.0.0.0/0 on port 443.

Directly on the public ISP router

Why it fails: Placing the sensor on the ISP router only sees traffic crossing that WAN boundary, so east-west traffic between internal segments never reaches it. It is tempting because the ISP demarcation is a convenient, always-powered vantage point for external threat monitoring, and it would suit an organisation that only needs to inspect inbound and outbound internet traffic.

Inside the isolated guest Wi-Fi network

Why it fails: A sensor inside the isolated guest Wi-Fi network only inspects guest-to-internet flows; internal corporate traffic and external traffic to other zones bypass it entirely. It is tempting because guest networks are high-risk and easy to instrument, and this placement would be correct if the requirement were solely to monitor guest-user activity.

On the WAN interface of the firewall

Why it fails: The WAN interface of the firewall only carries traffic entering and leaving the internet edge, so internal-to-internal traffic is invisible to the sensor. It is tempting because the firewall WAN interface is a natural choke point for external threats, and it would be the right placement if only perimeter traffic needed inspection.

OCSP Responder

Why it fails: An OCSP Responder answers real-time revocation queries but does not itself enable revocation; the CA must publish CRLs or delegate OCSP signing, and clients must be configured to check. It is tempting because OCSP is a revocation technology, yet without CRL distribution points or an OCSP URL in issued certificates, revocation cannot be enforced.

Key Archival

Why it fails: Key archival stores private keys for recovery, not revocation status; revocation relies on CRL distribution points or OCSP responders. It is tempting because archival supports key recovery after loss or employee departure, which is the correct choice when encrypted data must remain decryptable.

Trust Anchor

Why it fails: A trust anchor is a public key or certificate used to validate a certification path, providing no revocation-checking mechanism. It is tempting because it is a required PKI component, but revocation needs CRL distribution points or an OCSP responder configured on the issuing CA.

Password Protection Policy

Why it fails: Password Protection Policy blocks weak or banned passwords and enforces custom banned lists; it does not challenge users with a second authentication factor. It is tempting because it is a Microsoft Entra ID authentication policy, and it would be correct if the requirement were password strength rather than MFA enforcement.

Security Defaults

Why it fails: Security Defaults enforce MFA for all users but cannot be scoped, and they are disabled once Conditional Access policies exist. They are tempting as a free tenant-wide baseline, and would be correct for a small organisation with no Conditional Access licensing or granular policy needs.

Identity Protection User Risk Policy

Why it fails: Identity Protection user risk policies act on calculated sign-in risk signals, not on baseline MFA enforcement for all users. They are tempting because they add adaptive MFA when leaked credentials are detected, which suits organisations already running Conditional Access and wanting risk-based step-up authentication.

Encapsulating EAP frames

Why it fails: RADIUS carries EAP payloads between the authenticator and the authentication server; it does not encapsulate EAP frames, which the supplicant and authenticator handle within EAPoL. The tempting association arises because RADIUS transports EAP messages, so it would be the answer if the question asked how credentials reach the authentication server.

Providing the EAP method to the client

Why it fails: The EAP method is negotiated end-to-end between the supplicant and the authentication server; the client selects it, not RADIUS. RADIUS receives the encapsulated EAP exchange and validates credentials against a directory, returning accept or reject to the authenticator.

Enforcing the physical port state

Why it fails: RADIUS carries authentication, authorisation and accounting attributes; it does not control the physical port state, which the authenticator (switch or access point) sets via EAPOL and the PAE. It is tempting because RADIUS authorisation attributes such as Tunnel-Type can influence VLAN assignment, but port blocking remains the authenticator's function.

Share the ESXi root password

Why it fails: Sharing the ESXi root password destroys individual accountability and makes privileged actions unattributable, whereas console access should be granted through named accounts with least privilege. Shared credentials suit no governance scenario; unique per-administrator accounts are required for any auditable vSphere deployment.

Disable all logging

Why it fails: Disabling logging removes the audit trail needed to detect console access and tampering, directly undermining accountability for privileged VM operations. Logging is retained and forwarded to a central syslog host precisely so that console sessions can be investigated after an incident.

Leave the VNC port open

Why it fails: Leaving the VNC port open exposes VM consoles to unauthenticated network access, undermining console security. It is tempting because VNC enables remote console access for administration, but best practice restricts console connections to the management network and disables unused remote console services.

Disable all auditing

Why it fails: Disabling auditing erases the evidence needed to detect misuse and reconstruct what a compromised DBA account did, increasing impact instead of minimising it. It is tempting to reduce log volume or overhead, and would be acceptable only where no accountability or forensic requirement exists, which contradicts this scenario.

Store passwords in plain text

Why it fails: Plain-text storage exposes credentials to anyone reading the database or its backups, guaranteeing immediate compromise rather than limiting blast radius. It is tempting when authentication integration is difficult, and would only be defensible in an isolated test system with no real credentials, never for a production DBA account.

Use a single shared account

Why it fails: A shared account removes individual attribution, so auditing cannot tie privileged actions to a person and revocation after compromise affects every user. It is tempting for reducing administrative overhead, and would suit a scenario where accountability is not required, but it defeats the separation and traceability this control demands.

Encryption at Rest

Why it fails: Encryption at rest protects stored objects cryptographically but does not restrict who may retrieve them; an anonymously readable object remains readable regardless of encryption. Encryption addresses confidentiality of data at rest, and would be the correct control when the requirement is protecting PII from storage-media disclosure rather than public access.

Bucket ACLs

Why it fails: Bucket ACLs are legacy access controls that can themselves grant public read or write permissions, so they are a common cause of exposure rather than the primary preventive mechanism. ACLs suit per-object grants to other AWS accounts; blocking public access is done through the account-level and bucket-level Block Public Access settings.

IAM User Permissions

Why it fails: IAM user permissions govern identity-based access for principals within the account, but they do not override bucket policies or ACLs that grant anonymous public access, so they cannot block public exposure. IAM policies are the right control for restricting which authenticated users and roles may call S3 APIs.

Biometric scanner

Why it fails: A biometric scanner authenticates one person per scan but does not detect or stop a second individual entering on the same authenticated door cycle. It is tempting because biometrics give strong identity assurance, and it would be correct where the requirement is verifying an individual's identity rather than controlling how many people pass through.

CCTV camera

Why it fails: CCTV records entry events but cannot physically block a second person tailgating behind an authorised badge holder; it only provides after-the-fact evidence. It is tempting because surveillance supports investigations and deterrence, and would be the right choice where the requirement is monitoring or auditing an entrance rather than stopping unauthorised passage.

Security guard

Why it fails: A security guard observes and challenges people but is not a physical barrier preventing tailgating; a person can still follow an authorised entrant through. It is tempting because guards provide human judgement and deterrence, and would be correct where the requirement is monitoring, challenging or responding to incidents rather than mechanically restricting passage.

Shared administrative password

Why it fails: A shared administrative password removes individual accountability, so audit logs cannot attribute actions to the developer, and rotation after departure becomes unmanageable. It is tempting because it is simple and requires no directory integration, and it would suffice for a single-operator lab or legacy appliance lacking identity-provider support.

VPN connection to the internal network

Why it fails: A VPN only encrypts transport into the network; it grants no per-session authorisation, credential rotation, or command logging on the server itself. VPN access is the right control when the requirement is secure remote connectivity to a trusted network segment.

Direct SSH access to the server

Why it fails: Direct SSH bypasses the broker that would issue short-lived, audited credentials, so the developer holds standing access to the production host. Direct SSH is appropriate for isolated lab machines where no privileged-access mediation or session recording is required.

OUTPUT

Why it fails: The OUTPUT chain filters packets generated locally before they leave the host, not traffic arriving for the local host. It would be correct for restricting outbound connections, but inbound traffic destined for the host is filtered by the INPUT chain.

FORWARD

Why it fails: FORWARD processes packets routed through the host to another destination, so it never sees traffic addressed to the local machine; INPUT does. It is tempting because FORWARD filters traffic, but only transit traffic, making it correct for a router or gateway, not a local-delivery firewall.

PREROUTING

Why it fails: PREROUTING handles packets before routing, so it cannot filter traffic already destined for the local host; that is the INPUT chain's role. It is tempting because PREROUTING does filter inbound packets, but only for DNAT and similar pre-routing tasks, not local delivery.