Refer to the Exhibit Practice Questions

Share the full file by email as Confidential because only the last four digits of the SSN are included.

Why wrong: Last-four SSN data is still sensitive, and the file also contains address, balance, and support notes that require stronger handling.

Label it Public because the contractor needs the information to troubleshoot effectively.

Why wrong: Business convenience does not change the classification of customer data containing personally identifiable and financial details.

Mark it Internal and place it on the shared project drive for easy access.

Why wrong: Internal sharing is too broad for customer records and does not satisfy the minimization and approval requirements shown in the policy.

Increase the backup schedule from nightly to hourly.

Why wrong: More backups help recovery, but they do not detect suspicious file access or exfiltration in real time.

Rename the share to a less obvious name.

Why wrong: Security by obscurity does not detect misuse and does not stop a valid account from accessing files.

Disable SMB signing so the file transfer runs faster.

Why wrong: Disabling signing weakens integrity protections and does not address the core detection gap.

Require users to set a longer password on the email app and keep the current access policy.

Why wrong: A stronger password helps only if the device itself is trustworthy. It does not block rooted, jailbroken, or outdated devices from connecting to the mailbox.

Disable email on all mobile devices and force users to use desktop computers only.

Why wrong: This would be unnecessarily disruptive and does not address the actual security gap in a balanced way. The business requirement still needs mobile access with stronger control.

Rely on a remote full factory reset whenever a device is lost or reported stolen.

Why wrong: A full wipe can erase personal data and creates privacy concerns for BYOD. It also does not stop risky devices from connecting before a loss event occurs.

Provide the export because the requester is a manager with a legitimate business relationship to employees.

Why wrong: Being a manager does not automatically authorize access to personal data. The exhibit limits use to specific purposes, and this request falls outside them.

Send the data to the manager if the manager promises not to share it externally.

Why wrong: A verbal promise does not override the stated purpose limitation or the access restriction in the privacy notice. Personal data handling must follow approved business use, not informal assurances.

Store the export in a shared drive so multiple teams can use it for convenience.

Why wrong: Broader storage would increase exposure and violate the limited-access principle in the exhibit. Convenience is not a valid reason to expand access to personal data.

Restore the workstation from backup immediately before preserving any evidence.

Why wrong: Immediate restoration could destroy forensic evidence and does not stop the attacker from continuing lateral movement elsewhere.

Run a vulnerability scan against the subnet to see whether the malware exploited an unpatched service.

Why wrong: That may help later in root cause analysis, but it is not the priority while the compromise is still active.

Notify users to ignore the issue until the next maintenance window because the incident is likely self-limiting.

Why wrong: The logs show ongoing malicious activity, so waiting would increase business impact and spread risk significantly.

Cross-site scripting, because the input is visible in the URL and causes an error.

Why wrong: Cross-site scripting would involve injecting script content that runs in a browser context. The exhibit shows database syntax errors tied to SQL query construction, not script execution in the client.

Broken authentication, because the application returns a 500 error.

Why wrong: Broken authentication involves weaknesses in login, session handling, or credential verification. A server error after crafted search input does not indicate authentication failure, so this is not the best fit.

Insecure deserialization, because the application is parsing attacker-controlled data.

Why wrong: Insecure deserialization usually involves tampered serialized objects leading to code execution or logic abuse. The log here shows direct SQL syntax manipulation, which is a different attack pattern.

Bluetooth pairing abuse

Why wrong: Bluetooth pairing abuse involves short-range device pairing, not duplicate Wi-Fi SSIDs and captive portals.

NFC skimming

Why wrong: NFC skimming targets very close-range contactless communication, such as badges or payment cards. The exhibit is about wireless network access.

DNS poisoning

Why wrong: DNS poisoning manipulates name resolution. The evidence here is a fake wireless access point, not a changed DNS record.

Enable password synchronization so the SaaS app stores the same password as the directory.

Why wrong: Password synchronization still leaves the SaaS app managing credentials instead of trusting the external identity provider.

Create a shared local administrator account for all subsidiary users.

Why wrong: A shared account breaks accountability and does not provide individual user authentication or centralized trust.

Configure MAC address filtering on company laptops to allow portal access.

