Machine Learning Fundamentals

Assuming only the general notion that machine learning learns from data, this domain leaves you able to name a scenario's technique, explain its shared mechanics, and pick the Azure tool that runs it. It is built as three layers that stack on each other, and the AI-900 questions reward keeping them straight. The first layer is the technique families (ml-techniques): given a described scenario, name whether it is regression, classification, clustering, or deep learning, and whether that is supervised or unsupervised. The second layer is the mechanics shared by every supervised technique (ml-core-concepts): features versus label, training versus inferencing, the train/validation split, and evaluation. The third layer is the Azure platform that operationalizes all of the above (azure-ml-service): the workspace, automated ML, the designer, compute, endpoints, and the model registry. A scenario question almost always probes layer one ('what kind of problem is this?'); a vocabulary question probes layer two ('what is a hyperparameter / what is overfitting?'); a tooling question probes layer three ('which Azure ML capability trains many models for me?'). If you can locate a question on the right layer you have usually located the right subtopic.

Across ml-techniques and ml-core-concepts the same hinge keeps reappearing: does each past observation already include the answer you want to predict? If yes, the data is labelled and you are doing supervised learning: regression when that label is a number, classification when it is a category. If no, you have only feature values and you are doing unsupervised learning, whose most common form is clustering, which groups observations by feature similarity with no label to learn from. This one distinction cascades: it decides the technique family, whether a 'label' even exists in the dataset (ml-core-concepts: a label only exists in labelled data), and which evaluation metrics are valid (numeric label means regression metrics like MAE/MSE/RMSE/R-squared; categorical label means classification metrics like accuracy, precision, and recall). Microsoft repeatedly tests the trap that clustering and classification look similar but split exactly here: clustering has no known labels, classification does, and that clustering can be used first to discover groups that later become classification labels.

azure-ml-service ties the techniques and concepts to a concrete platform: a workspace that holds shared notebooks, compute, data assets, and a model registry, and manages the full train-deploy-operate (MLOps) lifecycle. Within it, the same problem can be tackled three ways, and AI-900 wants you to pick by intent. Automated ML (AutoML) is the right choice when you want the service to iterate for you: it trains many candidate models in parallel across different algorithms, featurizations, and hyperparameters and ranks them by the target metric you chose. The designer is the right choice when you want a visual, no-code, repeatable drag-and-drop pipeline you can see and edit. Notebooks with the Python SDK (and the CLI) are the code-first path for full control. A recurring trap is that AutoML and the designer are both no-code, so the deciding factor is intent (let the service search many models = AutoML; build a specific visual pipeline = designer), not coding skill. The iterative model-development loop from ml-core-concepts is exactly what AutoML automates, making this principle the bridge from concept to product.

A theme that runs from ml-core-concepts into azure-ml-service is that a model is only trustworthy if it is judged on data it never saw during training. Labelled data is split into a training subset that fits the function y = f(x) and a held-back validation subset used only to score predictions (y-hat) against the true labels (y); evaluating on the training rows instead is what hides overfitting, where a model memorizes its training data yet fails on new inputs. This is not just theory, it is baked into the platform: AutoML scores every candidate on a validation metric and ranks accordingly, and the Responsible AI dashboard adds error analysis, fairness, and interpretability on top of raw accuracy so a model is debugged before deployment. The practical upshot for the exam: when a question contrasts 'looks accurate on training data' with 'must work on new data', the intended answer involves a validation/held-back set, and when raw accuracy could mislead (for example on imbalanced data) the intended fix is precision and recall.