Operating Systems practice questions

Provide a few-shot example of a valid JSON response in the prompt

Why it fails: A single few-shot example demonstrates format but does not guarantee every response parses as JSON; the model may still emit prose or malformed brackets. Few-shot prompting is the right choice when teaching a task pattern or style, not when downstream systems require guaranteed syntactic validity.

Include a system prompt that says 'You are a helpful coding assistant.'

Why it fails: A persona instruction sets tone and role, not output syntax; it cannot constrain token generation to valid JSON. It is tempting because system prompts do steer behaviour, and this one would be the right choice when the goal is shaping a general assistant's helpfulness rather than enforcing a machine-readable schema.

Use chain-of-thought prompting to have the model reason step-by-step before answering

Why it fails: Chain-of-thought elicits intermediate reasoning tokens, which typically appear in the output and break JSON parsing. It is the right choice when the task needs multi-step arithmetic or logic, not when the requirement is a strictly parseable structured payload.

Explicit consent from all data subjects

Why it fails: Consent is not always required; other legal bases may apply.

Data retention period of at least 10 years

Why it fails: Retention periods vary; no universal 10-year requirement.

Compare the distribution of predictions to the training set

Why it fails: Prediction distribution comparison can indicate shift but is less reliable than performance metrics.

Monitor the model's training loss

Why it fails: Training loss can stay low even if the underlying data distribution changes.

Retrain the model daily on new data

Why it fails: Retraining is a remedy, not a monitoring method for detecting drift.

Encrypt all training data

Why it fails: Encryption is a security measure, not a transparency obligation.

Limit model access to internal employees only

Why it fails: Access control is about security and privacy, not transparency.

Use a different dataset from a similar hospital without checking demographics

Why it fails: Swapping datasets without demographic checks risks importing the same or different bias, leaving the elderly under-triage unresolved. A different hospital's data suits expanding coverage or validating generalisation, but only after auditing representation and label distributions against the target population.

Manually increase the weight of age-related features in the model

Why it fails: Manually upweighting age features amplifies the spurious correlation rather than removing it, pushing predictions further from clinical risk. Feature weighting suits deliberate emphasis of known predictive signals, but here the bias stems from historical data and proxy features that must be rebalanced.

Replace the neural network with a decision tree to simplify decision logic

Why it fails: Swapping the neural network for a decision tree changes the model class, not the training data or labels encoding age-related assumptions, so the learned disparity persists. Decision trees suit scenarios needing interpretable, rule-based logic over tabular data, but bias mitigation requires auditing and rebalancing the dataset or applying fairness constraints.

Cross-validation

Why it fails: Cross-validation is a method to evaluate models, not a cause of bias.

High regularization

Why it fails: Regularization reduces variance, not bias.

Retrieval-Augmented Generation (RAG) with a vector store

Why it fails: RAG retrieves documents from a vector store to ground responses in source content; it provides no mechanism for decomposing goals, sequencing API calls, or reasoning over their outputs. It is tempting because RAG is the right pattern when answers must cite internal knowledge rather than orchestrate external actions.

A single large language model prompt with all instructions

Why it fails: A single prompt cannot iteratively decompose tasks, invoke external APIs, and reason over returned results across turns; it produces one static completion. It is tempting because a monolithic prompt suffices for straightforward single-shot generation, such as summarising text or answering a self-contained question.

Fine-tuning a model on a dataset of flight, hotel, and rental conversations

Why it fails: Fine-tuning adapts a model's weights to a conversational style or domain, but it adds no mechanism for decomposing tasks, invoking external APIs or reasoning over their results. It tempts when domain-specific tone is the goal. A tool-use or agent pattern provides that orchestration.

Built-in data versioning

Why it fails: Data versioning tracks changes to datasets and embeddings over time, supporting reproducibility and rollback rather than query-time similarity ranking. It is tempting because versioning matters when embeddings are regenerated, but the requirement is retrieving the top 10 nearest neighbours, which depends on vector indexing and distance metrics.

ACID transaction support

Why it fails: ACID transactions guarantee atomic, consistent writes across records, which matters for concurrent updates but not for similarity ranking. It is tempting because transactional integrity sounds essential for production databases, yet top-10 retrieval depends on vector indexing and distance metrics, not on transactional write semantics.

SQL query interface

Why it fails: A SQL interface supports structured filtering and joins, not approximate nearest-neighbour ranking over high-dimensional embeddings. It is tempting because SQL is familiar for querying stored data, but top-10 similarity retrieval depends on vector indexing and distance metrics such as cosine or Euclidean search, which SQL alone does not provide.

