Select Two (Multi-Select) Questions

HTML-encode the report name before inserting it into the shell command.

Why wrong: HTML encoding protects web pages from script injection, not operating-system shell interpretation. It does not stop the shell from treating characters like semicolons or pipes as command separators. The control does not address the execution context shown in the scenario.

Switch the feature from POST to GET so the values are easier to inspect.

Why wrong: Changing HTTP method does not fix command injection. The vulnerability is in how the server uses the input, not in the request verb. GET may even make sensitive values more visible in logs and history without improving security.

Hide the server error messages so attackers cannot see the failure details.

Why wrong: Suppressing error output can reduce information leakage, but it does not stop command execution. The application would still process attacker-controlled shell content if the input is unsafe. This is a helpful hardening measure, not a root-cause fix.

Email phishing is used because the attacker is requesting a login action.

Why wrong: Phishing is a broad term, but this scenario is specifically about SMS and voice, not email. Since the channel is not email, calling it email phishing would be inaccurate. The attacker may still be phishing generally, but the more precise attack channels are different and more useful for response.

Baiting is used because the attacker offers a free reward or device.

Why wrong: Baiting usually involves enticing the victim with something attractive, such as free media, hardware, or a promised benefit. This scenario instead uses a fake service request and a follow-up call. There is no lure of a reward, so baiting is not the best fit.

Tailgating is used because the attacker follows someone into a restricted area.

Why wrong: Tailgating is a physical social engineering tactic involving unauthorized entry into a secured space. This scenario takes place over SMS and phone, so it does not involve a person following another through a door or into a controlled area. That makes tailgating irrelevant here.

The pattern is most consistent with password spraying across many accounts.

Why wrong: Password spraying is characterized by a small number of common passwords being tried against a large set of usernames, specifically to avoid triggering account lockout policies. In this SIEM data, all 17 failures are concentrated on a single account, not distributed across many accounts. That concentration is the opposite of spraying's low-and-slow approach, so while both are credential attacks, the pattern does not match spraying.

The events primarily indicate a volumetric denial-of-service attack.

Why wrong: A volumetric denial-of-service attack is designed to exhaust network bandwidth, server connections, or other resources by flooding them with high-volume traffic. The events here consist of 17 authentication failures and a token creation — neither of which generates the massive traffic required for a DoS. There is no indication of resource saturation or service unavailability, so the sequence is clearly about credential access and session abuse, not availability disruption.

Token creation proves the account password was never exposed.

Why wrong: Creating a token after a successful login is often the direct result of the attacker authenticating with the correct password, which could have been obtained through the brute-force attack. Tokens are issued by identity providers after authentication succeeds, so their existence is evidence that the password was used, not that it was never exposed. A compromised password frequently leads to token creation as part of persistence, so this option misreads the forensic artifact.

Increase retention to keep backups for two years without changing restore testing.

Why wrong: Incorrect because longer retention alone does not prove recoverability. Old backups that are never tested may still fail when restoration is needed.

Move the backup repository onto the same always-mounted file share as production data.

Why wrong: Placing the backup repository on the same always-mounted file share as production data eliminates offline isolation, meaning a ransomware attack or storage failure that corrupts the live share simultaneously destroys the backup set. This directly violates the requirement for a restorable copy within the 4-hour RTO, because no independent recovery source exists. It is tempting because co-location simplifies storage management and reduces network transfer time, and would be correct in a scenario where the RTO is zero and continuous data protection from the live volume is acceptable.

Reduce the number of user permissions on the file server without changing backup design.

Why wrong: Incorrect because access reduction may be good hygiene, but it does not directly improve recovery confidence. The question asks about restore assurance and resilience.

User files are renamed with a new extension and a ransom note appears.

Why wrong: Renamed files and ransom notes are classic signs of ransomware, not spyware. Ransomware focuses on extortion through encryption or disruption, while spyware focuses on covert collection of data. This behavior points to a different malware family and does not match the scenario described.

CPU usage spikes only during a scheduled operating system update.

Why wrong: Temporary CPU usage during a scheduled update is normal and does not imply malware. Without further evidence such as suspicious processes, odd network destinations, or unauthorized persistence, this is not a useful spyware indicator. It is more likely to be ordinary maintenance activity.

