Recap and final exam
Ten modules to take the fraud-detection red thread from a BigQuery table to a scheduled Vertex AI pipeline serving two model versions and a foundation-model text classifier. Here is the course condensed, and the threads that run through it.
The course at a glance
| Module | The essential point |
|---|---|
| 1. Components and vocabulary | One project per environment, one region, an explicit least-privileged service account |
| 2. Managed notebooks | Workbench with 30-minute idle shutdown is the single most cost-saving setting in the course |
| 3. Cloud Storage and BigQuery | Partition by date, cluster by merchant, and dry-run every non-trivial query to see the dollar cost |
| 4. Custom training | CustomTrainingJob writes to AIP_MODEL_DIR; start CPU-only, add a GPU only when the workload uses it |
| 5. Hyperparameter tuning | Vizier reaches near-optimum in ~1/3 the trials; report metrics via cloudml-hypertune with a stable tag |
| 6. Model Registry | Use parent_model from the second upload; aliases move, versions do not |
| 7. Endpoints and traffic split | min_replica_count=2 for zero-downtime; traffic_split must sum to 100 |
| 8. Batch prediction | 20–30× cheaper than online for equivalent volume; the join key must be present in the input row |
| 9. Vertex AI Pipelines | KFP components + dsl.If gate = a release process, not a script; enable caching in dev |
| 10. Foundation models | Model Garden unifies models under one Vertex surface; prompt length dominates the token bill |
Correspondence with SageMaker and Azure ML
The three hyperscalers offer the same building blocks under different names — a fact that this course, together with courses 21 and 22, makes concrete. The vocabulary map is worth memorising:
| Vertex AI | AWS SageMaker | Azure ML |
|---|---|---|
| Project | AWS account | Workspace |
| Workbench instance | SageMaker Studio Notebook | Compute Instance |
| CustomTrainingJob | Training Job | Command Job |
| HyperparameterTuningJob (Vizier) | Automatic Model Tuning | Sweep Job |
| Model Registry | SageMaker Model Registry | Model Registry |
| Endpoint + DeployedModel | Endpoint + EndpointConfig + Variant | Online Endpoint + Deployment |
| BatchPredictionJob | Batch Transform | Batch Endpoint |
| Vertex AI Pipelines (KFP) | SageMaker Pipelines | Azure ML Pipelines |
| Model Garden | Bedrock | Azure OpenAI + Model Catalog |
The choice between the three is rarely about capability parity — it is about which cloud already carries the organisation's data. Every core pattern of this course (registry with movable aliases, endpoints with traffic split, batch on the same model, pipelines with a promotion gate) has a direct equivalent on both other platforms.
The threads running through the course
Everything is per-second billing and least-privileged access. Two habits — labelled jobs and 30-minute idle shutdown on notebooks — save more money than any accelerator choice. An explicit service account with only the roles the job needs saves more incidents than any monitoring dashboard.
The registry is the pivot. From module 6 onward, every downstream capability — endpoints, batch prediction, pipelines, lineage — reads from and writes to the same catalogue. Skipping the registry ("we deploy straight from GCS") disconnects that graph, and every future question about "which data trained this" becomes archaeology.
Aliases move, versions do not. champion and challenger are the two words the whole promotion story lives on. Endpoints refer to aliases, not versions; the deployment pipeline moves the alias; the version stays immutable forever. This is the pattern that survives ten team members turning over across three years.
Batch and online are two tools, not two options. The endpoint answers the checkout in 100 ms; the batch job scores yesterday's 12 M transactions in 15 minutes for cents. Sending nightly refresh through the endpoint burns money for no reason; sending checkout decisions through batch loses customers.
A pipeline with a gate is a release process. Every module up to 9 is a step; the dsl.If block on PR-AUC in module 9 is what turns those steps into a training pipeline. Without the gate, one bad Monday retrain replaces the champion with something worse and nobody notices for a week.
The final exam
The exam has 40 questions covering the ten modules: setting up a project with the right APIs and service account, choosing a region and a machine, reading BigQuery scan cost, running a CustomTrainingJob and reading its outputs, driving Vizier and reading its trials, versioning a model with aliases and evaluation, deploying two versions on one endpoint with the right autoscaling, choosing batch or online, wiring a KFP pipeline with a deployment gate, and calling a foundation model with a controlled token bill.
Several questions present situations to diagnose: a job that fails with PERMISSION_DENIED, a notebook that races through a $50 query in an afternoon, a registry that has accumulated a hundred sibling models instead of versions, a traffic split that refuses to apply, a pipeline that reuses a stale cached step in production, a foundation-model call whose bill triples because of a padded prompt. It is judgment that is assessed, not the recitation of API names.
On success, your certificate of completion is issued immediately; its number can be verified by anyone on the platform.
Take the table above and, for each row, ask yourself "how would I know I am about to make the wrong choice here?". If you can say when a GPU is the right tool and when it is theatre, when batch beats online and when it does not, and why a challenger deployed at 10 % is safer than a straight promotion — you are ready. 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.