Why wrong: MAC filtering controls device access, not user authentication, and it cannot provide federated sign-in.

Run a full antivirus scan first and wait for the results before taking any other action.

Why wrong: A scan is useful later, but it does not immediately stop possible spread or attacker activity.

Reboot the laptop to clear the malicious process from memory.

Why wrong: Rebooting can destroy volatile evidence and may not stop persistence mechanisms from reloading afterward.

Reset the user's password and close the ticket after confirming they can log in again.

Why wrong: Changing a password may help if credentials were stolen, but it does not stop the endpoint infection.

Store the passwords in encrypted form so they can be recovered later if needed.

Why wrong: Encryption is reversible, which is not ideal for password storage. If the key is exposed, passwords can be recovered.

Replace the hash with a plain SHA-256 digest because it is modern and widely supported.

Why wrong: A fast general-purpose hash without salt is still vulnerable to offline guessing and precomputed attacks. It is not enough for password storage.

Append the application name to each password before hashing to make the hashes unique.

Why wrong: A fixed application string is not a unique per-user salt. It does not meaningfully prevent identical hashes for identical passwords within the same system.

Keep the current shell command, but add HTML encoding to the response page.

Why wrong: Output encoding helps prevent browser-side issues, but it does not stop command injection on the server.

Increase the web server timeout so the ping utility has more time to complete.

Why wrong: Timeout tuning does not prevent an attacker from appending extra shell commands to the request.

Require users to authenticate before they can access the page.

Why wrong: Authentication may reduce exposure, but it does not correct the underlying unsafe command execution.

Ransomware, because the browser settings changed after installation.

Why wrong: Ransomware would typically encrypt files or display payment demands. A homepage change alone is not enough to indicate ransomware, and the exhibit instead highlights data collection and tracking.

Rootkit, because the endpoint security console detected an unknown process.

Why wrong: A rootkit is designed to hide malware or give persistent privileged access. The exhibit does not mention kernel-level hiding, disabled security tools, or stealthy privilege escalation, so spyware is a better match.

Worm, because the software was installed from an unofficial website.

Why wrong: A worm spreads itself across systems, usually without user installation. Here the user manually installed a suspicious utility, which is more consistent with spyware or bundled adware behavior than worm propagation.

DNSSEC, because it validates DNS records and would stop local address-to-MAC spoofing.

Why wrong: DNSSEC protects DNS data integrity, but this incident is about forged ARP replies on a local subnet. ARP operates below DNS and is used to resolve IP addresses to MAC addresses. DNSSEC would not stop the bad ARP mappings shown in the capture.

Port forwarding, because it can direct traffic to the correct internal host more reliably.

Why wrong: Port forwarding is a routing or NAT convenience mechanism, not a protection against forged Layer 2 address resolution. The problem here is that clients are learning a fake MAC address for the gateway. Forwarding does not validate ARP or stop spoofed replies.

Load balancing, because it would distribute traffic and reduce the impact of connectivity issues.

Why wrong: Load balancing improves availability for services, but it does not detect or prevent ARP poisoning on a local broadcast domain. The exhibit shows hosts being tricked into using the wrong MAC address, which must be addressed with a Layer 2 security control.

Guideline, because it provides flexible advice without requiring enforcement.

Why wrong: Guidelines are optional recommendations. They are useful for advice, but the objective here is to make behavior mandatory and auditable, so a guideline is too weak.

Procedure, because it lists the exact steps the help desk follows.

Why wrong: A procedure explains how a task is performed, but it is not usually the best place to establish organization-wide mandatory approval authority or retention requirements.

Architecture diagram, because it shows where documents are stored.

Why wrong: An architecture diagram can illustrate systems or data flows, but it does not define mandatory business rules, approval authority, or evidence retention requirements.

Deploy immediately because the issue is customer-facing and urgent.

Why wrong: Urgency does not remove the need for basic change controls when the exhibit shows skipped tests and no rollback plan.

Close the ticket after deployment and create a postmortem if users complain.

Why wrong: A post-implementation review is useful, but it cannot replace required pre-release approvals, testing, and rollback planning.

Ask support to warn users that sign-in may fail during the next hour.

Why wrong: Customer communication may help operations, but it does not address the unsafe release process shown in the exhibit.