Practice Test #1

Correct answer: B. features. Features are the input data values (columns) that the model uses to learn patterns and make predictions. For example, in a house-price model, square footage, number of bedrooms, and location are features because they influence the predicted price. Why the others are wrong: - A. dependant variables: In most ML terminology, the dependent variable is the target/output you are trying to predict (often synonymous with the label), not the inputs that influence the prediction. - C. identifiers: Identifiers (like CustomerID) uniquely identify records but typically should not be used as predictive inputs because they don’t represent generalizable patterns; they can also introduce data leakage. - D. labels: A label is the known outcome/target value used for training in supervised learning (for example, “price” or “spam/not spam”), not the input values that influence the prediction.

Forecasting housing prices based on historical data is not anomaly detection. The key phrase is “forecasting … based on historical data,” which indicates a time-series forecasting problem: you use past values (and possibly external variables like interest rates, inventory, seasonality) to predict future prices. The objective is to estimate expected future values, not to identify rare deviations. Anomaly detection would instead focus on finding unusual house prices or transactions that deviate from normal patterns (for example, a sale price far above comparable properties, potentially indicating data errors or fraud). In AI-900, forecasting and anomaly detection are distinct workload types: forecasting predicts what will happen; anomaly detection flags what is unusual compared to normal behavior. Therefore, the correct answer is No.

Identifying suspicious sign-ins by looking for deviations from usual patterns is a classic anomaly detection scenario. The goal is to detect rare or unusual events—such as logins from atypical locations, impossible travel (two distant sign-ins in a short time), unusual device fingerprints, abnormal login times, or spikes in failed attempts—relative to a baseline of normal user behavior. This aligns directly with the definition of anomaly detection: finding observations that differ significantly from the majority. It is often used in cybersecurity and fraud detection because anomalies can indicate compromised accounts or malicious activity. This is not primarily forecasting (predicting a future numeric value) or standard classification unless you already have labeled examples of “suspicious” vs. “normal.” Even when classification is used, the underlying concept in the prompt—“deviations from usual patterns”—maps to anomaly detection. Therefore, the correct answer is Yes.

Predicting whether a patient will develop diabetes based on the patient’s medical history is not anomaly detection; it is classification. The output is a discrete label (for example, “will develop diabetes: yes/no”), and the model is trained on historical patient records where the outcome is known. This is a supervised learning task. Anomaly detection would be more appropriate if the goal were to identify unusual patient measurements or rare patterns that deviate from a normal population (for example, detecting abnormal lab results that might indicate an undiagnosed condition). But the prompt is explicitly about predicting a specific outcome (diabetes development), which is a typical binary classification use case. In AI-900, remember: classification predicts categories, regression predicts numbers, forecasting predicts future time-based values, and anomaly detection flags rare deviations. Since the scenario is outcome prediction (yes/no), the correct answer is No.

Correct: E (Reliability and safety). The description emphasizes that AI systems should behave consistently with their intended design, handle unexpected conditions, and resist harmful manipulation. These are classic reliability/safety concerns: robustness, fault tolerance, resilience to adversarial inputs, and safe operation under edge cases. Why others are wrong: - A (Accountability) is about who is responsible and ensuring oversight and governance, not the technical/operational robustness of the model. - B (Fairness) focuses on avoiding discriminatory outcomes across groups. - C (Inclusiveness) focuses on accessibility and ensuring solutions work for people with diverse abilities and needs. - D (Privacy and security) focuses on protecting data and controlling data usage, not primarily on model robustness and safe behavior.

Correct: A (Accountability). The key phrase is that AI decisions “can be overridden by humans.” This is human-in-the-loop governance: ensuring there is appropriate oversight, escalation paths, and the ability for people to intervene when an automated decision is incorrect or inappropriate. Accountability also implies clear ownership for outcomes and processes for auditing and remediation. Why others are wrong: - E (Reliability and safety) is about the system operating safely and robustly, but the explicit requirement for human override maps more directly to accountability and governance. - D (Privacy and security) concerns data protection and consent, not decision override. - B (Fairness) concerns bias and equitable outcomes. - C (Inclusiveness) concerns accessibility and designing for diverse users.

Correct: D (Privacy and security). The description is explicitly about giving consumers information and controls over the collection, use, and storage of their data. That aligns directly with privacy principles (transparency, consent, data minimization, appropriate retention) and security principles (protecting data at rest/in transit, access control). Why others are wrong: - A (Accountability) is about oversight and responsibility for AI outcomes, not user controls over personal data. - E (Reliability and safety) is about robust and safe system behavior. - B (Fairness) is about avoiding biased outcomes. - C (Inclusiveness) is about ensuring the solution is usable and beneficial for people with diverse needs, not data governance.

Examining the values of a confusion matrix is part of model evaluation. A confusion matrix summarizes classification outcomes (true positives, false positives, true negatives, false negatives) on validation/test data, helping you assess performance and calculate metrics like precision and recall. Why not the others: - Feature engineering (A) changes/creates inputs; it doesn’t assess predictions. - Feature selection (B) chooses which inputs to keep. - Model training (E) is the learning/fitting step; the confusion matrix is typically produced after training when scoring a dataset. - Model deployment (C) is packaging and hosting the model for real use (endpoint, container, etc.), not analyzing metrics.

Splitting a date into month, day, and year fields is feature engineering because you are transforming a raw attribute into multiple derived features that may better capture patterns. Many models can’t directly learn useful relationships from a single date string/timestamp, but can learn seasonality (month), day-of-month effects, or year trends when those components are explicitly provided. Why not the others: - Feature selection (B) would be choosing whether to use the date (or derived fields) at all, not performing the split. - Model training (E) is fitting the algorithm after features are prepared. - Model evaluation (D) is measuring performance. - Model deployment (C) is operationalizing the trained model.

Picking temperature and pressure to train a weather model is feature selection. You are deciding which candidate variables (features) to include as inputs to the model. Good feature selection can reduce overfitting, improve generalization, and lower training cost by removing irrelevant or redundant inputs. Why not the others: - Feature engineering (A) would be transforming temperature/pressure (for example, normalizing values, creating rolling averages, or computing pressure change over time). - Model training (E) is the step where the algorithm learns from the selected features. - Model evaluation (D) happens after training to validate performance. - Model deployment (C) is publishing the model for inference (for example, an Azure ML endpoint).