Hard Difficulty Questions

Define a class named Calculator

Why it fails: Pseudocode is language-agnostic and typically avoids class definitions.

Execute SQL query to retrieve numbers from database

Why it fails: Pseudocode focuses on logic, not database queries.

ON DELETE SET NULL

Why it fails: ON DELETE SET NULL writes NULL into the Enrollments.StudentID column, leaving enrollment rows present but unlinked rather than removed. It is tempting because it preserves child records for optional relationships, which is correct when enrollments should survive a student's deletion with no assigned student.

ON DELETE NO ACTION

Why it fails: ON DELETE NO ACTION raises an error on the parent delete, so enrollment rows are neither removed nor updated, contradicting the automatic-removal policy. It is tempting because it is the default behaviour in many database engines and is correct when deletions must be blocked pending manual cleanup.

ON DELETE RESTRICT

Why it fails: ON DELETE RESTRICT blocks deletion of a parent row while matching child rows exist, so withdrawing a student would fail rather than cascade. It is tempting because RESTRICT is the correct choice when policy demands preventing orphaned enrollments by prohibiting the parent delete outright.

ROM

Why it fails: ROM retains its contents when power is removed, so it is non-volatile and cannot be a volatile memory example. It is tempting because ROM is memory and is often listed alongside RAM, but ROM is the correct answer when a question asks for non-volatile memory examples.

BIOS firmware

Why it fails: BIOS firmware is stored in non-volatile flash or ROM, retaining contents without power, so it is not volatile memory. It is tempting because BIOS runs at startup and interacts with RAM, but firmware is the correct answer when the question asks for non-volatile storage examples.

SSD

Why it fails: An SSD retains data without power, making it non-volatile storage, so it cannot be an example of volatile memory. It is tempting because SSDs are fast and sit close to RAM in the memory hierarchy, but they are correct answers when the question asks for non-volatile storage examples.

Integration testing

Why it fails: Integration testing verifies interactions between combined modules or services, not that previously working features still function after a change. It tempts because deployed applications involve component interfaces, but the stem describes re-running old test cases, which defines regression testing.

Smoke testing

Why it fails: Smoke testing verifies that a build's core functions work before deeper testing, so it confirms stability rather than re-checking previously passing cases. Regression testing is the correct type here, re-running old test cases after changes to catch unintended side effects. Smoke testing would be the right choice on a fresh build before committing to full test execution.

Acceptance testing

Why it fails: Acceptance testing validates that the system meets business and user requirements for release, not that prior functionality survived changes. It tempts because it occurs around deployment, but the described goal — catching unintended side effects — is regression testing's purpose.

The power supply has enough wattage.

Why it fails: NVMe drives draw power through the M.2 slot from the motherboard, so PSU wattage is not the limiting factor. It is tempting because storage upgrades are often assumed to stress the PSU, but the real check is whether the M.2 slot supports PCIe/NVMe rather than SATA-only operation.

The operating system is 64-bit.

Why it fails: A 64-bit OS is irrelevant to whether an M.2 slot supports NVMe; the slot's keying and PCIe lane support determine compatibility. It is tempting because NVMe drivers exist only in 64-bit Windows, but the decisive check is whether the M.2 slot offers PCIe rather than SATA signalling.

The SATA cable is compatible.

Why it fails: NVMe drives use the PCIe bus through the M.2 slot and require no SATA data cable at all, so cable compatibility is irrelevant to this upgrade. It is tempting because SATA SSDs do rely on a SATA data connection, and checking cabling is sensible when swapping that older drive type.

Replace the network cable

Why it fails: The user only visually confirmed the cable is seated; the red X means no link, so the cable and its ports still need testing or substitution. Swapping a cable is right once link negotiation fails on a known-good switch port.

Restart the network share server

Why it fails: The red X shows the user's own link is down, and the technician's successful gateway ping proves the server and network path are reachable, so restarting the server cannot restore a broken local link. Server restarts suit unresponsive services affecting many connected clients.

Disable the firewall on the user's computer

Why it fails: A host firewall cannot produce a red X, which indicates no physical link, and the share is unreachable before any traffic reaches the user's stack. Disabling a firewall suits blocked SMB traffic when the network icon shows a healthy connection.

A vulnerability is a risk, and a threat is a countermeasure.

Why it fails: A vulnerability is a weakness, not a risk, and a threat is a potential cause of harm, not a countermeasure. This option is tempting because risk and countermeasures appear in security discussions, but neither term matches the definitions tested here.

A threat is a weakness in a system, and a vulnerability is an attack that exploits it.

Why it fails: This reverses the definitions: a threat is a potential cause of harm, while a vulnerability is the weakness itself. It is tempting because attacks do exploit weaknesses, but the statement mislabels which term describes the weakness and which describes the attacker or event.

