Recap and final exam
Ten modules took a demand-forecast idea from an empty resource group to a monitored, scheduled, cost-tagged production system. Here is the course in one page, then the threads that run through it, then what to expect from the exam.
The course at a glance
| Module | The essential point |
|---|---|
| 1. Workspace and resources | Five services, not one; jobs authenticate as the compute's managed identity, not as you |
| 2. Compute targets | --min-instances 0 is the switch that makes idle time free; low-priority only for eviction-tolerant workloads |
| 3. Data assets and datastores | Datastore says "where", data asset says "which version"; prefer identity-based access |
| 4. Environments and images | Pin every package version, reference by explicit version, never by latest |
| 5. Training jobs and tracking | Command jobs, MLflow auto-log, sweep concurrency capped to cluster max instances |
| 6. AutoML: uses and limits | Wins on new problems and many-small-models; loses when a domain expert already knows |
| 7. Model registry | Register from the run's outputs/model path to inherit lineage; versions immutable, state on tags |
| 8. Online and batch endpoints | Endpoint = URL, deployment = model+compute; MLflow models deploy scoring-script-free |
| 9. Pipelines and scheduling | Compose small reusable components; register-if-better turns weekly training into MLOps |
| 10. Monitoring, quotas, costs | Model drift, App Insights, cores quota per region, tags + budgets, auto-shutdown for instances |
Threads that run through the course
Everything is a job, and every job runs somewhere. Training, AutoML, batch scoring, monitoring — every action in Azure ML v2 is a submitted job with an explicit compute target. Once you internalise that, the same debugging habits work everywhere: check the compute, check the environment, check the input paths, check the identity.
Identity is the reason things fail with a 403. The workspace does not run your job; a compute cluster does, under its own managed identity. That identity needs its own role on every storage account, every Key Vault, every registry it touches. When the notebook can read the data and the job cannot, the answer is always the same: it is a different identity now.
Versioning is a contract, not a nicety. Data assets, environments, models and components all carry immutable versions. A job that referenced sales-2y:1, forecast-env:3 and train_forecast_lgbm:3 in September will reproduce identically in December, whatever anyone else did in between. The moment a spec references @latest or an environment without a version, that contract silently breaks.
Endpoint and deployment are two distinct objects, and that is the whole point. A stable URL for clients; interchangeable model-plus-compute deployments behind it. Blue-green rollouts, traffic splits, symmetric rollback — none of it works if the endpoint and the deployment are collapsed. This is the single biggest architectural mistake to avoid.
The final exam
The exam has 40 questions covering the ten modules: workspace layout and RBAC, choosing a compute target and reading a quota, registering the right kind of data asset with the right access pattern, freezing an environment and reading a failed build, launching a command or sweep job with MLflow tracking, deciding when AutoML is the honest choice, registering a model with lineage, deploying online with traffic splits and batch on a cluster, composing components into a scheduled pipeline, and reading the drift, latency and cost signals of the whole thing.
Several questions present situations to diagnose: an endpoint that returns 200 but with a KeyError in the JSON, a cluster that never scales because of quota, a training job that reproduces yesterday's numbers but not last month's, a nightly bill that quadruples for no visible reason. It is judgment that is assessed, not the recitation of az ml flags.
Placing Azure ML on the cloud-ML map
The same problems appear on every major platform under different names. Knowing the mapping saves confusion when a team is bilingual across clouds:
| Concept | Azure ML | AWS SageMaker | GCP Vertex AI |
|---|---|---|---|
| Managed workspace | Workspace | Studio Domain | Workbench |
| Auto-scaling cluster | Compute cluster | Training instance pool | Training pool |
| Versioned data | Data asset | Dataset (limited) | Managed Dataset |
| Reproducible env | Environment (image + conda) | Docker image | Container image |
| Experiment tracking | MLflow (native) | Experiments | Experiments |
| Model registry | Model registry | SageMaker Model Registry | Model Registry |
| Managed online serving | Online endpoint | Endpoint + variants | Online Endpoint |
| Batch scoring | Batch endpoint | Batch Transform | Batch Prediction |
| Pipelines | Azure ML Pipelines | SageMaker Pipelines | Vertex Pipelines |
The abstractions are the same; the syntax and the quota systems differ. Course 21 covers SageMaker's version of these ideas in detail, Course 23 does the same for Vertex AI.
Before you start the exam
Take the table above and, for each row, ask yourself "how would I catch myself getting this wrong in production?". If you can explain why a compute cluster with min-instances 1 costs an order of magnitude more than one with min-instances 0, what identity a job authenticates as, and why environment: azureml:forecast-env without a version is a landmine, you are ready. On success, your certificate of completion is issued immediately and its number is verifiable on the platform. Good luck.
Final exam
Ready to validate this course?
40 questions drawn at random from the course bank · passing score 70% · verifiable PDF certificate issued immediately on success.
Start the examYou need to be signed in to your InSkillML account with an active subscription. You can also start the exam from My courses.