Select Two (Multi-Select) Questions

Model pruning to reduce the number of parameters.

Why it fails: Pruning removes redundant weights to shrink the model and speed inference, which does not alter the decision boundaries that adversarial perturbations exploit. It tempts because pruning is a genuine optimisation technique, and would be the right choice when the goal is reducing model size, latency or memory footprint rather than hardening against crafted inputs.

Increasing model complexity to capture more patterns.

Why it fails: Increasing model complexity enlarges the attack surface by introducing more parameters for gradient-based adversarial perturbations to exploit, directly contradicting the security requirement for robustness. This option is tempting because deeper models often improve accuracy on benign data, making it a correct choice for performance optimisation tasks where generalisation, not adversarial defence, is the primary goal.

Hyperparameter optimization using grid search.

Why it fails: Grid search tunes hyperparameters such as learning rate and depth to improve accuracy or convergence, leaving the model equally susceptible to crafted perturbations. It tempts because hyperparameter optimisation is a legitimate part of model development, and would be correct when the objective is maximising predictive performance rather than adversarial robustness.

Gradient masking to hide model gradients

Why it fails: Gradient masking obscures gradients but is defeated by transferability and gradient-free attacks, so it provides no robust guarantee. It is tempting because hiding gradients appears to deny attackers the information they exploit, yet adversarial training and input preprocessing are the defences that actually reduce attack success.

Homomorphic encryption of input images

Why it fails: Homomorphic encryption protects data confidentiality during computation; it does not alter the model's decision surface, so adversarial perturbations still flip predictions. It is tempting because it secures processing of sensitive biometric data, and would be the right control when privacy of outsourced inference is the requirement rather than robustness.

Federated learning to train on distributed data

Why it fails: Federated learning distributes training across data holders for privacy, which does nothing to harden a model against perturbed inputs at inference. It is tempting because it changes the training regime, but adversarial defences require adversarial training or input validation, not a different data-residency architecture.

Ignore the disparity because the model is accurate overall

Why it fails: Ignoring disparity may violate anti-discrimination laws.

Remove all demographic attributes from the dataset

Why it fails: Removing attributes may not eliminate bias due to proxy variables, and can hinder fairness analysis.

Data encryption at rest

Why it fails: Encryption at rest protects stored data from physical theft or unauthorised disk access, but training pipelines read decrypted records into memory, so it does nothing against re-identification, memorisation or inference leakage. It is tempting because it is a genuine privacy control for storage compliance, and would be correct where data at rest is the exposure.

Data replication

Why it fails: Replication copies data to additional stores, multiplying exposure points and retention obligations without removing or masking any personal identifiers. It tempts because replication supports availability and backup, and it would be correct for resilience or disaster recovery — but privacy requires anonymisation, consent management or access controls, not duplication.

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.

Use a smaller learning rate

Why it fails: Smaller learning rate may slow convergence but does not directly regularize the model.

Increase the number of convolutional layers

Why it fails: More layers increase model complexity and typically worsen overfitting.

Kubeflow

Why it fails: Kubeflow is for ML workflows on Kubernetes, not a feature store.

Apache Hive

Why it fails: Hive is a data warehouse infrastructure, not a real-time feature store.

MLflow

Why it fails: MLflow is for experiment tracking and model management, not a feature store.

Normalise the entire dataset before splitting

Why it fails: Normalising before splitting lets statistics from the test partition influence training preprocessing, leaking information and inflating scores. It is tempting because it is convenient. Fitting the scaler on the training split only, then applying it to test, is correct when preprocessing must stay isolated from evaluation data.

Include validation data in the training set for more data

Why it fails: Folding validation data into training removes the held-out partition needed to tune and compare models, so evaluation reflects memorised data. It is tempting when labelled examples are scarce. Keeping validation separate is correct when you need an unbiased estimate of generalisation during model selection.

Use the same split for all experiments

Why it fails: Reusing one split across all experiments leaks test-set information into model selection, so reported performance no longer estimates generalisation. It is tempting because it guarantees comparability between runs, which is legitimate when tuning hyperparameters on a fixed validation split, but a held-out test set must stay untouched.

Pinecone

Why it fails: Pinecone is a vector database, not for general storage or SQL analytics.

pgvector

Why it fails: pgvector is a vector extension for PostgreSQL, not designed for large-scale unstructured storage or SQL analytics alone.

Using a larger learning rate

Why it fails: Larger learning rate can cause divergence; not a regularization technique.

Increasing number of layers

Why it fails: More layers increase model capacity, worsening overfitting.

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.

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.

Training speed

Why it fails: Incorrect; training speed is an efficiency metric, not ethical.

Model accuracy

Why it fails: Incorrect; accuracy is a performance metric, not an ethical consideration.

Model size

Why it fails: Incorrect; model size is a resource consideration, not ethical.

Use one-hot encoding for 'store_id' so every store gets its own binary column.

Why it fails: One-hot encoding a column with several thousand unique values creates thousands of sparse binary columns, which inflates memory, slows training, and forces the model to consider an impractical number of candidate splits. It can also cause overfitting on stores with few observations, and the resulting matrix is awkward for most tree implementations.

Use binary encoding for 'day_of_week' so each day is represented by a binary code across multiple columns.

Why it fails: Binary encoding is designed to compress high-cardinality features, but 'day_of_week' has only seven values, so one-hot encoding is simpler and avoids introducing an artificial numeric structure. Applying binary encoding here adds complexity without meaningful dimensionality reduction and can obscure the clear cyclic meaning of weekdays.

Use label encoding for 'product_category' so categories become arbitrary integers based on alphabetical order.

Why it fails: Assigning arbitrary integers to unordered categories introduces a false ordering that tree models may exploit, producing splits that treat one category as greater than another when no such relationship exists. This can degrade accuracy and make the model's behavior harder to explain, especially for a nominal feature like product category.

Extend the number of training epochs to ensure convergence

Why it fails: More epochs increase total energy consumption.

Increase the model size to achieve better accuracy faster

Why it fails: Larger models require more computation and energy, not less.

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.

Using a smaller batch size

Why it fails: Smaller batch size adds noise but is not a primary regularization technique; dropout and L2 are more effective.

Adding more layers

Why it fails: Adding layers increases model capacity, typically worsening overfitting.

Increasing the learning rate

Why it fails: Increasing learning rate can cause divergence or unstable training, not reduce overfitting.

learning rate

Why it fails: Learning rate is not a hyperparameter for SVM; SVM uses quadratic programming.

epsilon (for epsilon-SVR)

Why it fails: Epsilon is used in SVM regression, not classification.

degree (for polynomial kernel)

Why it fails: Degree is only relevant for polynomial kernel, not RBF.

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.