Use a separate AI model to audit the primary AI's decisions weekly

Why it fails: Auditing by another model replaces one automated decision with two, leaving no human in the loop, which the EU AI Act's oversight requirement demands. Model-based auditing suits ongoing quality assurance and drift detection, not the human review of individual high-risk decisions.

Allow applicants to appeal AI decisions through a customer service process

Why it fails: Appeals occur after an adverse decision, so they provide redress rather than oversight of the decision itself; the EU AI Act requires human oversight during operation, such as a human reviewing or overriding outputs before they take effect. Appeals suit post-hoc dispute resolution, not real-time control of a high-risk system.

Provide a dashboard showing the AI's confidence score for each application

Why it fails: A confidence score display leaves the reviewer as a passive observer; the AI still decides, so no human can genuinely intervene. Dashboards suit monitoring model performance over time, whereas oversight requires a person to review evidence and authorise or override each decision.

Association rule mining

Why it fails: Association rule mining discovers co-occurrence patterns in transactional baskets; it does not factorise a sparse user-item matrix into latent user and item vectors. It is tempting because both mine implicit preference data, but it would be correct for market-basket analysis such as "customers who bought X also bought Y".

k-nearest neighbors

Why it fails: k-nearest neighbors computes similarity directly on the sparse user-item matrix, so distances between users with few overlapping ratings become unreliable and accuracy degrades. It is tempting because it is a collaborative filtering method, but it would be correct on dense rating data where neighbourhood similarity is meaningful.

Content-based filtering

Why it fails: Content-based filtering recommends by matching item attributes to a user's own profile, ignoring other users' ratings entirely, so it cannot exploit the collaborative signal the sparse matrix encodes. It is tempting because it handles new items well, but it would be correct when item metadata is rich and interaction data is scarce.

Load testing the web server

Why it fails: Load testing measures web server throughput and concurrency, not recommendation quality. It is tempting because production traffic volumes matter, but the question asks which testing validates the AI system itself, so relevance ranking, bias and drift testing are the applicable types.

Integration tests for API calls

Why it fails: Integration tests for API calls verify that services exchange requests and responses correctly, not that recommendations are accurate or unbiased. It is tempting because the system is API-driven, but the question asks which testing validates the AI model itself, so data and model evaluation types are relevant.

Regression testing on the UI

Why it fails: Regression testing on the UI checks that interface elements still render and behave after changes; it exercises no model behaviour. It is tempting because regressions do affect AI products, but the question targets validating the recommendation engine, so model-focused testing such as accuracy and fairness evaluation applies.

Deploying the model on the fastest hardware available

Why it fails: Hardware speed affects training and inference latency, not security posture. It is tempting because performance is a visible engineering concern and faster GPUs are often prioritised in AI projects. Secure development instead demands threat modelling, secure data pipelines, and model validation against poisoning and evasion attacks.

Using homomorphic encryption for all data at rest

Why it fails: Homomorphic encryption protects data during computation, not at rest; applying it universally is impractical and unrelated to SDLC essentials. It is tempting because it is a genuine privacy-enhancing technique for confidential inference. Secure AI development instead requires threat modelling, data provenance controls, and adversarial testing across the lifecycle.

Repudiation

Why it fails: Repudiation concerns denying that an action occurred, typically lacking audit evidence, and does not describe crafted inputs altering model predictions. It is tempting where logging of inference requests is absent, but adversarial example manipulation is Tampering, which covers modifying model behaviour.

Information disclosure

Why it fails: Information disclosure covers exposure of model data, weights or training inputs, not adversarial inputs altering predictions. It is tempting because model extraction and membership inference leak information, but crafted-input manipulation maps to Tampering, which addresses modification of model behaviour.

Spoofing

Why it fails: Spoofing concerns impersonating a legitimate user, device or service, not perturbing classifier outputs. It is tempting because adversarial examples can impersonate a target class, yet STRIDE places manipulation of the model's processing and behaviour under Tampering, which covers the crafted input itself.

Set temperature to 0.0 for all queries

Why it fails: Temperature controls sampling randomness, not instruction hierarchy; a deterministic output still obeys injected text embedded in retrieved documents. It is tempting because low temperature reduces creative drift in factual answering tasks, but it provides no separation between system instructions and untrusted user content.

