Azure DP-100 common mistakes
Azure DP-100 · Understand the traps and how to avoid them.
Chooses a compute instance as the compute target for a long, multi-node training job, or stands up a compute cluster just to open an interactive notebook.
Compute instance, compute cluster and serverless compute all appear in the same Azure ML SDK and portal surface, so candidates memorise that 'compute' is required without absorbing the scaling and lifecycle differences.
What to do instead
Anchor on three facts: compute instance = single-user, always-on development box (set idle shutdown); compute cluster = 0-to-N autoscaling nodes used by jobs and pipelines, with min_nodes=0 to avoid idle cost; serverless compute = no cluster object at all, provisioned per job. Requirements mentioning interactive authoring point to a compute instance; requirements mentioning parallel trials, HPO or pipeline steps point to a compute cluster.
Creates a brand-new datastore for every new version of the training data, or registers a directory of sharded parquet files as a uri_file data asset.
Datastores and data assets are both surfaced as 'where the data lives' in the studio, and the file-versus-folder distinction is a dropdown that nothing validates until the job fails to open the path.
What to do instead
Separate the two roles: a datastore is a reusable connection (plus credential mode) to a storage service; a data asset is a named, versioned pointer to one path inside a datastore. Set the path type from the target itself: a single CSV/JSONL is uri_file; a directory of parquet parts, images or audio is uri_folder. New data snapshots become a new version of the same asset, not a new datastore.
Stores the storage account key or SAS token in a datastore even though the requirement forbids stored credentials, and later assumes the workspace can be renamed or that its key vault / storage / container registry can be swapped in place.
Most quickstart examples create key-based datastores because they are fastest, and the word 'workspace' suggests a mutable container rather than a fixed bundle of dependent resources.
What to do instead
When secrets must not be stored, use a credential-less datastore: no account key, and the workspace's managed identity (or the submitting user's identity) authenticates, so that identity needs Storage Blob Data Reader/Contributor on the account. Treat the workspace name, region and dependent resources as fixed at creation time; to change them, redeploy with an ARM/Bicep template into the target resource group rather than trying to rename or move.
Calls run.log()/run.log_metric() from inside a training script that is submitted as a Command job, or expects mlflow.autolog() to record a custom business KPI.
Local notebook tutorials obtain a Run object with Run.get_context(), and that object is not available inside the child job process; autolog only captures framework-native signals such as loss, accuracy and model files.
What to do instead
In any script executed on a compute target, log with MLflow (mlflow.log_metric, log_param, log_artifact) - the tracking URI is injected automatically, so metrics land on the parent job's run. Turn on mlflow.autolog() only for extra framework metrics, and log custom KPIs explicitly. Read results back afterwards with the SDK run object or mlflow.get_run(run_id).data.metrics.
Submits an AutoML classification job with a regression primary metric (or leaves the default), and combines validation_data with n_cross_validations in the same configuration.
The primary_metric enum is long and task-specific, and the validation settings are separate properties, so the mutual exclusion is invisible in autocomplete and only fails at job validation.
What to do instead
Match metric to task before submitting: classification uses accuracy, AUC_weighted, norm_macro_recall, average_precision_score_weighted; regression uses r2_score, normalized_root_mean_squared_error, normalized_mean_absolute_error, spearman_correlation; forecasting adds its own metric set. Pick exactly one validation strategy - either validation_data (optionally with validation_data_size) or n_cross_validations. Control runtime with timeout_minutes for the whole job and trial_timeout_minutes per trial.
Sets a sweep job's primary_metric to a friendly label that differs from the string the trial script logs (for example 'accuracy' vs 'val_accuracy'), so no run is ever flagged best and early termination never triggers.
goal and primary_metric are resolved by exact string match against logged metric keys at runtime, so nothing catches the mismatch at submission time.
What to do instead
Use the identical metric key in the trial script and in the sweep definition, and set goal (maximize/minimize) consistently. If an early-termination policy is required, remember Bandit uses slack_factor for a ratio and slack_amount for an absolute margin, evaluated every evaluation_interval after delay_evaluation. Do not pair Bayesian sampling with an early-termination policy - that combination is not supported.
Invokes a managed online endpoint that has two deployments without passing deployment_name, or calls a batch endpoint with the same single-record JSON request body used for an online endpoint.
Both endpoint types share the 'endpoint' noun in the SDK and expose similarly named invoke methods, so the request/response contract difference is easy to skip over.
What to do instead
Online endpoints are request/response: a scoring script with init() and run(raw_data) returns JSON immediately, invoked via online_endpoints.invoke(endpoint_name, deployment_name, request_file); with multiple deployments deployment_name is mandatory, and traffic is split with traffic rules. Batch endpoints are long-running file jobs: batch_endpoints.invoke(endpoint_name, input=) scores many files in parallel and writes predictions to an output location - no per-record JSON payload.
Registers an MLflow-trained model as type MLflow, then tries to deploy it with a hand-written scoring script containing init()/run(), or deploys a custom-format model with no scoring script at all.
The model type chosen in the registry does not visibly constrain whether code is required at deployment, and the two deployment paths look interchangeable in the portal.
What to do instead
MLflow-format models (produced by log_model or autolog for scikit-learn, PyTorch, transformers and similar) deploy with no scoring script - Azure ML builds the serving image and the environment must contain mlflow and the training framework. Models registered as custom/default require a scoring script with init() and run(raw_data) returning a JSON-serialisable response, plus an environment that pins the same library versions used at training time.
Recommends fine-tuning a language model so it can answer from an internal document set that is updated weekly.
Fine-tuning reads as 'the way to give a model your data', and the docs present fine-tuning and retrieval augmentation side by side without emphasising that fine-tuning teaches behaviour, not retrievable facts.
What to do instead
Choose retrieval augmentation (embeddings plus a search index, retrieved chunks injected as context) when the need is private or frequently changing knowledge, source citations, or per-user access control. Choose fine-tuning when the need is behaviour: consistent output schema, tone, tool-call syntax, domain phrasing, or shortening prompts. Fine-tuned weights do not reliably retain new facts and require retraining on every content change.
Hardcodes the Azure OpenAI endpoint and key into a prompt flow node instead of referencing a workspace connection, and reports one unqualified 'quality' number from an evaluation flow without matching individual metrics to the requirement.
Prompt flow lets you paste a connection inline and it runs fine locally, and evaluation flows emit several metrics at once, which invites reporting an average rather than the metric the scenario actually constrains.
What to do instead
Create a workspace connection (Azure OpenAI connection type, with the deployment name referenced separately from the model name) and reference it by name in the flow so keys never live in the flow files and the flow is portable across environments. When evaluating, map the requirement to the metric: groundedness for answers supported by retrieved context, relevance for answering the asked question, fluency for language quality, and similarity for closeness to a reference answer - then report the metric that the stated acceptance criterion names.