Scenario practice questions

Queue

Why it fails: Queues enforce first-in-first-out ordering, exposing only enqueue and dequeue operations, so no key can address a specific value. They are tempting because they manage ordered processing, and would be correct for scheduling or buffering tasks rather than key-value storage.

Array

Why it fails: Arrays index elements by sequential integer position, so they cannot associate a lookup key with a stored value. They are tempting because they store ordered collections efficiently, and would be correct when sequence and positional access matter rather than key-based retrieval.

List

Why it fails: Lists hold ordered elements accessed by numeric index, not by arbitrary key, so they cannot map keys to values. They are tempting because they store heterogeneous collections flexibly, and would be correct when order and iteration matter rather than keyed lookup.

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.

The computer does not have enough RAM.

Why it fails: Insufficient RAM causes general slowness or swapping, not a crash tied to one specific file. It is tempting because memory exhaustion does crash applications, but the trigger here is file version incompatibility. Adding RAM is correct when large files or many concurrent applications exhaust memory.

The file is corrupted.

Why it fails: A version mismatch, not corruption, is the likely cause: the newer file format cannot be parsed by the older application, so it crashes on open. Corruption is tempting because it also produces crashes, and would be the answer if the file failed in the same version that created it.

The user does not have permission to access the file.

Why it fails: A permissions problem produces an access-denied error, not an application crash, so it does not explain the failure. Permissions would be the likely cause if the user could see the file but received a denial when opening or saving it.

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.

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.

Random order

Why it fails: Stack removal is deterministic: the top element, last pushed, is always removed first. Random removal describes no standard abstract data type; hash tables approximate arbitrary access by key, but a stack's LIFO discipline fixes the order exactly.

First-In-First-Out (FIFO)

Why it fails: FIFO describes a queue, where the earliest enqueued item leaves first. A stack is LIFO, so the most recently pushed call frame returns first, which is why recursion unwinds in reverse call order. Queues suit breadth-first traversal and print spooling.

Based on priority

Why it fails: A stack removes the most recently added item, so priority plays no role in its ordering. Priority queues, such as heaps, order removal by assigned priority, which is the correct structure when tasks must be processed by urgency rather than recency.

Merge

Why it fails: A merge integrates changes from one branch into another; it is the operation performed after development, not the isolated copy. It is tempting because the stem mentions merging back, but the copy created beforehand is the branch.

Commit

Why it fails: A commit records a snapshot of staged changes within a repository, not a separate working copy of the codebase. It is tempting because commits are created on the branch and later merged, but the isolated copy itself is the branch.

Pull request

Why it fails: A pull request is a request to review and integrate committed changes, not the isolated copy itself. It is tempting because merging a branch back typically happens through a pull request, but the copy the developer works in is the branch.

Ring

Why it fails: Ring topology passes data token-style around a single closed loop, so one break or node failure can disrupt the whole segment; a small office sharing files needs a central switch, making star the efficient fit. Ring suits token-passing networks where deterministic access matters.

Bus

Why it fails: A bus topology shares one backbone cable, so a single break or fault disrupts every connected device, and performance degrades as collisions rise with each added node. It suits small, temporary or legacy coaxial networks where cost matters and few devices connect. Here, the building's employees need reliable, scalable file sharing, which a star topology's central switch provides.

Mesh

Why it fails: Mesh requires every node to interconnect directly, so a small office LAN would need cabling or wireless links between all endpoints, multiplying cost and configuration effort for no gain. It is tempting because mesh delivers path redundancy and fault tolerance, making it the right choice for wide-area backbones or networks where a single link failure must not isolate sites.

System testing

Why it fails: System testing verifies the integrated system against specified requirements, typically performed by testers rather than business end users validating usability. It is tempting because it also occurs before go-live, but the accounting staff's requirements-and-usability focus indicates user acceptance testing instead.

Unit testing

Why it fails: Unit testing exercises individual components or modules in isolation, usually by developers, so it cannot assess whether accounting staff find the payroll system usable. It is tempting as a pre-release verification step, yet the scenario describes business users validating the whole system against their requirements.

Integration testing