Allow the model to execute any code from user prompts for flexibility

Why it fails: Arbitrary code execution from prompts hands attackers the execution environment, escalating injection into remote code execution. It is tempting where dynamic tool use or data transformation is required, but that demands sandboxed, allow-listed functions invoked through validated schemas, not unrestricted interpreter access.

It typically has lower inference latency.

Why it fails: Modular pipelines split perception, planning and control into separate stages, so each adds its own inference overhead rather than sharing one network pass, raising latency. It is tempting because modular decomposition genuinely aids debugging, safety certification and component-level testing — the right choice when interpretability and regulatory auditability outweigh end-to-end latency.

It handles novel scenarios better due to joint training.

Why it fails: Modular components are trained separately, so there is no joint training to exploit; each module optimises its own objective. Joint training is the property of end-to-end networks, which is why that approach is selected when large labelled datasets spanning the whole task are available.

It requires less engineering effort.

Why it fails: The modular approach demands more engineering effort, since each stage needs its own model, interface and testing. It is selected when teams require interpretability, regulatory auditability or independent component updates, not to reduce the total build cost.

Using LIME for explanations

Why it fails: LIME explains individual model predictions to developers and auditors; it produces no user-facing label, watermark or disclosure statement. It is tempting because explainability supports accountability, and would be correct where the requirement is interpreting why a model produced a given output rather than declaring AI involvement.

Implementing federated learning

Why it fails: Federated learning trains models across decentralised data without centralising it, addressing privacy and data-residency concerns. It is tempting because it is an AI governance practice, and would be correct where the requirement is keeping training data on-device rather than informing recipients that content is AI-generated.

Publishing a model card

Why it fails: A model card documents a model's intended use, training data and performance for reviewers; it does not mark or label deployed output. It is tempting because it is a recognised transparency artefact, and would be correct where the obligation is disclosing model characteristics to stakeholders rather than flagging AI-generated content.

Implementing differential privacy

Why it fails: Differential privacy adds calibrated noise to outputs to protect individuals in training data; it produces no explanation of a decision. Explainability tooling such as SHAP or LIME addresses the regulatory requirement. Differential privacy would be right when the obligation is privacy protection.

Conducting bias audits

Why it fails: Bias audits measure disparate impact across protected groups, not the reasoning behind an individual automated decision, so they cannot satisfy an explanation mandate. They are tempting because audits are a recognised AI governance control, and would be correct where the regulation targets discriminatory outcomes rather than explainability.

Establishing an AI ethics board

Why it fails: An ethics board sets principles and reviews dilemmas; it does not itself produce the per-decision explanation artefacts the regulation demands. It is tempting because boards do govern AI, and would be right when the requirement is broad policy oversight rather than documented reasoning for each automated outcome.

Model versioning

Why it fails: Model versioning tracks which artefact produced a prediction, aiding audit and rollback, yet it does not itself give an individual an explanation of the decision. It would be the right choice when the requirement is reproducibility of deployed models rather than contestability of outcomes.

Differential privacy

Why it fails: Differential privacy adds statistical noise to protect individual records in the training data; it does not expose the reasoning behind a specific decision. It is tempting because it is a recognised AI governance control, but it would be the right choice when the requirement is privacy preservation rather than contestability.

Data minimization

Why it fails: Data minimisation limits collection and retention of personal data, which supports privacy compliance but provides no mechanism for explaining or challenging an automated outcome. It would be correct where the obligation concerns reducing stored personal data, not the right to question a decision.

Full transparency by publishing the model's source code and training data

Why it fails: Publishing source code and training data is not an EU AI Act requirement for high-risk systems; that obligation concerns GPAI models, not employment screening. High-risk providers must instead implement risk management, technical documentation, logging, human oversight and conformity assessment. Transparency here means informing affected persons, not open-sourcing proprietary models.

Annual third-party audits of the model's energy consumption

Why it fails: Energy-consumption audits address environmental impact, not the EU AI Act's high-risk requirements of risk management, data governance, technical documentation, logging, transparency, human oversight and conformity assessment. It is tempting because sustainability auditing is topical, but it does not satisfy the Act's high-risk obligations.

Obtaining explicit consent from each applicant to process their data

Why it fails: Explicit consent is a GDPR data-processing condition, not an EU AI Act high-risk obligation; the Act instead requires risk management, technical documentation, logging, human oversight and conformity assessment. It is tempting because consent feels protective, but consent alone does not satisfy the high-risk regime.