The browser certificate store was refreshed after applying a patch.

Why wrong: Refreshing the certificate store after a patch is a normal administrative event. It does not indicate keylogging, exfiltration, or covert monitoring. While certificate manipulation can be malicious in some attacks, this specific detail is routine and not aligned with the spyware behaviors in the scenario.

Policy, because it explains the organization's overall security intent in broad terms.

Why wrong: A policy is a high-level document that conveys management's overall security intent and principles (e.g., 'protect the confidentiality of credentials'). It establishes the 'why' but does not specify the mandatory control details or exact operational steps needed to perform a password reset securely. While policy is foundational, it lacks the measurable, enforceable requirements (like MFA or minimum password length) and the step-by-step actions that this scenario demands, so it cannot serve as the requested standard and procedure.

Guideline, because it provides recommended practices that staff may ignore if needed.

Why wrong: A guideline offers advisory, recommended practices that are never truly mandatory; staff could reasonably choose to ignore it without violating formal security requirements. For a high-risk support function like password resets, relying on a guideline would allow inconsistent identity verification, ticket handling, and reset execution, potentially reintroducing the very incidents the organization wants to prevent. The question specifically asks for one document that mandates minimum requirements and another that gives exact steps, so a guideline, being optional, is not the right choice for either.

Baseline, because it is mainly used as a casual reference document for analysts.

Why wrong: A baseline can define a known-good configuration state, but it is not the best answer for the two requested document types. The scenario specifically calls for one mandatory requirement document and one step-by-step operational document.

Allow inbound traffic from the internet directly to the application servers.

Why wrong: Allowing internet users to connect directly to the application tier bypasses the web tier’s role as the single entry-point and forces those backend servers to become internet-exposed, which dramatically increases their attack surface. Application servers typically hold business logic and may have direct connections to sensitive databases, so exposing them to the internet would allow malicious traffic to reach them without passing through the web server’s filtering or reverse-proxy protection. In a correctly segmented design, only the web server—placed in the DMZ—should accept inbound client sessions; the application tier must never have a public IP or an open inbound ACL from the internet. This is not just a network design preference; it is a security control to prevent direct, unrestricted access to the most critical processing components.

Put the database on the guest Wi-Fi VLAN.

Why wrong: The guest Wi-Fi VLAN is intentionally isolated for visitors and is considered an untrusted zone, with no premise of security or internal resource trust. Placing the database—the most sensitive back-end component—on that segment would expose critical data to any guest who joins the Wi-Fi, often without strong authentication or endpoint protection. Even if network isolation is configured, a compromised guest device could pivot to the database, and the VLAN’s purpose (to give internet-only access) directly conflicts with the requirement to protect backend data. A database should reside on a dedicated internal VLAN that only accepts traffic from the application tier, protected by strict firewall ACLs, not on a public-facing guest segment.

Use the same flat network for all three tiers.

Why wrong: A flat network provides no segmentation between the web, app, and database tiers, so an attacker who compromises the web tier can directly reach the app tier without traversing any firewall or access control list. This violates the requirement that the app tier must never be reachable from the internet. The temptation is that a flat network simplifies routing and reduces latency between tiers, and it would be correct if all tiers were equally trusted and no internet-facing isolation were needed.

Average time to patch critical vulnerabilities in production systems

Why wrong: This is a vulnerability management metric that reflects patching speed, risk prioritization, and IT operational efficiency, not the security knowledge or behavior of employees. While critical for reducing exposure, it depends on system administrators and automated processes rather than on the awareness curriculum, so it is not a valid measure of the training program's impact.

Number of firewall rule changes approved per quarter

Why wrong: This is a network administration and change management metric that counts firewall rule changes, which are typically driven by application requirements, business need, or security engineering work. It does not involve employee knowledge or decision-making, and it measures operational throughput rather than the effectiveness or reach of a security awareness program.

Percentage of servers with full disk encryption enabled

Why wrong: This is a data-at-rest protection metric that measures the percentage of servers configured with full disk encryption, a technical control enforced by IT policies and system settings. It is a configuration management and endpoint security measure, unrelated to employee awareness or training, and therefore does not evaluate the awareness program's success.