A vulnerability is a potential harm, and a threat is likelihood times impact.

Why it fails: A vulnerability is a weakness, not potential harm, and likelihood times impact defines risk, not threat. The option is tempting because risk calculations feature in security analysis, but it conflates three distinct concepts the question asks you to separate.

Ring

Why it fails: In a ring, each node depends on its neighbours, so one cable or node failure can disrupt the entire loop unless dual rings are used. It tempts because ring topologies offer predictable performance, and would be correct where deterministic throughput matters more than isolating a single cable fault.

Bus

Why it fails: A bus topology shares one backbone, so a single cable break can isolate multiple devices or the whole segment, failing the resilience requirement. It tempts because it is cheap and simple for small offices, and would suit a scenario prioritising low cabling cost over fault isolation.

Mesh

Why it fails: A mesh topology requires each device to maintain multiple direct links to others, creating excessive cabling and configuration overhead for a 20-device network. This fails the stem’s need for easy troubleshooting, as tracing faults across numerous interconnections is cumbersome. The option is tempting because mesh offers high resilience to cable failures, and in a critical data-centre environment where maximum redundancy is essential, it would be the correct choice.

String

Why it fails: A string is a composite sequence of characters, not a primitive scalar in most languages. It is tempting because strings are ubiquitous and often written with literal syntax, but the question targets single-value types such as integer, boolean and float.

Array

Why it fails: An array is a composite aggregate holding multiple elements, not a primitive; primitives store a single value directly. It is tempting because arrays appear in nearly every language, but the question asks for built-in scalar types, not containers.

For loop

Why it fails: A for loop iterates over a known sequence or a fixed number of repetitions, so it cannot keep running until an arbitrary condition becomes true. It is tempting because it handles counted iteration cleanly, and would be the right construct when the number of passes is determined in advance.

If-else statement

Why it fails: An if-else statement evaluates a condition once and branches to one of two paths; it cannot repeat instructions, so it never satisfies "until a condition is met". It is tempting because it handles conditional logic, and would be correct where a single decision between two outcomes is required rather than iteration.

Function definition

Why it fails: A function definition names a reusable block but does not itself repeat execution; iteration requires a loop construct, such as while or for, that re-evaluates a condition. Functions are tempting because they group instructions, and they would be correct where the same logic must be called from several places rather than repeated until a condition is met.

Replace all drives and reconfigure RAID

Why it fails: Replacing every drive destroys the surviving data and parity, forcing a full rebuild from backup and unnecessary downtime. It appeals as a clean-slate fix, yet RAID 5 tolerates one failed member, so only that disk needs swapping and reconstruction.

Simply replace the drive with a larger capacity drive

Why it fails: A larger drive alone does not rebuild the missing parity data; the array stays degraded until the replacement is added and the controller reconstructs parity across all four members. Capacity matching matters because the controller treats the smallest member as the array size, wasting the extra space.

Replace the failed drive and restore from backup

Why it fails: Restoring from backup recovers file data but does not rebuild the RAID 5 parity stripe; redundancy returns only when the controller reconstructs parity onto the replacement drive. Backups suit data loss or corruption, not a single-disk failure where parity already protects the data.

Reinstalling the operating system

Why it fails: Reinstalling the operating system destroys the environment rather than isolating the faulty logic, so it cannot reveal where output diverges. It is tempting as a generic remedy for corrupted system state, and would be justified when the OS itself is unstable or infected, not when code produces wrong results.

Changing the program requirements

Why it fails: Changing requirements alters what the program should do, not how you locate the defect, so it is not a debugging technique. It belongs to requirements gathering or scope negotiation, where stakeholders revise specifications before development begins.

Full disk encryption

Why it fails: Full disk encryption protects data at rest on a device's storage volume, so it does nothing for data crossing a public network. It is the right control when a stolen laptop's drive must remain unreadable, not for protecting traffic in transit.

File encryption

Why it fails: File encryption protects individual files at rest on disk, leaving network traffic unprotected. It is the correct choice when specific stored files need confidentiality, such as on shared storage, not when data is moving across the internet.

HTTPS

Why it fails: HTTPS encrypts web traffic in transit using TLS, but the question asks which encryption method protects data in transit generally; HTTPS is a protocol applying TLS to HTTP rather than the underlying encryption method, so it describes the transport rather than the cryptographic mechanism sought.

Session-based authentication

Why it fails: Session-based authentication issues a server-side session token after an interactive login, so third-party services would need browser-based sign-in rather than a static key. It tempts because tokens accompany subsequent requests, but the stem requires each service to hold its own unique key with no login exchange.

Basic authentication

