Practice Test #1

This describes ransomware delivered via an email attachment: opening the attachment leads to file encryption and a ransom demand to regain access. While email may be the initial vector, the defining characteristic is malware-based extortion, not impersonation-driven financial fraud. This is not typically categorized as BEC on the exam.

This is a phishing/social engineering attempt to obtain credentials (requesting a cloud administrator login). It could be part of a broader BEC campaign, but the scenario itself is primarily credential harvesting and violates security policy (no legitimate HR director should request passwords). BEC questions usually emphasize payment diversion, invoice fraud, or executive impersonation for funds.

This is classic credential phishing: a link leads to a fake portal designed to steal usernames and passwords. It’s a common precursor to account takeover, which can later enable BEC, but the described activity is specifically phishing via a spoofed login page rather than the business-payment fraud focus of BEC.

Canceling current employee recognition gift cards is not directly responsive to the smishing attempt. The scam is about fraudulent purchasing and exfiltration of gift card codes, not compromise of an existing gift card program. Canceling legitimate cards may disrupt business operations and does not address the root cause (social engineering). A better response is warning users and reinforcing verification procedures.

Having the CEO change phone numbers is usually unnecessary and ineffective. Smishing/impersonation often uses spoofed numbers or lookalike identities; changing the CEO’s number does not prevent attackers from claiming to be the CEO again. It also creates operational disruption. The better approach is verification procedures and awareness rather than changing identifiers.

Conducting a forensic investigation on the CEO’s phone is not the best initial response given the facts. The scenario indicates impersonation via SMS, not confirmed compromise of the CEO’s device. Forensics is appropriate when there are indicators of device compromise (malware, suspicious logins, SIM swap evidence). Here, immediate user warning and training updates are higher-value responses.

Implementing mobile device management can improve mobile security posture (policy enforcement, app control, device compliance), but it is not the best direct response to an SMS impersonation/gift-card scam. MDM typically won’t prevent an attacker from sending fraudulent texts to employees. It’s a broader architectural control and may be beneficial long-term, but it’s not the top response for this specific incident.

Incorrect. User awareness training is typically delivered to users (email/LMS) or enforced via policy, not “to a device.” While an inventory system could help identify who has a laptop, the sticker itself doesn’t enable training delivery or ensure the right endpoint receives it. This is more of a security program/training administration function than a direct benefit of asset tagging.

Incorrect. Mapping users to devices for software MFA tokens generally depends on identity provider enrollment, device registration, MDM/UEM records, or device certificates. A physical asset sticker is not a trusted technical identifier for MFA provisioning and is not used by MFA systems to bind tokens. Asset tagging may help administratively, but it’s not the security benefit being tested.

Incorrect. User-based firewall policies are usually targeted using user identity (directory groups), device identity (hostnames, certificates), or MDM compliance state. A sticker does not integrate with firewall policy engines and cannot be reliably used for enforcement. Proper targeting requires technical controls like NAC, endpoint agents, or directory-based policy mapping.

Incorrect. Penetration testing targets are defined by scope (IP ranges, hostnames, applications) and discovered through technical inventory and scanning, not by physical stickers. Asset tags might help correlate a discovered host to a physical device after the fact, but they don’t materially enable targeting the “desired laptops” during a test.

Hardening is the process of reducing a system’s attack surface by applying secure configurations such as disabling unnecessary services, closing unused ports, removing default accounts, applying patches, and enforcing secure baselines. Restricting admin console access can be part of an overall hardening strategy, but the scenario is specifically about limiting permissions to certain users, which maps more directly to least privilege than to general system hardening.

Employee monitoring involves observing and recording user activities (e.g., session recording, keystroke logging, web filtering logs, DLP alerts, or SIEM correlation) to detect misuse, policy violations, or insider threats. The scenario does not describe monitoring or auditing behavior; it describes restricting access to an administrative function. Therefore, employee monitoring is not the technique being set up here.

Configuration enforcement ensures systems and applications maintain required settings and do not drift from an approved baseline. Examples include Group Policy, MDM profiles, security configuration management tools, and compliance checks (CIS benchmarks). While an admin console might be used to enforce configurations, the manager’s action is about limiting who can access that console, not about enforcing a configuration standard across endpoints or servers.

