Recap and final exam
Ten modules to bring the course-20 churn model to a monitored SageMaker endpoint with a budget. Here is the course condensed, then the threads that run through it.
Services by lifecycle stage
| Stage | SageMaker service | Course 20 equivalent |
|---|---|---|
| Interactive work | Studio, notebook instances | Local Jupyter |
| Data storage | S3, Feature Store | Filesystem, custom feature service |
| Training | Training Jobs, built-in containers, script mode | mlflow run, custom scripts |
| Tuning | Automatic Model Tuning (Bayesian) | Optuna, manual grid |
| Real-time serving | Endpoints, autoscaling | FastAPI on Kubernetes |
| Serverless serving | Serverless Inference | Cloud Run, Lambda |
| Batch serving | Batch Transform | Scheduled scoring script |
| Orchestration | Pipelines | Airflow, custom DAG |
| Registry | Model Registry | MLflow Registry |
| Monitoring | Model Monitor, CloudWatch | Prometheus + custom exporter |
| Cost | Budgets, Cost Explorer, tags | Nothing built-in |
The threads running through the course
Everything is a container on a transient instance, billed by the second. Training jobs, tuning jobs, batch transforms and processing steps all follow the same pattern: SageMaker starts a Docker container on the instance you asked for, mounts your data under /opt/ml/input, runs your code, uploads the outputs to S3 and shuts the instance down. Understanding that single lifecycle makes the pricing model predictable and the debugging habits transferable — a bug in a Processing step and a bug in a Batch Transform surface the same way.
The interface between your code and SageMaker is the /opt/ml/* filesystem and a handful of SM_* environment variables. That is what the built-in containers respect, what the framework containers respect, and what you must respect in a fully custom image. Learn those paths once and you never worry about the container flavor again.
Every step of the graph writes to S3, and the next step reads from S3. That is why S3 layout in module 3 matters more than it looked at the time: it is the substrate on which the pipeline moves. A messy raw/, processed/, models/ split turns into a messy DAG the moment you write it in Pipelines.
The choice of endpoint shape is a traffic-pattern decision, not a model decision. Real-time for steady low-latency load, serverless for clumpy sub-4-million-request-per-month workloads that tolerate a cold start, batch for scheduled scoring on large volumes. The same Model object serves all three, and the same inference.py runs in all three; only the deploy call changes.
Monitoring is a training-time decision, not an operations-time one. The data-quality baseline comes from the training set, the ground-truth pipeline that feeds Model Quality must be planned before the model ships. Setting up Model Monitor after a drift incident is the moment you learn that lesson the expensive way.
The final exam
The exam has 40 questions covering the ten modules: IAM roles and the execution-role trap, notebook and kernel cost, S3 layout and Parquet, training jobs with built-ins and with script mode, Spot instances and checkpoints, hyperparameter tuning with Bayesian search and parallelism, real-time versus serverless with cold starts, batch transform sizing and joining, pipelines with condition steps and the registry, Model Monitor and the five causes of a surprise bill.
Several questions present situations to diagnose: a training job failing with AccessDenied on S3, a tuning job whose best trial sits at a boundary of the range, a real-time endpoint whose p99 latency is dominated by cold starts, a monthly invoice with an unexplained $500 line item. It is judgment on the trade-offs that is assessed, not the recitation of API signatures.
On success, your certificate of completion is issued immediately; its number is verifiable by any third party on the platform.
Take the services table above and, for each row, ask yourself "what does it cost per hour, per second or per request?" and "what fails if I forget to configure it?". If you can name the two identities of module 1, the auto-shutdown of module 2, the ninety-percent rule of module 4, the ten-percent parallelism rule of module 6, the cold-start break-even of module 7, the join-source flag of module 8, the else-steps trap of module 9 and the five bill causes of module 10, 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.