Immediately shut down the portal until the dependency risk is completely eliminated.

Why wrong: Shutting the portal down is a form of risk avoidance, which conflicts with leadership's stated desire to keep the service available. It may be appropriate in some high-risk situations, but it does not fit this scenario's requirement to continue operations.

Ignore the finding until the next annual audit cycle.

Why wrong: Ignoring the finding until the next annual audit cycle is not a risk treatment option; it effectively defers any decision on mitigation without formally documenting the residual risk or obtaining management acceptance. Known unmitigated vulnerabilities create ongoing legal and operational liability, and an audit may not even re-examine the same control, leaving the organization exposed indefinitely. This violates due care principles and could be considered negligence if the risk materializes.

Transfer the issue to the help desk by opening a routine support ticket.

Why wrong: Opening a routine support ticket does not transfer risk in a risk management context; risk transfer shifts financial liability to a third party via insurance, contractual indemnities, or outsourcing agreements. The help desk can execute patching or workarounds, but that is operational mitigation, not legal or financial risk transfer. Furthermore, a routine ticket lacks the urgency and management authority needed to properly address a security dependency, so it may be deprioritized and leave the portal vulnerable without a formal decision.

Let all corporate laptops connect directly to SSH on the servers if MFA is enabled.

Why wrong: Enabling MFA on direct SSH connections does not prevent lateral movement if an admin laptop is compromised, because an attacker with access to an authenticated session can still pivot to other servers without re-authenticating. This design also fails to log every administrative session centrally, as SSH logs remain on individual servers rather than being captured in a session recorder or jump host. It is tempting because MFA is a strong authentication control that reduces credential theft risk, and in a scenario where only authentication security matters—without requirements for session logging or lateral movement containment—it would be a valid choice.

Expose SSH to the internet because key-based authentication is already strong.

Why wrong: Publicly exposing SSH is unnecessary and increases brute-force, scanning, and exploitation risk. Key-based authentication helps, but it does not justify direct internet access to management services. The requirement is to remove direct access from employee laptops, not extend management services to untrusted networks.

Use split tunneling for admin traffic so management packets can bypass the VPN.

Why wrong: Split tunneling is generally used to route some traffic outside the secure tunnel, which is the opposite of what this scenario needs. Management traffic should be tightly controlled and inspected, not routed around security controls. Bypassing the VPN would weaken the protected management path.

change the default gateway IP address on the subnet

Why wrong: Changing the gateway address does not stop an attacker from forging ARP responses on the local segment. The poisoning issue is about false layer 2 mappings, not the specific gateway IP value. This would create administrative work without addressing the root cause.

disable spanning tree protocol to reduce switching delays

Why wrong: Spanning tree is unrelated to ARP poisoning and should not be disabled as a response to spoofed ARP traffic. Turning it off can actually create loops and instability on the network. This option addresses the wrong problem and could make the environment less reliable.

replace private addressing with NAT on every endpoint

Why wrong: Network address translation does not prevent layer 2 spoofing on a local subnet. The attack happens before traffic leaves the segment, so NAT is not the right mitigation. This would not stop forged ARP replies from redirecting traffic.

Allow each user to customize local security settings for productivity.

Why wrong: User-driven customization increases inconsistency and makes it harder to prove that devices are secure. Local changes may weaken controls, create exceptions, or interfere with patching and support. The scenario is asking for standardization and drift reduction, not personalization.

Skip validation after patching because the baseline will always remain correct.

Why wrong: Assuming patching always succeeds without verification creates blind spots and delays detection of failed updates. Validation is necessary because systems can miss patches, reboot unexpectedly, or diverge from the intended configuration. The organization needs monitoring and reporting, not blind trust in deployment.

permit tcp host 10.10.20.20 any eq 8443

Why wrong: This rule is written in the wrong direction and is far too broad. It permits traffic sourced from the application server to any destination, which does not match the required flow. ACLs must be precise about source, destination, and direction.

permit ip any any