Risk tolerance describes the amount of risk an organization is willing to accept and can be expressed as thresholds (e.g., maximum acceptable residual risk). However, it is not typically the document used to list each risk and assign responsible parties. Tolerance is usually defined in policy or governance statements and then applied within tools like the risk register for escalation and acceptance decisions.

Risk transfer is a risk response strategy where the financial or operational impact is shifted to a third party (e.g., cyber insurance, outsourcing with contractual SLAs, indemnification). While transfer decisions may be recorded somewhere, “risk transfer” itself is not the primary artifact for documenting all risks, owners, and thresholds across the organization.

Risk analysis is the process of evaluating risk—often by determining likelihood and impact and calculating a risk rating (qualitative or quantitative). It produces inputs that may be recorded in a risk register, but it is not usually the ongoing tracking document that assigns owners, tracks remediation dates, and records acceptance/escalation thresholds for each risk.

Remote access points failing closed can be a good security practice (e.g., if an authentication service is unavailable, deny access). However, the question emphasizes “human life considerations” in a data center. Remote access behavior does not directly address life safety requirements like emergency egress. Therefore, while plausible from a security standpoint, it is not the best match to the scenario’s stated priority.

Logging controls should not “fail open” as a design goal. If logging fails, you lose visibility, detection, and forensic capability, which weakens security operations and compliance. In practice, some high-assurance environments may even fail closed (stop processing) if audit logging cannot be performed. Regardless, logging behavior is not the primary control tied to human life considerations, so this option is not the best answer.

Logical security controls should generally fail closed to preserve confidentiality and prevent unauthorized access when a dependency fails (e.g., deny access if an auth server is down). This is a correct principle, but it does not address the question’s key requirement: ensuring human life considerations are included. In a data center review that explicitly calls out life safety, the best description is that safety controls fail open.

Default credentials are a common deployment risk for devices and self-managed applications (e.g., routers, IoT, on-prem apps). However, the scenario’s distinguishing detail is that the system is supported by a SaaS provider, not that it ships with default passwords or that the technician is configuring accounts. While still possible, it is not the primary risk being tested here.

A non-segmented network is a security architecture concern: flat networks increase lateral movement and blast radius. The question, however, focuses on opening firewall ports for a SaaS-supported system. Segmentation might be a good design recommendation, but it is not the key risk introduced by using a SaaS provider and exposing connectivity for it.

Vulnerable software is always a concern, but SaaS typically shifts patching responsibility to the provider under the shared responsibility model. The question does not mention outdated versions, missing patches, or known CVEs. The more specific and differentiating risk in the prompt is third-party/supply chain exposure rather than a generic software vulnerability.

Incorrect. An account lockout usually results in log entries indicating the account is locked/disabled or that authentication is denied at the password stage. Here, the password authentication continues to succeed repeatedly, which is inconsistent with a lockout condition. If lockout were occurring, you would expect subsequent attempts to fail immediately rather than proceed to MFA validation.

Incorrect as the best explanation. A keylogger could be one way the attacker obtained the correct password, but the logs do not provide evidence of a keylogger specifically. The observable behavior is repeated MFA failures with a successful password, which more directly indicates someone is attempting to guess or bypass the second factor rather than proving malware on the workstation.

Incorrect. Ransomware deployment would typically generate endpoint detection alerts, unusual process execution, mass file modifications/encryption, shadow copy deletion, or lateral movement indicators. Authentication logs showing repeated invalid MFA codes do not align with ransomware activity. While attackers may use compromised accounts for initial access, this log pattern alone points to an authentication attack, not ransomware execution.

A bastion host is a hardened, exposed system used to access a protected network segment (often in a DMZ). If you truly have an air gap, you generally do not have a network-connected bastion providing a route in/out. Bastion hosts are relevant to segmented networks with controlled connectivity, not to fully isolated environments. Therefore, it is not the most common data loss path for an air-gapped network.

Unsecured Bluetooth can be a data loss path if Bluetooth radios are present and enabled, but in properly designed air-gapped environments, wireless interfaces are typically prohibited or physically removed/disabled. While Bluetooth-based exfiltration is possible, it is less common than removable media because it requires compatible hardware, proximity, and often violates standard air-gap operational controls.

An unpatched OS is a vulnerability, not a “path” by itself. In an air-gapped network, attackers still need a delivery mechanism to exploit the unpatched system (e.g., infected removable media, compromised supply chain, or an insider). Unpatched systems increase risk and impact, but the most common way data actually leaves an air-gapped environment is through physical transfer methods.