DP-100 Model Training & Deployment on Azure: Domain Mastery

DP-100 (Designing and Implementing a Data Science Solution on Azure) focuses on using Azure Machine Learning as the central control plane for ML work. In practical terms, the exam tests whether you can take a business problem and implement a repeatable ML solution: preparing data, running experiments, training models, and deploying/operationalizing them with responsible controls.

Use the official skills outline as your “domain map,” then align it to hands-on tasks. A productive way to organize your preparation is by workflow stages:

• Design and prepare: choose Azure ML workspace patterns, manage access (RBAC), select compute types, and structure assets (data, environments, models).
• Explore data and run experiments: use notebooks/SDK/CLI, create datasets or data assets, track runs, log metrics, and compare experiments.
• Train and deploy: use training jobs, pipelines, managed endpoints, batch vs online scoring, model registration, and deployment configuration.
• MLOps and LLM optimization basics: understand responsible deployment and evaluation patterns, plus modern AI app concepts such as Azure OpenAI + Prompt Flow and evaluation workflows where relevant to DP-100.

Common trap: treating Azure ML as optional. Many wrong answers propose “just use a VM” or “just use Azure Databricks” without tying back to Azure ML tracking, model registry, managed endpoints, or reproducibility. Another trap is mixing older terminology with current platform concepts (for example, “datasets” versus newer “data assets” language). If the question emphasizes governance, repeatability, or production deployment, the answer nearly always involves Azure ML assets and managed services.

Exam Tip: When two answers both look plausible, pick the one that improves reproducibility: versioned data, tracked runs, registered models, and managed deployment with authentication.

Plan logistics early so your study time is spent on learning, not paperwork. DP-100 is scheduled through Pearson VUE (online proctored or test center). Create your Microsoft Certification profile, confirm your legal name matches your government ID, and choose the delivery method that best matches your environment and test-taking style.

Online proctoring demands a stable internet connection, a quiet room, and strict desk/room rules. Test centers reduce the risk of connectivity issues but require travel and fixed appointment windows. In either case, you should schedule a date first, then build your study plan backward from it—your calendar creates focus.

If you need accommodations (extra time, assistive technology, etc.), apply as early as possible. Accommodation approval can take time, and you don’t want your intended exam date to slip.

• Verify identification requirements and check-in procedures.
• Understand what items are prohibited (notes, phones, secondary monitors in online sessions).
• Do a system test for online proctoring well before exam day.

Common trap: assuming you can “wing it” with online proctoring. Many candidates lose time to check-in delays or are interrupted for room violations. Treat logistics as part of exam readiness, not an afterthought.

Exam Tip: Schedule your exam at a time when you are consistently alert. Avoid late-night slots; DP-100 requires careful reading and can punish fatigue-driven misreads of requirements like latency, cost, or security.

Microsoft exams typically use a scaled score, and DP-100 is no exception. You do not need a perfect score; you need consistent performance across the skill domains. The exam may include unscored items used for future validation, meaning you must treat every question as if it counts because you won’t know which ones are unscored.

Understand the practical implication of scaled scoring: your goal is to reduce “avoidable misses” (misreading, rushing, skipping constraints) rather than chasing obscure trivia. DP-100 questions often provide multiple technically valid paths; scoring pressure comes from selecting the best fit for the constraints stated.

Retake policies can change, so always confirm current rules on Microsoft Learn and Pearson VUE. In general, you should plan as though you want to pass on the first attempt: retakes cost time, money, and momentum. If you do need a retake, use the score report to target weak domains and re-run labs that map to those tasks.

Common trap: interpreting “passing” as “memorize definitions.” DP-100 grades your ability to apply Azure ML patterns—what to click or code, what resource to choose, and how to secure and operationalize it.

Exam Tip: After each practice session, tag your errors as one of three types: (1) concept gap, (2) Azure feature confusion, (3) careless reading. Then fix them differently: concept review, hands-on lab, or question-reading discipline.

DP-100 commonly uses multiple-choice and multiple-response formats, plus scenario-based sets where several questions share a single business context. The challenge is not only knowing the content, but managing time and cognitive load across long prompts with many constraints.

Train yourself to read like an engineer: extract requirements first, then evaluate options. In Azure ML scenarios, requirements often include one or more of the following: data privacy, lowest operational overhead, reproducibility, cost control, real-time latency, batch throughput, or integration with CI/CD.

• First pass: answer items you can solve quickly and confidently; flag the rest.
• Second pass: return to flagged items and eliminate options using constraints (for example, “must be managed” rules out DIY VM hosting).
• Final pass: review only the highest-impact flags to avoid changing correct answers due to anxiety.

Common traps include “partial compliance” answers. For instance, an option might correctly train a model but ignore tracking and versioning, or it might deploy but fail authentication/authorization requirements. Another classic trap is confusing similar Azure ML compute choices (compute instance vs compute cluster) or endpoint types (online vs batch) when latency and scaling requirements are explicitly stated.

Exam Tip: Circle the constraint words mentally: “must,” “least administrative effort,” “near real-time,” “auditable,” “reproducible,” “private.” Most wrong answers fail one of these—even if they sound technically impressive.

A 2–4 week plan works if you combine three elements: hands-on labs, tight notes, and retrieval practice (active recall). Beginners often overinvest in passive reading. DP-100 punishes passive study because the exam asks you to select implementations, not recite definitions.

Structure your weeks around the workflow: environment setup → data/experiments → training → deployment/MLOps. Each study block should produce an artifact: a run in Azure ML, a registered model, an endpoint deployment, or an evaluation report. For modern AI application coverage, include at least a baseline exposure to Prompt Flow concepts and evaluation patterns so you can recognize them in questions and avoid mixing them up with generic prompt engineering.

• Labs: repeat core tasks until you can do them without instructions: create compute, run training jobs, log metrics, register models, deploy managed endpoints, and update deployments.
• Notes: maintain a “decision table” (when to use compute instance vs cluster; online vs batch endpoint; workspace RBAC basics; where secrets belong).
• Recall: end each session with a 10-minute blank-page recall of steps and reasons (what, where, why).

Spaced repetition matters because Azure ML has many similar nouns. Review your decision table every 2–3 days. As your confidence grows, shorten reading time and increase hands-on repetitions and recall drills.

Exam Tip: Practice explaining your choice out loud: “I choose a managed online endpoint because latency is required and autoscaling reduces ops overhead.” If you can’t justify it, you don’t own it yet.

Your environment should be ready before deep study begins. DP-100 preparation is faster when you can immediately run experiments and deploy endpoints without fighting permissions, quotas, or missing tools. Set up an Azure subscription you control (or a sandbox), then create an Azure Machine Learning workspace in a region with good service availability for your needs.

Use this baseline checklist to avoid common roadblocks:

• Azure account: active subscription, verified billing if required, and awareness of spending limits.
• Workspace: Azure ML workspace created; confirm you can open Azure ML Studio and create resources.
• Access: ensure your user has appropriate RBAC roles for creating compute, storage access, and deployments.
• Compute: create a compute instance for interactive notebooks and a compute cluster for scalable training jobs; check quotas early.
• Data: storage account or data source accessible; understand where data assets will be registered/versioned.
• Tools: install Azure CLI, Azure ML CLI/extension, and Python environment support if working locally; validate authentication with your preferred method.
• Ops basics: know where secrets belong (Key Vault patterns) and avoid hardcoding credentials in notebooks.

Common trap: skipping quota checks. Many candidates lose days because they cannot allocate a GPU SKU or a cluster size in their chosen region. Another trap is using ad-hoc local environments that don’t match Azure ML job environments, leading to “works on my machine” confusion when you submit training runs.

Exam Tip: Aim for “one-click repeatability”: if you can re-run an experiment and redeploy with minimal manual steps, you’re training the exact behaviors DP-100 is designed to validate.

Section 2.1: Define use case, constraints, and success criteria

DP-100 expects you to start with a clear ML problem statement that is anchored to business outcomes and measurable success criteria. Your job is to translate “improve retention” or “reduce fraud” into a well-defined prediction task, identify decision boundaries (what action will be taken from the prediction), and specify what “good” means numerically. In exam scenarios, look for words that imply constraints: “real-time,” “batch,” “regulated,” “explainability,” “limited labels,” “class imbalance,” “seasonality,” or “data drift.” These are signals that your metrics and evaluation approach must be chosen carefully.

Success criteria should include both model metrics and operational metrics. Model metrics might be accuracy, F1, precision/recall at a threshold, AUC, RMSE/MAE, MAPE, BLEU, or human-rated relevance—depending on the task. Operational metrics include latency, throughput, cost per 1,000 predictions, and monitoring thresholds. The exam often rewards specificity: “maximize recall at 95% precision” is more actionable than “maximize accuracy,” especially when false positives have a high cost.

Exam Tip: If the scenario mentions asymmetric risk (for example, missing fraud is worse than flagging legitimate transactions), choose threshold-based metrics (precision/recall, F-beta, PR-AUC) rather than accuracy. Accuracy is a common trap in imbalanced datasets.

Constraints also inform data requirements. If the solution must be explainable for auditors, note that interpretability requirements may shape model choice (for example, linear/logistic regression with feature importance) and logging requirements (store inputs, outputs, and versioned model artifacts). If privacy is emphasized, focus on least-privilege access and avoid copying sensitive data across boundaries without justification. A strong answer set always ties: business goal → ML task → success metric(s) → constraints → Azure ML design choices.

Section 2.2: Choose ML approach (classification/regression/forecasting/NLP)

This objective tests whether you can map the problem statement to the correct ML family and evaluation method. Classification applies when the output is categorical (churn yes/no, risk tier). Regression fits continuous numeric outputs (demand quantity, price). Forecasting is a time-series variant where temporal ordering matters; leakage prevention and time-aware validation are key. NLP and generative AI tasks (summarization, extraction, conversation) often bring different evaluation patterns (offline metrics plus human or rubric-based evaluation) and may include Azure OpenAI or Prompt Flow concepts in later domains—here, you must still select the correct approach based on output type and constraints.

In DP-100 scenarios, the trick is often in the data description. If the dataset includes a timestamp and the question mentions “next week” or “next month,” treat it as forecasting, not generic regression. If the problem is “predict probability of default,” that is classification even though the output is numeric (a probability); the label is typically default/non-default. If the business wants ranked recommendations, you may frame as classification, regression (score prediction), or learning-to-rank, but exam questions typically steer you toward the simplest correct category.

Exam Tip: When you see time-dependent data, ask: “Would random shuffling break reality?” If yes, prefer time-based splits and forecasting-style validation. A random train/test split is a common leakage trap that the exam expects you to avoid.

NLP choice signals include free-text fields, documents, chat logs, or the need to extract entities/sentiment. For classic NLP (classification, extraction), you may use embeddings and classifiers. For generative tasks, evaluation often requires prompt/version tracking and qualitative assessment. The exam frequently checks whether you understand that model choice impacts compute planning: deep learning and LLM fine-tuning/inference typically need GPU; traditional ML often works well on CPU clusters. Tie your ML approach to the next step: what compute, what data prep (tokenization, text cleaning), and what metric is valid.

Section 2.3: Azure ML workspace design: compute, storage, and networking

Azure ML workspace design is a high-yield DP-100 area because many scenario questions ask you to choose resources that support experimentation and production needs. At minimum, a workspace integrates storage for artifacts and data access (often via datastores), compute for notebooks/training/inference, and networking controls. Expect the exam to test trade-offs: speed vs governance, cost vs scalability, and isolation vs ease-of-use.

Compute decisions typically include compute instances (developer workstations for notebooks), compute clusters (scale-out training), and specialized GPU clusters for deep learning. Key signals: “data scientists need interactive notebooks” implies compute instances; “run training jobs on demand” implies clusters with autoscaling; “low cost” implies autoscale-to-zero when idle. Another common decision is whether you need multiple environments or workspaces (for example, dev/test/prod) to match a regulated SDLC.

Storage and data access often involve Azure Storage accounts (Blob/ADLS Gen2) as the source of truth and Azure ML datastores as the workspace abstraction. You should anticipate questions about keeping data in place vs copying it; enterprise scenarios prefer pointing datastores to governed storage (ADLS Gen2) with RBAC and audit controls. Artifact storage for runs, models, and logs is managed by the workspace, but you still must design how datasets are accessed and versioned.

Exam Tip: If the scenario says “no public internet access” or “must stay on private network,” expect to choose private endpoints/private link for the workspace dependencies and restrict outbound. If the scenario emphasizes quick prototyping, public access with RBAC may be the intended answer—don’t over-secure beyond requirements.

Networking choices revolve around whether the workspace and dependent services are reachable over public endpoints or private endpoints, and whether compute resides in a managed VNet or connects to a customer-managed VNet. The exam tests your ability to align networking with compliance statements. Also watch for regional requirements (data residency): choose resources in the required Azure region and avoid cross-region data movement unless explicitly allowed.

Section 2.4: Identity, secrets, RBAC, and responsible data access

DP-100 frequently validates that you understand how Azure ML uses Azure Active Directory identities, role-based access control (RBAC), and Key Vault for secrets management. The exam wants least privilege: give users only the roles they need in the workspace and underlying resources (storage, container registry, key vault). When a scenario mentions “audit,” “regulated,” “segregation of duties,” or “centralized identity,” assume Azure AD + RBAC is mandatory.