Why it fails: Integration testing checks interactions between combined modules or interfaces, performed by technical testers rather than end users. It is tempting because the payroll system spans multiple components, but the accounting employees are validating business requirements and usability, which is acceptance testing.

Unit testing

Why it fails: Unit testing exercises one isolated function or method, so it cannot confirm that previously working end-to-end functionality still passes. It tempts because unit tests are the fastest, most granular checks developers rerun constantly, yet the scenario requires re-running existing tests after changes.

System testing

Why it fails: System testing validates the complete integrated application against requirements, typically on a fresh build rather than replaying an existing regression suite. It tempts because it covers the whole e-commerce site end to end, but the stem's purpose of detecting broken prior functionality defines regression testing.

Integration testing

Why it fails: Integration testing verifies interactions between combined modules or services, not re-execution of existing cases after changes. It tempts because integration testing does exercise multiple components together, which suits validating data flow across an e-commerce checkout, but the stem describes regression testing.

JWT

Why it fails: A JWT is a self-contained token carrying signed claims about an identity, typically used for user authentication and authorisation, not as a static service identifier sent on every request. It is tempting because JWTs do travel in HTTP headers, but they encode session or identity claims rather than tracking third-party API usage.

Session ID

Why it fails: A session ID identifies a specific user's server-side session after login, so it is meaningless to a third-party weather service that has no session with the developer's application. It is tempting because session IDs are sent in HTTP headers, but they track user state, not application-level API usage.

OAuth token

Why it fails: An OAuth token is issued after an authorisation grant to access protected resources on a user's behalf; it is not the fixed application identifier a service uses to track and authenticate API calls. It is tempting because OAuth tokens also appear in HTTP headers, but they represent delegated access, not the app's own credential.

Data structure

Why it fails: A data structure is an in-memory arrangement such as an array or tree, not a communication convention. It is tempting because JSON payloads are parsed into structures, but the stem asks for the rules governing interaction between app and service, which is a protocol, not a storage format.

SDLC

Why it fails: The SDLC is a project management framework covering requirements, design, build and maintenance phases. It is tempting because it structures software delivery, but it governs development process, not runtime message exchange. The stem describes HTTP request-response rules, which constitute a protocol.

Algorithm

Why it fails: An algorithm is a finite sequence of computational steps producing a result, such as sorting or searching. It is tempting because apps process JSON via code, but an algorithm performs calculation rather than defining message formats and exchange rules between two systems, which is a protocol's role.

Platform as a Service (PaaS)

Why it fails: PaaS delivers a managed runtime where the provider handles patching, scaling and backups, but the customer still deploys and administers the application and its data. It is tempting because the stem describes managed platform duties, yet the question asks for the model where the provider also operates the application itself.

Software as a Service (SaaS)

Why it fails: SaaS delivers a complete provider-run application to end users, with no customer-visible database service to configure or consume programmatically. It is tempting because the provider manages everything, but SaaS is correct when users simply access finished software rather than building on a managed database platform.

Infrastructure as a Service (IaaS)

Why it fails: IaaS supplies raw compute, storage and networking that the customer still patches, backs up and scales themselves, so the provider's automatic database management contradicts the model. IaaS is tempting because the database runs on provider hardware, but it is correct when the customer needs control of the operating system and middleware.

Data is not altered unexpectedly

Why it fails: Unexpected alteration describes integrity, not confidentiality, which concerns restricting data access to authorised parties. It is tempting because integrity and confidentiality are both CIA triad pillars and are frequently confused, and this wording would be the right answer to a question asking which principle integrity represents.

Systems are accessible when needed

Why it fails: Accessibility when needed describes availability, not confidentiality, which concerns preventing unauthorised disclosure of data. It is tempting because availability is the third CIA triad pillar and the phrasing sounds protective, and it would correctly answer a question asking which principle availability represents.

Ensuring data is backed up regularly

Why it fails: Backups support availability and recovery, not confidentiality, which concerns restricting data access to authorised parties. It is tempting because backups are a recognised security control and sound protective, and regular backup would be the right answer to a question about resilience or availability rather than confidentiality.

60 GHz

Why it fails: 60 GHz suffers severe oxygen absorption and needs near-line-of-sight, so its short range cannot cover a large warehouse. It tempts because the band is uncongested and offers huge throughput, suiting dense short-range links within a single room.