Why wrong: This would allow all traffic through the interface and completely defeat the purpose of the segmentation boundary. A rule like this is useful only when the goal is unrestricted access, which is the opposite of the scenario. Default deny should remain in place for all other flows.

permit udp 10.10.10.0/24 host 10.10.20.20 eq 8443

Why wrong: The application requires TCP, not UDP, so this rule would not allow the intended service to function. It also uses a broad subnet rather than the specific web host. Protocol and addressing must match the actual application flow.

Send the full employee record set because the contractor is trusted.

Why wrong: Trusting a third party does not eliminate privacy obligations or the risk of compromise. A trusted contractor may still misconfigure storage, fall victim to phishing, or have an insider threat—all of which can expose personally identifiable information (PII). Sending entire records violates the principle of least privilege and data minimization, expanding the attack surface without adding functional value for the benefits project.

Upload the file to a public collaboration site so the contractor can retrieve it easily.

Why wrong: Using a public collaboration site removes authentication and encryption, making employee PII indexable and accessible to anyone with the link. Without access controls, the file could be crawled by search engines, downloaded by unintended parties, and retained by the provider, leading to likely breach notification obligations and severe privacy violations. Secure file transfer should use encrypted repositories with per-user permissions and audit trails.

Keep an unrestricted copy on multiple shared drives for convenience.

Why wrong: Creating unrestricted copies on multiple shared drives expands the attack surface and complicates access revocation—any one copy can leak without the others being traceable. Uncontrolled data sprawl violates data retention and disposal policies, increases the likelihood of malware infection, and makes compliance audits difficult. Convenience is not a valid justification for bypassing hardware security and least-privilege controls.

The email contains a professional logo and a consistent signature block.

Why wrong: Attackers often copy logos, signatures, and branding from legitimate companies. Those elements can make the email look trustworthy, but they do not prove authenticity. They are weak indicators compared with workflow bypass and verification-blocking language.

The email uses correct spelling and grammar throughout.

Why wrong: Clean writing does not make a message legitimate. Many spear-phishing and pretexting emails are professionally written, especially when crafted by experienced attackers. Security decisions should rely on identity verification and process anomalies, not just presentation quality.

Keep app accounts manually managed so each app owner can decide independently.

Why wrong: Manual administration delegates deprovisioning to each application owner, but these owners rarely receive timely or complete HR status changes. When an employee transfers, their accounts in applications outside the owner's purview are easily forgotten or incorrectly kept, since the owner lacks a unified view. This fragmented approach produces a siloed, inconsistent lifecycle, with some apps revoked and others still active, and it fails to scale and lacks proper auditability.

Share a generic help desk password for quick access restoration.

Why wrong: Sharing a generic help desk password for quick restoration creates a permanent backdoor into every application. Because multiple people authenticate with the same credentials, the system cannot attribute actions to an individual user, breaking non-repudiation and auditing, and an already privileged user could use it to escalate further. Moreover, it fails to solve the underlying lifecycle problem—it simply adds an uncontrolled, high-risk lateral movement path and undoes any benefit from automated provisioning.

Require password changes every 30 days for all users.

Why wrong: Requiring password changes every 30 days only refreshes the authentication secret; it does not alter the user's authorization or application entitlements. An employee who transferred to another department can still access old team resources as long as their account and memberships remain active. Frequent password rotation can even reduce security by prompting users to choose predictable or reused passwords, and it distracts administrators from the real issue of re-certifying who has access to what.

Allow users to install any app if they promise not to open work files.

Why wrong: Requiring a verbal or written promise not to open work files assumes user behavior is a reliable security control, but technical enforcement is absent. If the device installs arbitrary apps from unapproved stores or sideloads, those apps can request broad permissions and potentially access corporate data via file shares, attachments, or clipboard, even if the user later avoids opening work files. The policy is unenforceable, creates a false sense of security, and violates mobile security best practices that require application allowlisting, integrity verification, and permission hygiene.

Store corporate files in the personal photo gallery for easier backup.