Managed identities (system-assigned or user-assigned) are a core pattern for secure access from compute to data without embedding credentials. A typical secure flow: training compute uses a managed identity that has Reader/Storage Blob Data Reader on the data lake; the workspace uses Key Vault for any required secrets; and users authenticate interactively via Azure AD rather than shared keys. The exam often contrasts “access keys/SAS tokens in code” (generally discouraged) with “managed identity + RBAC” (preferred). Choose the latter unless a legacy constraint explicitly requires a token-based approach.

Exam Tip: If an answer option suggests storing secrets in notebooks, environment variables in code, or source control, eliminate it. The exam expects Key Vault integration and managed identity patterns for production-grade designs.

Responsible data access also includes minimizing exposure of sensitive data and controlling who can see what. In practice this can mean separate storage containers for raw vs curated data, controlled datastores, and role separation between data engineers and model developers. If a scenario mentions PII/PHI, your design should reduce data replication and ensure that only authorized identities can access sensitive datasets. While DP-100 is not a full governance exam, it does test whether you can implement secure access patterns that stand up to enterprise requirements.

Section 2.5: Data preparation planning: ingestion, quality, and splits

Data preparation planning appears on DP-100 as both a design and an experimentation capability. The exam expects you to plan how data is ingested (batch vs streaming), validated for quality, transformed into training-ready features, and split correctly for evaluation. A strong plan also considers reproducibility: the same transformations should be applied consistently across training and scoring, typically via pipelines or reusable components rather than ad-hoc notebook steps.

Look for data access patterns in scenarios: “data updated daily” implies an ingestion schedule and incremental processing; “multiple sources” implies joining logic and careful key management; “labels delayed” implies a training window and potential semi-supervised or delayed-supervision handling. Data quality signals include missing values, duplicates, outliers, and schema drift. The exam may not ask you to write code, but it will test whether you know to detect and mitigate these issues before training.

Splitting is a common trap. Random splits are valid for i.i.d. data, but time series requires time-based splits, and entity leakage (same customer appearing in train and test) may require group-based splitting. Also consider stratification for imbalanced classes. For NLP, ensure train/validation/test reflects the same distribution of intents/domains; for LLM prompt-based solutions, ensure evaluation sets include representative user prompts.

Exam Tip: When the scenario includes “future” predictions, events with timestamps, or seasonality, prefer time-aware validation and avoid shuffling. When the scenario includes repeated entities (patients, devices, accounts), consider group splits to prevent leakage.

Feature readiness planning means confirming that every feature used at training time will be available at inference time with the same definition and timeliness. The exam likes designs that avoid “training-serving skew.” If a feature relies on a future value or a batch-only table that won’t be available in real time, redesign the feature or adjust the serving pattern (batch scoring). Align data prep decisions to the deployment expectations stated in the scenario.

Section 2.6: Exam-style practice: design-and-prepare scenarios

In Domain 1 scenarios, your scoring advantage comes from a repeatable decision process. First, identify the ML task and the correct metric family. Second, list explicit constraints (security, latency, cost, region, governance). Third, map those constraints to Azure ML workspace components: compute (instance vs cluster, CPU vs GPU), storage/datasets (datastores pointing to governed storage), and networking (public vs private endpoints, VNet integration). Fourth, validate identity and secrets: Azure AD + RBAC + managed identities + Key Vault. Fifth, confirm a data prep plan that prevents leakage and supports reproducibility.

Many questions are “choose the best next step” even when multiple answers are technically possible. The exam usually prefers the simplest architecture that meets requirements, not the most complex enterprise blueprint. A classic trap is over-optimizing early: adding private networking, custom VNets, and complex governance when the scenario is a proof-of-concept with no stated restrictions. Another trap is ignoring operational constraints: choosing GPU clusters for tabular regression or using real-time endpoints when the scenario clearly describes nightly batch scoring.

Exam Tip: Treat every scenario as a requirements-matching exercise. Underline (mentally) phrases like “must,” “only,” “cannot,” and “within.” If a choice violates any hard constraint, eliminate it—even if it sounds like a best practice.

Also watch for terminology cues the exam uses to test understanding of Azure ML building blocks: “interactive development” points to compute instances and notebooks; “repeatable training” points to pipelines/components; “tracking experiments” implies MLflow-compatible run logging and workspace tracking; “data access without secrets” implies managed identity and RBAC. If you consistently translate cues into the right Azure ML primitives, you will recognize the intended answer pattern and avoid distractors designed to tempt you into generic cloud choices not aligned with Azure ML.

In DP-100 scenarios, Azure ML notebooks are the workbench for exploration, but the exam expects you to connect notebooks to governed assets rather than ad-hoc local files. A common workflow is: attach to an Azure ML compute instance, load data via an Azure ML data asset (or directly from a datastore), perform EDA, and log key findings to the current run so they’re discoverable later.

Practical EDA in Azure ML typically includes: understanding schema, target distribution, missing values, outliers, and basic feature relationships. You should also confirm the split strategy (random vs time-based) matches the problem. If you are using a registered data asset, ensure versioning is part of your workflow so that a colleague can reproduce your notebook results using the same snapshot.

Exam Tip: When the question mentions “reproducibility” or “repeatable experiments,” favor answers that use Azure ML data assets (versioned), managed compute, and MLflow logging—over answers that rely on a local CSV path inside a notebook.

• Use notebooks for interactive checks, but prefer governed inputs (data assets/datastores) for exam-friendly solutions.
• Keep exploration outputs actionable: what you discovered, what you will fix, and what you will monitor.
• Document assumptions: time windows, join keys, label definition, and split methodology.

Common trap: doing EDA on a fully prepared dataset that already includes post-split transformations. On the exam, that’s a hint you may be accidentally inspecting or creating leakage. Another trap is assuming the same preprocessing can be reused across training and scoring without considering training-only operations (like target encoding) that must be fit only on training folds.

Data profiling is the bridge between “I loaded data” and “I can trust it.” DP-100 questions often disguise leakage and validation errors as unexpectedly high metrics, suspiciously stable performance across folds, or a production scoring mismatch. Your job is to detect and prevent these through systematic checks: schema validation, range checks, missingness patterns, and split integrity.

Leakage detection is especially testable. Watch for features that directly encode the label (e.g., a “status=approved” column in a loan default dataset), features computed using future data (time series), and post-event timestamps. Leakage also shows up when preprocessing is fit on the full dataset before splitting, meaning statistics from the test set influence training transformations.

Exam Tip: If a question highlights “time,” “future,” “after the event,” or “too-good-to-be-true accuracy,” your best answer often involves time-based splitting, preventing look-ahead features, and fitting transformers only on training data within each fold.

• Validation checks: schema (types), uniqueness of keys, duplicates, label distribution drift, and outlier bounds.
• Split checks: ensure no entity overlap (e.g., customer IDs in both train/test) when leakage via identity is possible.
• Join checks: confirm 1-to-1 vs 1-to-many joins; inadvertent duplication can inflate performance.