Why it fails: Basic authentication transmits a base64-encoded username and password pair per request, not a per-service unique key. It tempts because it also sends credentials on every call, but the stem describes API keys issued individually to each third-party service, which is key-based authentication rather than credential replay.

OAuth

Why it fails: OAuth issues short-lived access tokens through an authorisation server and consent flow, not a fixed unique key per third-party service. It tempts because it also authenticates external clients to APIs, but the stem describes static keys embedded in every request, which is API key authentication rather than delegated token issuance.

Disable the Windows Firewall on the server to allow traffic

Why it fails: Disabling the server firewall does not address the client's inability to ping 192.168.1.1, because the client's default gateway points to 192.168.1.10, so its packets never reach the modem. It is tempting because firewalls block traffic, and this would be correct if the server were dropping forwarded packets while routing correctly.

Replace the cable modem as it is not routing traffic correctly

Why it fails: The modem is reachable from the server, proving it routes correctly, so replacing it cannot resolve the client's failed ping to 192.168.1.1. It is tempting because modem faults commonly cause internet outages, and replacement would be correct if the modem were genuinely failing to forward traffic.

Configure the DNS server to forward queries to 8.8.8.8

Why it fails: DNS forwarding to 8.8.8.8 cannot fix the failure, since the client cannot even ping the modem at 192.168.1.1, a layer-3 reachability problem independent of name resolution. It is tempting because DNS misconfiguration commonly breaks internet access, and forwarding would be correct if pings to the gateway succeeded but names failed.

User acceptance testing

Why it fails: User acceptance testing confirms the delivered system meets business needs and is performed by end users near release, long after functions are coded. It is the right choice for validating fitness for purpose against real workflows, not for developers writing function-level tests before implementation.

Integration testing

Why it fails: Integration testing verifies interactions between combined modules or services, so it runs after units exist and cannot be written before the functions themselves. It is the right choice when validating interfaces, data flow and contracts between components, not for test-first development of individual functions.

System testing

Why it fails: System testing exercises the complete integrated application against end-to-end requirements, which necessarily happens once all components are built. It is correct for validating the whole system's behaviour and performance, but writing tests for individual functions before coding them is unit-level, test-first practise.

Commit the changes directly to the main branch

Why it fails: Committing straight to main bypasses the merge step, so the feature branch's history never integrates through review. Direct commits suit trivial hotfixes on solo repositories, whereas collaborative workflows merge the completed branch into main via pull request.

Delete the feature branch without merging

Why it fails: Deleting the branch discards the commits, so the feature never reaches main. Branch deletion is correct only after a successful merge, or when abandoning experimental work entirely; here the completed feature must first be merged.

Push the branch to the remote repository

Why it fails: Pushing publishes the branch to the remote but leaves main unchanged; integration still requires a merge or pull request. Pushing is the right step for sharing work-in-progress or backing up a branch, not for incorporating finished changes into main.

RAID 0

Why it fails: RAID 0 stripes data across all three drives with no parity or mirroring, so any single drive failure loses the entire array. It tempts because it maximises usable capacity and performance, but the stem requires fault tolerance, which RAID 5 provides by distributing parity across the drives.

JBOD

Why it fails: JBOD concatenates all three drives into one logical volume, so any single drive failure destroys the entire array's data — no fault tolerance at all. It is tempting because JBOD maximises usable capacity by pooling every drive, which suits scratch storage or non-critical archives where capacity matters and redundancy does not.

RAID 1

Why it fails: RAID 1 mirrors data across paired drives, so with three identical disks the third sits unused or forms a second mirror, yielding only one drive's usable capacity rather than two. It is tempting because mirroring gives excellent fault tolerance, making RAID 1 the right pick when capacity is secondary to redundancy.

Install antivirus software on all company laptops and personal devices

Why it fails: Antivirus on endpoints scans local files and processes, but the ransomware encrypted the file server, and signature-based detection frequently misses new ransomware variants. It would be correct as a baseline control against known malware on laptops and personal devices, not as the first measure addressing phishing-driven server compromise.

Deploy a next-generation firewall with intrusion prevention

Why it fails: A next-generation firewall inspects network traffic, but the phishing link was clicked by a user and the ransomware executed on the file server, so perimeter inspection does not address the root cause. It would be correct for blocking malicious inbound connections or command-and-control traffic at the network boundary.

Enable full-disk encryption on all company laptops

Why it fails: Full-disk encryption protects data at rest on a stolen laptop; it cannot stop a phishing link executing ransomware on a file server, nor restore lost client data. It would be correct for meeting confidentiality requirements on mobile devices that may be physically lost or stolen.

IaaS

Why it fails: IaaS provides virtual machines and storage; you still manage the OS and applications.

DaaS

Why it fails: DaaS is Desktop as a Service, not email.

PaaS

Why it fails: PaaS provides a platform for application development, not full email service.