Why wrong: Storing corporate files in the personal photo gallery removes the technical separation that makes containerized management possible, because the gallery is typically synced to consumer cloud services like iCloud or Google Photos and is accessible to any installed app with storage permissions. This exposes sensitive business data to personal cloud backup, unintended sharing, and third-party app data collection, and it eliminates the ability to perform a selective wipe on that data without erasing the user's personal memories. It also defeats the purpose of the work profile because the corporate data leaves the managed boundary.

Disable screen locks so users can access business apps faster.

Why wrong: Disabling screen locks—removing PIN, pattern, or biometric authentication—lets anyone who picks up the device access the corporate apps and the underlying managed container without authentication. This violates the principle of least privilege and basic mobile device hardening, as the device's encryption at rest becomes ineffective when an attacker can simply unlock the screen. Even in a low-risk environment, the mobile device can be lost or stolen, and without a lock screen the corporate data is immediately exposed, making this a severe security regression.

Assume the traffic is benign because it happens on a fixed schedule.

Why wrong: A fixed schedule is not a reliable indicator of legitimacy; many malware families use periodic beaconing to evade detection and maintain C2 channels. Security analysts must validate the source process, destination, and signature before dismissing the alert, rather than relying solely on timing patterns.

Suppress all alerts from the host permanently after this one event.

Why wrong: Permanently suppressing alerts for a host after a single event eliminates visibility and may mask subsequent malicious activity, especially if the original alert was actually a false negative. Tuning should be minimal and evidence-based—ideally scoped to the specific process or destination—and should never be based on a one-time assumption that no further investigation is needed.

Stop collecting logs from the server so the same alert does not recur.

Why wrong: Disabling log collection on the server is disruptive and degrades the security posture, making it harder to perform incident response or retrospectively analyze behavior. Instead of preventing future alerts, the analyst should validate the current alert and, if warranted, adjust the rule with a specific exception that still retains the log data for auditing.

Printer spooler logs

Why wrong: Printer spooler logs capture print job metadata, spooler service errors, and driver load events on hosts with attached printers. These logs are entirely local to the print subsystem and do not contain any records of cloud control-plane API calls, IAM policy changes, or command execution within virtual machines. They would be irrelevant in an investigation of cloud configuration changes unless the question specifically concerned printing activity on a particular host, which is not the case here.

Browser history from employees' home PCs

Why wrong: Browser history from employees' home PCs is non-authoritative, outside corporate logging scope, and easily cleared or manipulated. Even if it showed visits to the cloud provider's web console, it would not record the underlying API parameters, the exact configuration change made, or the authenticated context beyond a possible URL fragment. Forensic investigations rely on server-side audit logs that cannot be altered by the user, not on client-side browsing artifacts that lack integrity and chain of custody.

DHCP lease logs from the office router

Why wrong: DHCP lease logs from the office router record which IP address was assigned to a given MAC address and for what period. While they might help correlate a device's IP at a specific time, they contain no information about cloud account activity, control-plane API calls, or commands executed inside a virtual machine. The logs are also limited to the local network segment and do not extend to cloud-hosted services, making them useless for this requirement.

Shared generic accounts for each department.

Why wrong: Creating a shared generic account for each department (e.g., a single 'sales@' login) would make every member of the department authenticate with identical credentials, destroying non-repudiation and auditability. It is impossible to tell which specific user performed a given action, which complicates incident response and compliance reporting. Additionally, password changes must be communicated to everyone, and when any user leaves, the shared password must be rotated and redistributed, making it both a security and an administrative burden.

Storing the same password inside every SaaS application.

Why wrong: Storing the same password in every SaaS application forces users to use either a single weak password or a memorable one for all services, dramatically increasing the risk of credential stuffing and lateral compromise. If one SaaS provider is breached and hashes are cracked, the same password allows access to all other applications, including sensitive corporate data. This approach also violates the principle of least privilege and does nothing to address centralized authentication or account lifecycle management.

Disabling MFA so the sign-in process is faster.

Why wrong: Disabling MFA is not only unnecessary for achieving single sign-on, but actively undermines security. SSO centralizes authentication at the identity provider, so an attacker who obtains a user's password gains access to every federated application at once. Keeping MFA enabled adds a strong, second-factor verification at the corporate IdP, protecting all downstream SaaS services from a single weak point without degrading the user experience.