Common trap: focusing only on missing values and ignoring data granularity. Many real leakage issues come from incorrect joins (e.g., aggregations computed across all time) and entity overlap. On the exam, choose answers that explicitly mention preventing leakage through correct split strategy and pipeline-safe preprocessing (fit on train only, apply to validation/test).

Azure ML uses MLflow-compatible tracking to record runs, metrics, parameters, and artifacts. DP-100 expects you to know what to log, why it matters, and how to compare experiments. Metrics (accuracy, AUC, RMSE) answer “how good,” parameters answer “how configured,” and artifacts (plots, confusion matrices, feature importance files, model files) preserve “what was produced.” Lineage ties runs to code, data versions, and compute context, enabling auditing and reproducibility.

In practice, you should log: the dataset or data asset version, feature engineering choices, hyperparameters, evaluation metrics, and key artifacts (like a ROC curve or residual plot). Tags are critical for organization—use them to mark scenario context (baseline vs tuned), data slice (region=west), or model family (xgboost vs logistic). The exam will often ask how to locate the “best run” or compare runs across experiments; the strongest answers emphasize consistent metric names and tags for filtering.

Exam Tip: If the scenario mentions “compare runs,” “audit,” “traceability,” or “reproduce results,” select options that use MLflow/Azure ML run tracking with logged parameters/metrics/artifacts and references to versioned data assets.

• Metrics: numeric values over time or at end of run (loss, AUC).
• Artifacts: files generated by the run (plots, model binaries, reports).
• Lineage: links between run, code, environment, compute, and data versions.
• Tags: searchable metadata to group and filter runs.

Common trap: assuming printing to notebook output is “tracked.” Notebook output is not a substitute for logged metrics/artifacts. Another trap: logging only final metrics and omitting the configuration (parameters and data version). On DP-100, the “right” approach is the one that makes runs comparable and explainable later.

Hyperparameter tuning is often tested conceptually: what you tune, how you search, and how you avoid overfitting to the validation set. Hyperparameters (like learning rate, max depth, regularization strength) are not learned from data in the same way model weights are; they’re set before training and can strongly influence performance and training stability.

Search strategies include grid search (exhaustive but expensive), random search (often more efficient in high-dimensional spaces), and more advanced methods such as Bayesian optimization (guided by previous trials). The exam commonly frames tuning with constraints: limited compute, need for faster iteration, or need to balance performance with cost. In those cases, random search or Bayesian methods are usually favored over full grid search.

Exam Tip: When the question emphasizes “limited budget” or “many hyperparameters,” prefer random search or Bayesian optimization over grid search. When it emphasizes “reproducibility,” mention fixed random seeds and consistent data splits.

• Define a primary metric and ensure it matches the business goal (AUC vs accuracy; RMSE vs MAE).
• Use appropriate validation: cross-validation for small datasets, time-aware validation for time series.
• Track each trial as a run, logging parameters and metrics for comparison.

Common trap: repeatedly tuning on the test set. DP-100 expects correct experimental hygiene: tune on validation (or within cross-validation), then reserve a final untouched test set for unbiased evaluation. Another trap is ignoring early stopping or training instability signals; in many real scenarios, choosing a slightly worse metric with stable training and simpler parameters is operationally better.

Automated ML (AutoML) in Azure ML is a productivity tool, but DP-100 tests whether you can configure it responsibly and interpret outputs. You must specify the task type (classification, regression, forecasting), the target column, the primary metric, the validation strategy, and compute constraints. For forecasting, you also need time column and horizon-related settings. Guardrails matter: set timeouts, max trials, concurrency, and (where appropriate) explainability options.

AutoML outputs are not just “a best model.” Expect artifacts such as the best pipeline/algorithm, run history across featurization and models, metric charts, and sometimes feature importance/explanations depending on configuration. On the exam, you may be asked what AutoML provides for transparency; the correct direction is that AutoML tracks trials as runs and surfaces metrics and configurations so you can compare candidates.

Exam Tip: If a question mentions “interpret results” or “responsible use,” select answers that include reviewing featurization choices, validating split strategy, and examining run details—not blindly deploying the top metric model.

• Key configuration knobs: primary metric, validation type, featurization settings, and compute/time budgets.
• Guardrails: prevent leakage (time splits), limit complexity, and ensure consistent evaluation.
• Outputs to review: best run details, model explainability (when enabled), and training/validation metrics across trials.

Common trap: using random split for time series because it’s the default. Another trap: interpreting AutoML’s “best” as universally best without considering latency, model size, or fairness constraints. DP-100 questions often reward answers that show you checked the evaluation method and constraints rather than trusting the leaderboard.

In Domain 2 practice, you should be able to read a scenario and immediately classify it into: (1) data quality/validation issue, (2) leakage or split problem, (3) insufficient tracking/reproducibility, or (4) experiment design/tuning/AutoML configuration. The exam frequently provides clues like “metric suddenly improved,” “cannot reproduce,” “different results between notebook and pipeline,” or “model fails in production but worked in training.”

To identify correct answers, look for options that add control and traceability: versioned data assets, consistent splits, training-only preprocessing, and MLflow/Azure ML logging. If the question asks what to log, prioritize: parameters, metrics, data version identifiers, and artifacts that help explain model behavior (e.g., confusion matrix). If the question asks how to compare experiments, prioritize consistent metric naming, tags for filtering, and a clear primary metric aligned to the objective.

Exam Tip: When two options both “work,” choose the one that improves governance: lineage to data/code, tracked artifacts, and repeatable compute. DP-100 is as much about engineering discipline as it is about modeling.

• Red flags for leakage: features derived from the label, future timestamps, global preprocessing before split, entity overlap between train/test.
• Red flags for weak experimentation: no run tracking, no data versioning, manual notes instead of logged parameters.
• AutoML decision checks: correct task type, correct metric, correct validation strategy, and budget constraints.

Common trap: treating “EDA completed” as a deliverable. On the exam, EDA must lead to actions: removing/leakage-proofing features, fixing joins, adjusting splits, and recording evidence via tracked experiments. Another trap is optimizing a metric without considering what the metric implies (e.g., accuracy on imbalanced data). Favor answers that mention appropriate metrics (AUC, F1) and validation strategies that match the data generating process.

Section 4.1: Compute targets: clusters, instances, quotas, and cost controls

Azure ML offers two common training compute patterns you must distinguish on the exam: compute instances (single-user dev boxes for interactive work) and compute clusters (autoscaling pools for jobs). Compute instances accelerate iteration for notebooks and debugging, but they are not the best answer for repeatable, scalable training runs. Compute clusters are designed for job submissions, can scale to zero, and align with batch-style training and pipelines.

DP-100 frequently tests your ability to balance speed and cost: choose an appropriate VM family (CPU vs GPU), set min/max nodes, and understand quotas. Quotas are enforced at subscription/region and often cause job failures (e.g., “insufficient quota” for GPUs). You should know that the “fix” is not code—it’s requesting quota, changing region/size, or reducing requested nodes. Cost controls include autoscale settings, low-priority/spot nodes (where appropriate), and setting the cluster minimum to 0 to avoid idle burn.

