Azure ML Deployment Strategies for Rollback
Short answer
C Use Managed online endpoints with traffic splitting to enable staged rollout and instant rollback, aligning with the need for low operational risk and managed services.
Question
This is a case study. Case studies are not timed separately from other exam sections. You can use as much exam time as you would like to complete each case study. However, there might be additional case studies or other exam sections. Manage your time to ensure that you can complete all the exam sections in the time provided. Pay attention to the Exam Progress at the top of the screen so you have sufficient time to complete any exam sections that follow this case study.
To answer the case study questions, you will need to reference information that is provided in the case. Case studies and associated questions might contain exhibits or other resources that provide more information about the scenario described in the case. Information provided in an individual question does not apply to the other questions in the case study.
A Review Screen will appear at the end of this case study. From the Review Screen, you can review and change your answers before you move to the next exam section. After you leave this case study, you will NOT be able to return to it.
To start the case study
To display the first question in this case study, select the "Next" button. To the left of the question, a menu provides links to information such as business requirements, the existing environment, and problem statements. Please read through all this information before answering any questions. When you are ready to answer a question, select the "Question" button to return to the question.
Background
Fabrikam Inc. is a mid-sized healthcare analytics company that provides population health dashboards and predictive insights to regional hospital systems across the United States. Fabrikam Inc. customers rely on near real time analytics to monitor patient flow, staffing needs, and readmission risks. They use multiple traditional forecasting machine learning models for predictions.
Fabrikam Inc. has an established Microsoft Azure footprint. The company uses Jupyter Notebooks that run on a local server as the primary development environment. The data science team is experiencing scalability, asset management and code management issues with the current development platform. Fabrikam Inc. plans to migrate to a cloud-based development environment to mitigate the issues.
Additionally, the company plans to implement a Retrieval-Augmented Generation (RAG)-based chat application for client support. Leadership requires the application to be developed and deployed with a low operational risk.
Current Environment
Fabrikam Inc. operates a single Azure subscription that has the following components:
• Azure Data Lake Storage Gen2 that contains de-identified clinical and operational datasets
• Azure AI Search indexing curated analytical documents and reference materials
• A small set of Python-based training scripts maintained by data scientists
• Azure OpenAI Service with deployed foundational models
• A Microsoft Foundry resource for building a RAG-based solution
Evaluation data has manually defined expected responses.
The current challenges faced by the data science team include the following:
• Model training jobs are run manually from notebooks.
• Experiment tracking is inconsistent
• Model versions are registered without standardized metadata.
• Deployment is performed manually by data scientists, with limited rollback capability.
• The team has no standardized evaluation process for generative AI outputs.
The environment currently allows public network access. Authentication relies on user accounts rather than managed identities. Compute targets are manually created and shared across experiments. This has led to resource contention during peak usage.
Business Requirements
Fabrikam Inc. has the following business requirements for the modernization initiative:
• Provide a conversational interface that answers analytics questions by using internal documents and datasets.
• Ensure that sensitive healthcare-related data is not exposed outside the Fabrikam Inc. Azure tenant.
• Enable repeatable and auditable model training and deployment processes.
• Support experimentation to compare prompt strategies and fine-tuned models.
• Align the model with the ranked preferences and optimize behavior for the long term.
• Minimize disruption to existing analytics workloads during rollout.
Technical Requirements
To support the business goals, Fabrikam Inc. identifies these technical requirements:
• Use Azure Machine Learning workspaces to centrally manage data assets, models, and environments.
• Implement experiment tracking and model versioning for all training jobs.
• Orchestrate training and evaluation by using pipelines rather than manually running notebooks.
• Deploy traditional machine learning models with support for staged rollout and rollback.
• Improve RAG-based solution output quality.
• Use the existing evaluation datasets that are based on real data with input-output pairs.
• Apply advanced fine-tuning techniques only when prompt engineering is insufficient
Issues and Constraints
Fabrikam Inc. must comply with internal security policies that require the company to restrict network access and avoid long-lived secrets. The data science team has limited Azure DevOps experience, so solutions must favor managed services and automation over custom infrastructure.
Cost predictability is important. Leadership prefers serverless or managed compute options where possible but is willing to approve dedicated compute for stable production workloads.
Problem Statement
Fabrikam Inc. must design and implement an Azure-based AI operations solution that enables reliable training, evaluation, deployment, and iteration of generative AI models. The solution must support experimentation and gradual rollout while ensuring governance, security, and operational stability. The data science and platform teams must collaborate to deliver this solution by using Azure Machine Learning and Microsoft Foundry capabilities.
You need to recommend a solution to address Fabrikam Inc.’s limited rollback capability.
Which deployment approach should you recommend?
Key Takeaways
The trap is choosing complex infrastructure like AKS; the key insight is that AML Managed Online Endpoints natively support traffic splitting for easy rollback, fitting the 'managed service' constraint.
This question addresses how to implement reliable model deployment with rollback capabilities using Azure Machine Learning. The correct approach leverages managed online endpoints with traffic splitting to ensure safe, staged rollouts.
Common mistake: Candidates often choose AKS because it is a common pattern for blue-green deployments, but they miss the critical constraint that Fabrikam prefers managed services due to limited DevOps experience.
Expert Analysis
Managed Online Endpoints with Traffic Splitting
The core problem is the lack of rollback capability for deployed models. Azure Machine Learning (AML) Managed Online Endpoints provide a built-in mechanism for deployment strategies, including traffic splitting. This allows you to route a percentage of traffic to a new model version while keeping the previous version active. If the new version fails validation or performance checks, you can instantly revert all traffic back to the stable version, effectively providing immediate rollback without manual intervention or complex infrastructure management.
Why Other Options Are Incorrect
- A. VM-hosted REST APIs: Deploying to virtual machines requires manual configuration and management of the underlying infrastructure. Rollback would involve manually swapping images or restarting services, which is error-prone and lacks the automated safety nets required by Fabrikam's low operational risk goals.
- B. Azure Kubernetes Service (AKS) with blue-green switching: While AKS supports blue-green deployments, the case study explicitly states that the data science team has limited Azure DevOps experience and solutions must favor managed services over custom infrastructure. Managing Kubernetes clusters adds significant operational overhead, contradicting the requirement for automation and managed compute.
- D. Batch endpoints: Batch endpoints are designed for high-volume, asynchronous inference tasks, not real-time conversational interfaces. They do not support traffic splitting or staged rollouts in the same manner as online endpoints, making them unsuitable for addressing the specific need for controlled, reversible releases of a chat application.
Exam Strategy
Always cross-reference deployment options with the 'constraints' section of the case study. If the scenario mentions limited DevOps experience or a preference for managed services, eliminate options requiring heavy infrastructure management (like VMs or AKS). Look for native platform features like traffic splitting that solve multiple problems (rollout + rollback) simultaneously.
Frequently Asked Questions
What is the difference between online and batch endpoints?
How does traffic splitting help with rollback?
Community Votes
100% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 2 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 2
-
RICHARDALEX007 👍 1 Answered CFabrikam's limited rollback capability is solved by managed online endpoints with traffic splitting (blue/green), giving staged rollout and instant rollback with minimal ops. VM REST APIs (A) and self-managed AKS blue-green (B) add custom infra the team wants to avoid; batch endpoints (D) aren't for real-time rollback.
-
exam_upskill 👍 1 Answered CC. Managed online endpoints with traffic splitting
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.