900 MHz

Why it fails: 900 MHz provides low throughput and limited channel capacity, so it cannot support many concurrent devices. It tempts because its long wavelength penetrates walls and travels far, suiting low-bandwidth telemetry across wide outdoor or industrial areas.

2.4 GHz

Why it fails: 2.4 GHz shares spectrum with microwaves, Bluetooth and legacy devices, so interference cannot be minimised in a warehouse. It tempts because its longer range and broad device compatibility suit general-purpose coverage where interference is not the stated constraint.

Consistency

Why it fails: Consistency concerns enforcing declared rules and constraints before and after a transaction, not incomplete writes caused by a mid-transaction crash. Consistency would be the answer if the saved order header violated a foreign key or balance constraint.

Isolation

Why it fails: Isolation governs concurrent transaction interference, not partial writes after a crash. The stem describes an atomicity failure: the header committed while line items did not. Isolation would be the answer if two simultaneous orders corrupted each other's uncommitted reads.

Durability

Why it fails: Durability guarantees committed data survives failure, but here the crash left a partial write, meaning the transaction was not treated as all-or-nothing. Durability would be correct if a committed order vanished after a power loss despite a successful commit acknowledgement.

Primary key

Why it fails: A primary key enforces uniqueness and non-null on its column, but the scenario concerns a non-key required field, which a NOT NULL constraint governs. It tempts because primary keys do reject nulls, yet they apply only to the designated key column, not to arbitrary required fields.

Index

Why it fails: An index speeds up data retrieval and can enforce uniqueness, but it does not require a column to hold a value. It tempts because unique indexes reject duplicates and nulls in some systems, yet the scenario needs a NOT NULL constraint on a non-key required field.

Foreign key

Why it fails: A foreign key enforces referential integrity between tables, requiring the value to match an existing parent key; it does not mandate that a column contain a value. It tempts because foreign keys do restrict inserts, but only when a referenced row is absent, not when a field is simply empty.

Ring topology

Why it fails: A ring topology passes frames node to node around a closed loop, so a single failed device or link breaks the ring and disrupts the whole network unless a dual-ring or bypass mechanism exists. It is tempting because rings give deterministic, orderly access, and it would be correct for token-passing networks such as FDDI.

Bus topology

Why it fails: A bus topology uses a shared backbone cable, so a break in that backbone or its terminators halts all communication, not just the failed device. It is tempting because bus networks are cheap and simple to cable, and it would be correct for a small legacy network where every node taps one common medium.

Mesh topology

Why it fails: A full mesh connects every device directly to every other, with no central switch; each node needs multiple interfaces and links. It is tempting because mesh offers redundant paths and high fault tolerance, and it would be correct where resilience matters more than cabling cost, such as a WAN core.

Integration testing

Why it fails: Integration testing exercises interactions and data flow between two or more combined units, so it requires the very dependencies the stem says are isolated. It is tempting because it sits between unit and system testing, and would be correct when verifying that interfaces between modules pass data correctly.

User acceptance testing

Why it fails: User acceptance testing confirms the delivered system meets business needs and is performed by end users against real-world scenarios, not by a tester checking function return values in isolation. It is tempting as the final sign-off gate, and would be correct when validating fitness for purpose before go-live.

System testing

Why it fails: System testing validates the complete, integrated application against end-to-end requirements, so it cannot isolate individual functions. It is tempting because it is the final verification stage before release, and would be correct when confirming that whole workflows behave as specified across all modules together.

Referential integrity

Why it fails: Referential integrity keeps foreign key values matching existing primary keys in a related table; it cannot restrict a column's numeric range. It would be correct when preventing orphaned child rows, whereas age between 0 and 120 is a domain constraint.

User-defined integrity

Why it fails: User-defined integrity enforces bespoke business rules across rows or tables, not a single column's permitted value range. It would be correct for cross-field rules like salary caps by grade; a column range such as age 0–120 is a domain constraint.

Entity integrity

Why it fails: Entity integrity guarantees each row has a unique, non-null primary key; it says nothing about a column's permitted value range. It would be correct when preventing duplicate or null identifier rows, whereas age between 0 and 120 is a domain constraint.