• Compute instance: best for interactive experimentation, quick iteration, and debugging.
• Compute cluster: best for scheduled or repeated training jobs, parallel runs, and pipelines.
• Quotas: a governance boundary; choose region/VM sizes with available quota.
• Cost control: scale-to-zero, right-size VM, use spot cautiously, limit max nodes.

Common trap: selecting a compute instance for “production training” because it’s easy. The exam typically expects a cluster for training jobs and pipelines. Another trap is forgetting that GPU availability is regional and quota-bound; “use GPU” isn’t sufficient if the region lacks quota.

Exam Tip: If a scenario mentions “many experiments,” “hyperparameter sweeps,” or “nightly retraining,” default to a compute cluster with autoscaling and controlled max nodes. If it mentions “debug in notebook” or “interactive development,” a compute instance is usually correct.

Section 4.2: Environments, dependencies, containers, and reproducibility

Reproducible training is a top DP-100 theme: the same code should produce comparable results when re-run, and the environment should be captured as an asset. Azure ML environments package dependencies (Conda or pip), base images, and runtime configuration. In exam scenarios, using an environment asset beats “pip install in the script” because it’s versioned, reusable, and tied to job runs.

Containerization is a practical consequence: Azure ML builds (or references) a container image to run your training job on remote compute. This is why environment specification matters—missing dependencies, mismatched CUDA versions, or unpinned packages commonly break remote runs even if the notebook worked locally. Pinning versions (e.g., scikit-learn==X.Y) reduces “works on my machine” failures and is an exam-friendly best practice.

Data bindings also affect reproducibility. The exam prefers referencing data assets (registered datasets/data assets) and using job inputs rather than hard-coded paths. This makes runs portable across workspaces/compute. It also ties lineage: which exact dataset version was used for training.

• Use a managed Environment asset rather than ad-hoc installs.
• Pin critical package versions; record CUDA/cuDNN compatibility for GPU training.
• Bind data through inputs (URI file/folder, MLTable) to avoid path brittleness.

Common trap: thinking “Dockerfile” is always required. In Azure ML, you often specify a base image and dependency file; a custom Dockerfile is only needed for advanced customization. Another trap is not aligning the environment with the target compute (GPU packages on CPU compute, or vice versa).

Exam Tip: If the scenario emphasizes auditability or repeatability, choose: environment asset + registered data asset + job inputs. That combination signals “reproducible training” to the exam.

Section 4.3: Training jobs: inputs/outputs, logging, and checkpoints

Azure ML training is centered on jobs. DP-100 expects you to know how jobs consume inputs, write outputs, and emit metrics. The most reliable pattern is: declare named inputs (data, parameters), run a script/command, and write outputs (model files, metrics, artifacts) to declared output paths. This makes artifacts discoverable and traceable in the Azure ML run history.

Logging and tracking are core: metrics (loss, accuracy, AUC) should be logged during training so you can compare runs. The exam may describe a need to “track experiments” or “compare runs” and expects you to use Azure ML’s tracking (run metrics, artifacts) rather than custom print statements or local files. For iteration cycles, you want fast feedback: log intermediate metrics, and persist checkpoints to resume long trainings.

Checkpoints matter when training is expensive or interruption-prone (spot instances, preemption, timeouts). A checkpoint strategy writes periodic model state to an output location so a later run can resume. In orchestration questions, checkpointing is often the difference between “start over” and “continue from last good state,” and the correct answer usually favors durable output storage tied to the run.

• Inputs: declare data and parameters; avoid hard-coded file paths.
• Outputs: write models and artifacts to managed outputs for lineage.
• Metrics/logging: track key metrics for run comparison and selection.
• Checkpoints: persist periodically to handle interruptions and speed retraining.

Common trap: saving model files only to the local working directory on the node without declaring outputs; results can be lost or hard to locate. Another trap is confusing “logging to stdout” with “tracking metrics” that appear in the Azure ML run UI.

Exam Tip: If a question mentions “resume,” “preemptible compute,” or “long training,” look for checkpointing to a run output (or durable store) plus a parameter to load from the latest checkpoint.

Section 4.4: Pipelines: components, reuse, and parameterization

Pipelines are the exam’s preferred answer when you need orchestration: multi-step training, repeatable workflows, or separation of concerns (prep → train → evaluate → register). Azure ML pipelines are built from components, which package a command plus inputs/outputs and an environment. Components promote reuse and enforce clear interfaces—exactly what DP-100 wants for maintainability.

Parameterization is a key concept: pipelines should accept parameters such as learning rate, number of epochs, model type, or data version. Parameterized pipelines support faster iteration cycles and consistent experimentation without editing code. Reuse also shows up as “cache” behavior: when inputs and code haven’t changed, a pipeline can reuse prior step outputs (where enabled), saving time and cost.

In exam scenarios, recognize when a single job is enough versus when a pipeline is warranted. If the requirement includes “run preprocessing and training together,” “schedule retraining,” “reuse a preprocessing step across multiple models,” or “promote to production,” pipelines are typically correct. Pipelines also align with MLOps expectations: each step produces artifacts that can be inspected and traced.

• Components: modular steps with defined inputs/outputs and environment.
• Pipelines: orchestrate steps end-to-end; ideal for repeatability and automation.
• Parameters: adjust behavior without code edits; supports experimentation.
• Reuse/caching: save cost/time by reusing unchanged step results.

Common trap: embedding preprocessing inside the training script “because it’s simpler.” The exam often prefers a separate preprocessing component, especially when multiple models share the same feature engineering. Another trap is forgetting that each component should declare inputs/outputs—otherwise you lose clarity and lineage.

Exam Tip: If the scenario stresses “reusable,” “standardized,” or “team collaboration,” choose components + pipelines. Those keywords are strong signals for the intended design.

Section 4.5: Model registration and versioning strategy

Training is not complete until the model is captured as a managed asset. Azure ML model registration provides a consistent way to store a model artifact with metadata (framework, path, tags), track versions, and connect the model to the run that produced it. DP-100 expects you to treat registration as part of the workflow, not as an afterthought.

A sound versioning strategy usually includes: linking each registered model to the training run, tagging with dataset version and key hyperparameters, and using semantic or incremental versions. The goal is traceability: “Which data and code produced model v12?” In operational scenarios, you may register only models that meet evaluation criteria (e.g., metric threshold) to avoid clutter and accidental promotion of weak candidates.

For exam questions about deployment readiness, registered models are often a prerequisite. If a scenario asks you to “deploy the best model,” the correct flow is: train → evaluate → register the chosen model (with metadata) → deploy. Avoid answers that suggest copying files manually to a web service.

