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 (a reading device for the three subtopics, not the neural-network sense of layer you will meet under deep learning), and the AI-900 questions reward keeping them straight. The first layer is the technique families (ml-techniques): given a described scenario, name whether the job predicts a number (regression), predicts a category (classification), groups look-alike records that carry no answers (clustering), or stacks many-layered neural networks (deep learning), and whether the past data already carries the answers (supervised) or does not (unsupervised). The second layer is the mechanics shared by every supervised technique (ml-core-concepts): features versus label, building the model versus using it (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): three ways to author a model plus the platform services that feed, store, serve, and govern the result, so the workspace, automated ML, the designer, compute, data assets, endpoints, the model registry, and the Responsible AI dashboard, among others. A scenario question almost always probes layer one ('what kind of problem is this?'); a vocabulary question probes layer two ('what is a setting chosen before training called, a hyperparameter? what is memorizing the training rows instead of generalizing, 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.