The full answer
Read the error code the deployment reports, because it tells you which stage failed: building the image, getting compute, downloading the model, or starting your scoring script. Then read the logs for that stage. Most failures are in the last step: a package missing from the environment or an exception in init(). Those are faster to reproduce with a local deployment than with repeated cloud attempts that take many minutes each.
What happens during a deployment
- Azure ML builds a Docker image from the environment (or reuses a cached one).
- It finds VMs for the instances you asked for, within your quota.
- A storage-initializer container downloads the model and code.
- Your container starts, runs
init()in the scoring script, and must pass readiness and liveness probes.
Each stage has its own errors:
| Error | Stage | Usual cause |
|---|---|---|
ImageBuildFailure | Image build | A conda or pip package that does not resolve, registry access in a private network, a build that times out |
OutOfQuota | Compute | Not enough cores in the region (remember the extra 20% kept for upgrades), or a model too large for the VM's disk or memory |
BadArgument | Setup | Model or image cannot be downloaded, missing role assignments |
ResourceNotReady | Your container | score.py fails: missing package, syntax error, exception in init(), or startup slower than the probes allow |
Where to look
# your container's output: import errors and tracebacks from init()
az ml online-deployment get-logs -e my-endpoint -n green -l 200
# the model and code download
az ml online-deployment get-logs -e my-endpoint -n green --container storage-initializer
If get-logs returns nothing, the container never started, which points to the image or the download rather than your code.
Reproduce it locally
Add --local to the create command (or local=True in the SDK). The same deployment runs in Docker on your machine, so a missing package or a bad path fails in seconds and you can iterate. Before that, run the scoring script through the Azure ML inference HTTP server package to test init() and run() with no container at all.
Fixes for common causes
- Missing package: the training environment had it and the inference environment does not. Use one versioned environment for both, or list the inference dependencies explicitly.
- Slow startup: a large model loading in
init()can outlast the probes. Raise the probe timings, use a bigger VM, or make the model smaller. - Slow image builds: build the image once ahead of time, so the deployment only pulls it.
- Quota: request more cores, choose another VM size, or deploy fewer instances.
What interviewers want: the stages of a deployment and which error belongs to each, reading the container and storage-initializer logs, local deployment to debug quickly, and fixing the environment rather than retrying.
Last updated 16 October 2026
Sources