• Register models from job outputs to preserve lineage.
• Tag models with dataset version, metrics, and training parameters.
• Register selectively (e.g., only if metrics pass thresholds).

Common trap: assuming “saving a pickle file” equals model management. The exam favors model registry for governance and repeatable deployment. Another trap is not considering multiple versions—real systems require rollback, A/B testing, and audit trails.

Exam Tip: If the prompt includes “traceability,” “auditing,” “rollback,” or “promote to production,” model registration with versioning and tags is the safest choice.

Section 4.6: Exam-style practice: training and orchestration cases

DP-100 scenario questions often present a symptom (“job fails on cluster,” “runs aren’t comparable,” “retraining is manual”) and ask for the best corrective action. Your job is to map the symptom to the Azure ML construct that fixes the underlying issue: compute target settings for scale/cost, environments for dependency drift, jobs for tracked execution, pipelines for orchestration, and registry for versioning.

Case pattern 1: a notebook works, but remote training fails. The most likely root cause is environment mismatch. The best answer typically introduces a managed environment with pinned dependencies and submits a job to a cluster, rather than continuing to run interactively.

Case pattern 2: training is too slow and expensive. Look for compute cluster autoscaling (min=0, right-size VM), possible GPU selection, and pipeline step reuse so preprocessing isn’t repeated unnecessarily. If the scenario mentions quota errors, the best answer is operational: request quota, change region, or use a different VM SKU—not “optimize code.”

Case pattern 3: results can’t be reproduced or compared. Expect to use job inputs bound to versioned data assets, log metrics to the run, and register models with tags that capture dataset version and hyperparameters.

Case pattern 4: orchestrating a multi-step workflow. The exam expects pipelines composed of reusable components, with parameters for experimentation and a final registration step based on evaluation outputs.

• Debugging signal: “works locally” → environment & dependency capture.
• Cost signal: “idle compute” → autoscale/min nodes; “repeated steps” → caching/reuse.
• Governance signal: “audit/trace” → versioned data assets, run metrics, model registry.
• Automation signal: “schedule/standardize” → pipelines + components.

Exam Tip: When you see a long list of requirements, choose the design that satisfies all of them with Azure ML-native assets. A common DP-100 trap is selecting a partial fix (e.g., just changing compute) when the scenario also demands reproducibility (environment + tracked job) and traceability (registered model + tags).

DP-100 expects you to distinguish the primary Azure ML deployment options and match them to business constraints. Managed online endpoints are the default for real-time inferencing: you deploy a model (often from a registered model or job output) into a managed compute environment and expose an HTTPS scoring route. You typically configure one or more deployments under the endpoint, which enables canary or blue/green strategies by shifting traffic weights.

Batch endpoints are designed for asynchronous scoring at scale. Inputs commonly come from data in storage (e.g., files or tables), the endpoint runs scoring in parallel, and outputs are written back to storage. On the exam, batch is often the correct answer when the scenario emphasizes nightly scoring, backfills, or processing millions of records without user-facing latency requirements.

Legacy or foundational concepts still appear: ACI (Azure Container Instances) is the simplest container runtime used historically for dev/test; AKS (Azure Kubernetes Service) supports advanced, self-managed orchestration. DP-100 questions may reference them to test your understanding of operational overhead: ACI is quick but limited; AKS offers control and scaling but requires cluster management. Azure ML managed online endpoints typically reduce that operational burden.

Exam Tip: If the prompt says “minimize infrastructure management” and “production-grade,” choose managed online endpoints over AKS unless the scenario explicitly requires custom cluster features.

• Online endpoint: interactive, low latency, traffic splitting, autoscale patterns.
• Batch endpoint: high throughput, scheduled, cost-effective for large jobs.
• ACI/AKS basics: recognize tradeoffs, but favor managed options when “managed” is emphasized.

Common trap: selecting AKS because it “sounds enterprise.” The exam often rewards the simplest service that meets requirements, especially when “managed” and “fast time to deploy” are stated.

Deployment is not complete until you can validate predictions and confirm the scoring contract. In Azure ML, your scoring code typically implements an initialization step (load model/artifacts) and a run step (accept request, parse inputs, return outputs). Exam scenarios frequently test whether you know how clients should call the endpoint and what configuration is required for secure access.

Authentication is a frequent objective: endpoints can require a key/token-based mechanism. If the scenario mentions “rotate credentials” or “service-to-service,” focus on endpoint keys and managed identity patterns rather than embedding secrets in code. If the scenario mentions “public access” versus “private,” consider network isolation choices, but keep your answer anchored to the question’s stated control plane requirement (auth vs networking).

Content types matter. Real-time endpoints typically accept JSON payloads; the scoring script must parse the expected schema. The exam can include a subtle trap where the payload is sent as form-encoded data, or the header is missing, causing 415/400 errors. You are expected to recognize that correct Content-Type and schema alignment are essential to successful scoring.

Performance considerations show up as: cold start, concurrency, request size, and throughput. Your initialization should load heavy artifacts once, not on every request. You may be asked which change reduces latency: caching the model in memory during init, batching requests, or scaling instance count. Also know that you can route traffic between deployments to test performance and accuracy without downtime.

Exam Tip: When you see “requests are timing out after deployment,” look for (1) model load in the request path, (2) insufficient compute sizing, or (3) large payloads. The correct answer is often “move model loading to initialization and increase instance resources” rather than “retrain the model.”

Common trap: focusing on model accuracy when the failure is operational (authentication header missing, wrong content type, or scoring script expects a different input field). On DP-100, correctness often means diagnosing the interface contract, not the ML algorithm.

Once deployed, DP-100 Domain 4 emphasizes operationalization: you must monitor health and detect when the model’s environment changes. Start with logs and metrics. Logs help you troubleshoot scoring errors (exceptions in parsing, missing features, dependency issues). Metrics help you observe availability and performance (request count, latency, error rate). A common exam pattern: “endpoint returns 500” or “latency increased”; the best first step is to check logs and recent deployments rather than immediately scaling or retraining.

Beyond infrastructure signals, the exam tests your conceptual understanding of data drift and model drift. Data drift is a change in the distribution of input features compared to training/baseline data. Model drift is a change in predictive performance over time, often driven by data drift, label delay, or changes in the underlying process. Many scenarios ask what to do when drift is detected: you typically investigate, validate with recent labeled data if available, and then decide whether to retrain or adjust the feature pipeline.

Exam Tip: Drift signals are not automatic proof you must retrain. The strongest answer usually includes “investigate the drift, validate impact on business/accuracy, then retrain if degradation is confirmed.”

• Troubleshooting order: logs → request schema/auth → dependency/runtime → scaling/perf tuning.
• Operational metrics: latency, error rates, saturation/CPU, concurrency.
• Drift concepts: input distribution vs performance degradation; label availability affects response.

Common trap: confusing drift with a one-off outage. Drift is a trend over time; a sudden spike of 500s is usually deployment/runtime/configuration. Also watch for questions that mention “no labels available yet”—that points you to data drift monitoring and proxy metrics rather than accuracy-based monitoring.

DP-100 does not require deep DevOps implementation, but it does test whether you understand the MLOps flow: versioning, automation, approvals, and safe release practices. A typical pipeline includes stages to train (or fine-tune), evaluate, register the model, deploy to a test endpoint, run validation, and then promote to production. The exam often frames this as “reduce manual steps” or “ensure repeatability” and expects “use pipelines and automated deployment” rather than ad-hoc notebook clicks.

CI/CD concepts appear as triggers (code change, data change, schedule), artifacts (model, environment, scoring code), and gates (quality checks). An approval gate is appropriate when the scenario requires human sign-off—common in regulated contexts. A rollback pattern maps cleanly to managed endpoints: keep the previous deployment live and shift traffic back if KPIs degrade.

Exam Tip: If a question mentions “minimize downtime” and “validate before full release,” the best-fit strategy is usually blue/green or canary using multiple deployments under one endpoint with weighted traffic.

Also recognize separation of concerns: training compute vs inference compute; dev/test/prod workspaces or environments; and the need to pin dependency versions. Many production incidents are caused by environment drift (different package versions) rather than model weights. On the exam, answers that emphasize reproducibility—tracked runs, registered models, curated environments—tend to be correct.

Common trap: assuming CI/CD is only for application code. DP-100 expects you to treat model + environment + scoring code as deployable assets and to automate promotion with checks, not just training.

DP-100 increasingly includes language-model solution design. You are tested less on memorizing prompt templates and more on selecting an optimization pattern that matches the failure mode: hallucination, irrelevant answers, cost/latency, or domain specificity. Start with prompting: clear instructions, role/task framing, output format constraints (JSON, bullet list), and few-shot examples can improve reliability. If the scenario demands consistent structure, the correct choice often involves stronger formatting constraints and explicit acceptance criteria.

Grounding is the key concept for enterprise use. If the model must answer using internal documents or current product policies, use RAG basics: retrieve relevant passages from a vetted index (e.g., embeddings + vector search), provide them as context, and instruct the model to cite sources and avoid guessing. This reduces hallucinations and improves freshness without full fine-tuning. The exam may try to lure you into “fine-tune the model” when the real need is access to private data and citations; grounding is usually the better first step.

Evaluation is where many candidates underperform. You need a repeatable way to measure quality: curated test sets, rubrics (correctness, groundedness, relevance), and comparisons across prompt variants. Prompt Flow concepts are often used for orchestration and evaluation: run prompts end-to-end, log outputs, and score them with automated or human-in-the-loop checks. If the scenario mentions “regression after prompt change,” evaluation and versioning of prompt assets is the expected response.

Exam Tip: Temperature/top-p changes are tuning knobs, not grounding solutions. If the prompt says “model invents policy details,” choose RAG/grounding and evaluation over lowering temperature alone.

• Prompt optimization: instructions, few-shot, structured outputs, guardrails.
• RAG: retrieval + context + citation instructions; reduces hallucination via evidence.
• Evaluation: test suites, rubrics, A/B comparisons, track prompt versions.

Common trap: treating “better answers” as a single lever. The exam expects you to diagnose the cause (lack of context vs poor instruction vs missing evaluation) and choose the minimal, auditable fix.

This final section consolidates how DP-100 questions are typically written across Domains 3 and 4. They often include extra details to distract you (algorithm names, dataset sizes, “enterprise” wording) while the real objective is selecting the correct deployment/monitoring/LLM pattern. Your job is to identify the constraint words and map them to the right service feature.

For deployment items, underline the time axis and interaction mode: “real-time user requests” points to managed online endpoints; “process files nightly” points to batch endpoints. If the stem emphasizes “validate predictions,” look for steps that include test calls with the correct schema/content type and checking logs for parsing errors. If it emphasizes “safe rollout,” select multiple deployments with weighted traffic and an easy rollback path.

For monitoring items, separate platform health from model health. “5xx errors and timeouts” are operational—logs, metrics, auth, content type, compute sizing. “Accuracy degraded over weeks” is model health—drift investigation, label collection, retraining pipeline triggers, and promotion with gates. If labels are delayed, prioritize data drift and proxy metrics until ground truth arrives.

For LLM optimization items, first classify the failure: hallucination about company facts (choose grounding/RAG + citations), inconsistent format (choose stricter prompting/structured output), or quality regressions after edits (choose evaluation harness and prompt versioning). Cost/latency constraints often imply reducing context size, improving retrieval precision, or caching rather than immediately selecting a larger model.

Exam Tip: When two answers seem plausible, pick the one that is (1) most directly tied to the stated constraint, and (2) lowest operational risk: managed endpoints over self-managed, evaluation/grounding over “try a bigger model,” and traffic-splitting rollback over “redeploy in place.”

Common trap: overfitting your answer to a favorite tool. DP-100 rewards principles: correct endpoint type, correct scoring contract, observability signals, and controlled change management—plus grounded, evaluated LLM behavior for AI apps.

Run this mock like the real DP-100: timed, uninterrupted, and with a strict pacing plan. Your goal is not to “learn while testing” but to surface decision-making gaps under pressure. Use a two-pass strategy. Pass 1: answer what you can confidently within a short time budget per item; flag anything that requires deep reading or calculation. Pass 2: return to flagged items and use elimination, objective mapping, and constraint checking.

DP-100 questions are often scenario-heavy: they hide the real requirement inside details about environment (VNet, private endpoints), governance (RBAC, managed identity), reproducibility (MLflow tracking, registries), or deployment posture (managed online vs. batch vs. AKS). Set a default time box and enforce it. If you find yourself rereading the same paragraph, you are likely missing the “ask” (e.g., “minimize cost,” “no public internet,” “automate retraining,” “deploy within SLA”).

• Pass 1: Read the last line first (what is being asked), then scan for constraints (security, latency, frequency, budget), then choose.
• Pass 2: Validate your choice against constraints and typical Azure ML best practice (managed compute, registries, endpoints, pipelines).
• Final sweep: Check for “most appropriate” vs. “first step” wording; DP-100 heavily tests sequencing.

Exam Tip: When answers look similar, compare them on “operational fit”: managed identity vs. keys, private link vs. public endpoint, pipeline vs. notebook, model registry vs. local artifact. The exam tends to prefer secure, automated, reproducible choices.

Part 1 focuses on end-to-end scenarios: you are given a business goal and an Azure setup, and you must select the correct Azure ML components. Expect frequent cross-domain blending: data access decisions affect training reliability; deployment choices affect monitoring; experimentation affects governance. Your best approach is to translate the scenario into an architecture: (1) data source and access method, (2) compute type, (3) training orchestration, (4) tracking/registry, (5) deployment target, (6) monitoring and iteration loop.

Scenario-heavy DP-100 items often test whether you can choose between Azure ML v2 assets (data, components, environments, models) and older patterns. Look for clues like “repeatable,” “team collaboration,” “CI/CD,” and “promotion to prod”—these point to pipelines, registered assets, and consistent environments. If the scenario emphasizes experimentation or comparing runs, the exam expects MLflow tracking (metrics, parameters, artifacts) and a workspace-centric lifecycle.

Common traps in Part 1 include: selecting an interactive notebook approach when automation is required; confusing managed online endpoints with batch endpoints; and ignoring network isolation requirements. When you see phrases like “must not traverse public internet,” assume private endpoint/VNet integration and managed identity are in play. When you see “scales to zero” or “sporadic traffic,” managed online endpoints and autoscale become relevant. When you see “large backfill scoring,” batch endpoints are typically a better fit than online endpoints.

Exam Tip: For ambiguous choices, favor solutions that (a) use Azure ML managed features, (b) reduce custom plumbing, and (c) preserve lineage: registered data/assets + pipelines + model registry + endpoints with monitoring hooks.

Part 2 shifts to troubleshooting: runs fail, deployments error, metrics look wrong, or access is denied. DP-100 troubleshooting questions reward methodical isolation. Start by identifying the layer: identity/RBAC, networking, environment/dependencies, compute quota, data path, or endpoint configuration. Then ask: “What changed?” and “Where does the error originate?” The exam expects you to recognize which Azure ML artifact to inspect: job logs, run history, endpoint logs, container logs, or data store permissions.

For training failures, typical causes include missing packages in the environment, incorrect conda/docker definitions, incompatible CUDA versions, or insufficient compute size/quota. For data access failures, look for storage permissions, SAS/token misuse, wrong datastore configuration, or missing managed identity roles. For deployment issues, distinguish between scoring script errors (inference code) and infrastructure/provisioning problems (SKU, quota, networking, private DNS). If traffic returns 5xx, think container startup, model load, or dependency mismatch; if you cannot create the endpoint, think permissions, quota, or network policy.

LLM/prompt workflow troubleshooting can appear as evaluation drift or inconsistent results. The exam may test whether you understand repeatable evaluation: fixed datasets, consistent prompts, and measuring quality with automated metrics and human review loops (Prompt Flow concepts). If the issue is “answers vary,” look for temperature/top-p settings; if the issue is “bad grounding,” look for retrieval context and evaluation methodology rather than more training.

Exam Tip: In troubleshooting questions, the correct answer is often the smallest “root cause” lever (RBAC role assignment, environment version pinning, identity configuration) rather than a broad rebuild or redeploy.

Your review process should be structured, not emotional. For each missed item, write down: (1) the objective domain it belongs to, (2) the key constraint you missed, and (3) the pattern of distractors that fooled you. Then map it to the course outcomes: solution design/prep; datasets/experiments/tracking; pipelines/compute/endpoints/MLOps; and Azure OpenAI/Prompt Flow optimization and evaluation concepts.

Use an “evidence checklist” for answer validation. Before accepting an option, confirm it satisfies: security (RBAC/managed identity/private link if stated), reproducibility (registered assets, versioned environments, pipelines), scalability (managed compute/endpoints with autoscale where needed), and operability (monitoring, rollback, model registry, promotion). If an answer does not explicitly support a required constraint, treat it as a distractor even if it sounds plausible.

• Design & preparation: workspace organization, compute planning, networking, identity, data governance.
• Experiments: MLflow logging, run comparisons, datasets/assets, notebooks vs. jobs.
• Training & deployment: pipelines/components, environments, managed online vs. batch endpoints, model registry.
• MLOps & LLM evaluation: automation triggers, monitoring, drift signals, Prompt Flow evaluation discipline.

Exam Tip: Track “why wrong” categories. If most misses are “ignored constraint,” practice extracting constraints first. If most are “feature confusion,” build a one-page mapping of similar services (online vs. batch endpoints; pipeline vs. notebook; AKS vs. managed endpoints).

This cram sheet is about fast recall of what DP-100 repeatedly tests: asset-based workflows, secure access, reproducible training, and correct deployment primitives. Focus on mental models and high-frequency pitfalls rather than rare edge cases.

• Azure ML assets (v2): data, environment, component, model are versioned and reusable; exam prefers these for team workflows.
• Job execution: command jobs + MLflow tracking for parameters/metrics/artifacts; reproducibility comes from pinned environments and consistent inputs.
• Pipelines: use components to compose steps; choose pipelines when the scenario calls for repeatability, scheduling, or CI/CD.
• Compute: pick CPU vs. GPU intentionally; watch quota/region limits; choose managed compute for simplicity unless AKS is explicitly required.
• Deployment primitives: managed online endpoints for low-latency; batch endpoints for large offline scoring; ensure scoring script and environment match.
• Identity & security: managed identity + RBAC beats embedding keys; private endpoints/VNet integration when “no public internet” is stated.
• LLM/prompt evaluation: control randomness (temperature), use fixed eval datasets, measure quality systematically; don’t confuse prompt iteration with model fine-tuning unless asked.

Common traps: choosing a notebook because it is familiar; selecting AKS when managed online endpoints meet requirements; ignoring data lineage and versioning; treating “monitoring” as just application logs instead of also tracking data/model drift signals. Another frequent trap is mixing up “where the model lives” (registry) versus “where it runs” (endpoint/compute).

Exam Tip: If two answers both “work,” the exam usually wants the one that is more governed: versioned assets, automated pipelines, managed deployments, and identity-based access.

Exam day is execution. Your goal is to avoid preventable errors and keep your reasoning consistent from first question to last. Confirm logistics early: testing environment, ID requirements, and permitted materials. Plan your time so you finish with a buffer for flagged questions; the DP-100 format rewards revisiting items with fresh eyes.

Use a calm, repeatable decision routine: read the question ask, extract constraints, classify the objective, eliminate distractors that violate constraints, then choose the most Azure-ML-native managed option. If you feel stuck, it is usually because you are debating two plausible answers—resolve this by finding the hidden requirement (security, automation, cost, latency, reproducibility). Do not over-engineer: if the scenario does not mention Kubernetes needs, do not assume AKS. If it emphasizes “minimal ops,” managed endpoints and pipelines usually win.

• Before starting: remind yourself of endpoint types (online vs. batch), pipeline vs. notebook, and managed identity/RBAC patterns.
• During: flag-and-move; do not donate minutes to a single ambiguous item.
• End: re-check flagged answers for constraint alignment and sequencing words (“first,” “best,” “most secure,” “most cost-effective”).

Exam Tip: Your final pass should be constraint-driven. Many last-minute point gains come from noticing a single phrase like “private,” “scheduled,” “near real time,” or “auditable,” which decisively changes the correct Azure ML feature choice.