11. DataOps, MLOps and Platform EngineeringIntroduction and contextBig data and cloud analytics create value only when data products, analytical pipelines, and machine-learning systems operate reliably after development. A notebook that produces an accurate model, or a dashboard that works on a developer’s laptop, is not yet an operational system. Production systems must ingest changing data, process it within agreed time limits, withstand failures, protect sensitive information, and provide evidence about how outputs were produced. They must also be changed safely as business requirements, software dependencies, models, and cloud infrastructure evolve. DataOps, MLOps, and platform engineering address this operational challenge from related but distinct perspectives. DataOps applies automation, testing, collaboration, and continuous delivery principles to data pipelines and data products. MLOps extends these ideas to the complete machine-learning lifecycle, including experimentation, training, validation, deployment, monitoring, and retraining. Platform engineering creates reusable internal platforms, tools, interfaces, and infrastructure that enable data and AI teams to work productively without independently solving the same operational problems. These disciplines are particularly important in cloud environments. Cloud services make storage and computation elastic, but elasticity does not automatically produce reliability, governance, cost control, or reproducibility. A well-designed operating model connects source control, automated tests, infrastructure as code, artifact management, deployment automation, observability, security, and organizational accountability. Learning objectivesAfter studying this chapter, the learner should be able to: 1. Distinguish DataOps, MLOps, and platform engineering and explain how they interact. 2. Design a versioned and reproducible workflow for data, code, models, and infrastructure. 3. Explain the role of testing, continuous integration, continuous delivery, and deployment strategies. 4. Evaluate model registries, metadata, lineage, monitoring, and observability practices. 5. Apply infrastructure-as-code and platform-engineering principles to cloud analytics. 6. Identify operational, ethical, security, governance, and cost risks. 7. Analyse an applied scenario and recommend an appropriate production operating model. From experimental assets to dependable data productsA data product is an operational output whose quality, availability, and meaning are managed for users. It may be a curated table, feature set, dashboard, recommendation service, forecast, or risk score. Production quality involves more than computational correctness. It includes freshness, completeness, validity, consistency, accessibility, explainability, security, and fitness for purpose. DataOps can be understood as a socio-technical approach to delivering trustworthy data rapidly. It combines data engineering, software engineering, quality assurance, operations, governance, and collaboration. Its central idea is that data pipelines should be treated as continuously maintained products rather than one-time scripts. A pipeline therefore requires ownership, documented interfaces, tests, deployment controls, monitoring, and an incident-response process. MLOps applies the same operational discipline to systems in which learned parameters influence behaviour. A machine-learning system contains more than model code. It includes training data, feature transformations, labels, hyperparameters, dependencies, evaluation procedures, serving code, and business thresholds. Changes to any of these may affect outcomes. MLOps manages this expanded dependency graph and supports controlled movement from experimentation to production. Platform engineering focuses on the paved road: a supported, reusable path that makes the correct operational behaviour easy. An internal data or ML platform may provide project templates, identity integration, container build processes, workflow orchestration, data-quality checks, model registration, deployment patterns, monitoring, and cost reporting. The platform team does not necessarily own every data product. Instead, it supplies capabilities, standards, and self-service interfaces while product teams retain responsibility for their outputs. These disciplines overlap but should not be treated as synonyms. DataOps concentrates on data delivery and quality; MLOps concentrates on the lifecycle and operation of learning systems; platform engineering concentrates on the reusable foundation and developer experience. A mature organization uses all three in a coherent operating model. The versioned chain of reproducibilityReproducibility means that an authorized practitioner can recreate, or at least explain, a result using recorded inputs, code, configuration, and execution conditions. It has several dimensions: - Code reproducibility: source code, dependency versions, and configuration are recorded.
- Data reproducibility: the input data or an immutable reference to it is preserved.
- Environment reproducibility: operating-system libraries, runtimes, containers, and hardware assumptions are known.
- Process reproducibility: transformations, random seeds, training procedures, and evaluation rules are documented.
- Deployment reproducibility: the same artifact can be promoted through environments using controlled configuration.
Git-based source control is normally the starting point for application code, pipeline definitions, infrastructure code, schemas, tests, and documentation. Large data files and model binaries are generally handled through object storage, dataset versioning systems, artifact repositories, or registries rather than ordinary source repositories. The essential principle is not a particular product but the creation of immutable, addressable versions. A useful release record links a source commit, data snapshot, feature definition, model artifact, dependency lockfile, container image, infrastructure version, configuration, test results, approver, and deployment environment. This relationship is often called a provenance graph. It allows a team to answer questions such as: Which data trained this model? Which model generated this prediction? Which code transformed the source records? Who approved the release? Can the previous version be restored? Reproducibility does not mean that every execution will produce bit-for-bit identical results. Distributed computation, hardware variation, nondeterministic algorithms, and changing external services may prevent that. The practical objective is controlled repeatability: sources of variation are identified, important randomness is managed, and differences are measurable and explainable. Testing data and machine-learning pipelinesTraditional unit testing checks small, deterministic pieces of software. Data systems require additional forms of testing because errors may be syntactically valid while semantically wrong. A pipeline can run successfully while silently producing an empty table, duplicating records, changing units, or shifting a date boundary. Common data tests include schema tests, nullness checks, uniqueness constraints, referential integrity checks, permitted-value checks, range checks, volume checks, freshness checks, and distribution checks. A schema test may verify that a customer identifier remains a string and that a transaction amount remains numeric. A freshness test may fail when the expected daily partition has not arrived. Distribution monitoring may signal that the proportion of rejected transactions has changed sharply. Tests should exist at several levels. Unit tests verify transformation functions. Integration tests verify interaction with storage, queues, databases, and external services. Contract tests verify that producers and consumers agree on schemas and semantics. End-to-end tests execute a representative workflow. Data-quality tests evaluate actual or synthetic data. Regression tests compare results with an accepted baseline. The objective is not to test everything in the same way, but to place each control at the level where failures can be detected cheaply and clearly. Machine-learning testing adds further dimensions. A model may need tests for prediction shape, feature availability, permissible score ranges, latency, performance against a benchmark, subgroup performance, calibration, and robustness to missing or unusual inputs. Training pipelines should test that labels are available at the correct prediction time and that features do not contain information from the future. This is a major source of data leakage: a model may appear highly accurate because training features include information that would not have been known when a real prediction was made. Tests need explicit responses. Some failures should block deployment; others should create warnings or initiate investigation. Thresholds should be justified rather than chosen solely to keep pipelines green. Excessive false alarms produce alert fatigue, whereas weak thresholds allow defects into production. CI/CD and controlled deliveryContinuous integration (CI) means that changes are frequently merged into a shared codebase and automatically built and tested. For data and ML systems, CI can validate code style, unit tests, schemas, security scans, dependency vulnerabilities, data contracts, and pipeline compilation. CI should be fast enough to support frequent feedback and should create traceable artifacts. Continuous delivery means that validated changes are kept in a deployable state. Continuous deployment goes further by automatically releasing changes when defined controls pass. Automatic deployment is not always appropriate for a high-impact model or a production data contract. Approval gates, segregation of duties, risk-based review, and scheduled releases may be necessary. A typical pipeline contains source validation, dependency installation, testing, artifact construction, security scanning, registration, deployment to a non-production environment, integration testing, and controlled promotion. The environment should be configured through code rather than manually altered. The release process should also support rollback or roll-forward. For a model, rollback may mean restoring a previous model version, feature transformation, serving image, or compatible combination of all three. Several deployment strategies reduce risk. A blue-green deployment maintains two environments and switches traffic between them. A canary deployment sends a small proportion of traffic to the new version and evaluates technical and business indicators. A shadow deployment runs the new system without using its output for decisions. A/B testing compares alternatives under a defined experimental design, but it is not a substitute for safety controls. Batch models may use champion–challenger evaluation, in which the current champion remains active while a challenger is assessed on recent data. Infrastructure as code and platform architectureInfrastructure as code (IaC) expresses infrastructure resources and their configuration in declarative or procedural files that can be versioned, reviewed, tested, and applied through automation. Resources may include networks, storage, compute clusters, service identities, secrets references, queues, databases, policies, and monitoring rules. IaC improves consistency and recovery, but it does not remove risk. Incorrect code can reproduce an insecure or expensive configuration at scale. State management, dependency ordering, secret handling, drift detection, access control, and approval procedures are therefore essential. A good practice is to separate reusable modules from environment-specific configuration and to review changes through pull requests. Sensitive values should not be committed in plain text; a secret-management service and short-lived credentials are preferable. A platform architecture commonly contains several layers. The foundation layer supplies identity, networking, storage, compute, encryption, logging, and policy enforcement. The data layer supplies ingestion, cataloguing, lakehouse or warehouse capabilities, transformation, quality checks, and orchestration. The ML layer supplies experiment tracking, feature management where justified, training execution, model registration, serving, and monitoring. The developer layer supplies templates, command-line tools, documentation, dashboards, and self-service workflows. A platform should expose stable interfaces and sensible defaults. Teams should be able to create a compliant project without understanding every cloud-provider detail. However, abstraction must not hide important consequences. Developers need visibility into data location, security classification, resource consumption, model limitations, and operational ownership. The platform is successful when it reduces cognitive load while preserving accountability. Registries, metadata, lineage, and observabilityA model registry manages model artifacts and their lifecycle metadata. A registered model may have versions, evaluation results, intended use, owner, approval state, dependencies, deployment history, and retirement status. Registry stages such as development, validation, staging, and production can express governance, although stage names alone do not guarantee a sound approval process. Metadata gives meaning to technical assets. Useful metadata includes business definitions, data classifications, retention periods, quality results, schema versions, owners, service-level objectives, training data references, and known limitations. Metadata should be captured as close to the production workflow as possible; manual documentation created months later is usually incomplete. Data lineage records relationships among sources, transformations, datasets, features, models, and outputs. It may be coarse-grained, such as table-to-table lineage, or fine-grained, such as column-level lineage. Lineage supports impact analysis, incident investigation, regulatory explanation, and deletion requests. It is especially important when a source field is corrected, restricted, or removed and teams must determine which downstream products are affected. Observability extends monitoring from individual metrics to the ability to understand internal system state through outputs. The principal signals are metrics, logs, and traces. Metrics can show pipeline duration, records processed, model latency, error rate, cost, and prediction distribution. Logs provide event-level context but must avoid exposing sensitive information. Traces connect stages across distributed services and help identify where latency or failure occurs. ML monitoring includes both system and model dimensions. System indicators include availability, throughput, resource use, and latency. Data indicators include missingness, schema changes, freshness, and feature distributions. Model indicators include prediction distributions, confidence, calibration, accuracy when labels eventually arrive, and subgroup performance. Business indicators may include conversion, loss rate, fraud capture, customer complaints, or manual-review volume. Drift has multiple meanings. Data drift is a change in input distributions. Concept drift is a change in the relationship between inputs and the target. Prediction drift is a change in model outputs. Drift does not automatically mean that a model is failing, and no drift does not prove that it is safe. Monitoring must connect statistical signals with operational and business interpretation. Alert policies should specify owners, severity, investigation steps, and possible remediation. Operating workflow for a production ML productA disciplined workflow begins with a problem definition and an explicit decision about whether machine learning is necessary. The team identifies the prediction target, decision context, acceptable errors, affected groups, data constraints, and service-level objectives. It then creates a data contract and establishes ownership. The next stage is data preparation and validation. Sources are ingested through controlled interfaces, raw data is retained according to policy, and transformations are implemented as tested code. Training and serving transformations should be aligned to avoid training–serving skew. Features are generated with clear time semantics, and labels are defined without leakage. During experimentation, practitioners track code versions, parameters, datasets, metrics, random seeds where relevant, and explanatory notes. Experiments should be comparable, not merely numerous. Evaluation uses appropriate temporal or group-aware splits rather than an arbitrary random split when the operational setting is time-dependent or population-sensitive. A candidate model is then evaluated against technical, fairness, security, reliability, and business criteria. The candidate is registered with its evidence and limitations. Deployment begins in a controlled environment, followed by integration, load, and shadow or canary testing. Promotion requires an explicit decision record. After release, monitoring detects technical failures, data changes, performance degradation, unexpected use, and harmful outcomes. The response may involve correcting upstream data, changing a threshold, retraining, replacing the model, or withdrawing the capability. Retirement is also part of the lifecycle: obsolete models, features, credentials, and infrastructure should be removed or archived according to policy. Illustrative case: a retail demand-forecasting platformBackground. A fictional national retailer, Northstar Stores, operates several hundred outlets and an online channel. Its data science group built demand forecasts in notebooks and delivered weekly CSV files to replenishment planners. Forecast accuracy was reasonable in pilots, but production results varied because source extracts, feature definitions, and manual adjustments were not consistently recorded. Situation. During a promotional period, a duplicated sales partition inflated historical demand for several product categories. The training job completed successfully and produced forecasts, but inventory recommendations became excessive. The team could not quickly identify which model version used the defective partition. At the same time, cloud costs were rising because development clusters remained active after experiments. Analysis. The main problem was not simply model accuracy. The organization lacked dataset versioning, data-quality gates, lineage, ownership, cost controls, and a reliable promotion process. Manual notebook execution had created an ungoverned path from data to business decision. Approach. Northstar established a platform team and a product team with shared responsibilities. Source code, pipeline definitions, and infrastructure were placed under version control. Raw sales partitions received immutable identifiers, while curated tables carried schema, freshness, volume, and duplication tests. A workflow orchestrator recorded run metadata and stopped downstream training when critical tests failed. Experiments were tracked with dataset references, code commits, parameters, and evaluation results. A model registry stored candidate and production versions together with approval evidence. Infrastructure was provisioned through reusable IaC modules, with automatic expiration for temporary environments and budget alerts. Forecasts were first run in shadow mode, then released category by category. Monitoring covered data freshness, forecast latency, error rates, prediction distributions, inventory outcomes, and cloud expenditure. Outcome. The retailer could identify the defective partition, prevent contaminated training, and restore the previous approved model. The new process made releases slower in the narrow sense that evidence was required, but substantially reduced unplanned investigation and manual rework. Teams also gained a common platform rather than independently maintained scripts. Learning points. The case demonstrates that MLOps is not only model deployment. It depends on data quality, provenance, infrastructure control, human approval, monitoring, and clear ownership. It also illustrates why cost and operational simplicity belong in platform design rather than being treated as secondary concerns. Organizational, ethical, and governance considerationsOperational maturity requires an ownership model. Every data product should have a responsible team, technical owner, data owner where applicable, defined consumers, service-level objectives, and escalation procedures. A responsibility matrix can distinguish who develops, approves, deploys, monitors, and retires a system. DevOps-style shared responsibility is useful, but it should not become an excuse for unclear accountability. Security must be integrated into the delivery lifecycle. Least-privilege identities, network controls, encryption, secret rotation, dependency scanning, image scanning, audit logs, and separation of development and production environments are standard safeguards. Production data should not be copied into development without appropriate masking, minimisation, and authorization. Supply-chain security is increasingly important because a compromised dependency or container can affect many downstream workloads. Governance concerns include lawful data use, retention, access rights, traceability, human oversight, and explainability appropriate to the decision. Model cards, data documentation, impact assessments, approval records, and incident logs can support responsible use. Fairness evaluation should examine relevant subgroups and deployment context, not merely a single aggregate metric. Monitoring should include harmful or discriminatory outcomes where the system can affect people. Automation can amplify bad decisions. A fully automated retraining pipeline may continuously learn from biased, corrupted, or strategically manipulated data. Retraining therefore needs eligibility criteria, validation, drift interpretation, and, for consequential applications, human review. The goal is controlled automation, not automation without judgment. Common failure patterns and practical safeguardsA frequent mistake is beginning with tools rather than operating requirements. Selecting an orchestrator, registry, or cloud service before defining ownership, quality expectations, and deployment risk often produces a technically impressive but unused platform. Another mistake is treating dashboards as observability. A large collection of metrics is not useful if alerts lack thresholds, owners, runbooks, or response time expectations. Teams should begin with critical user journeys and failure modes, then instrument the signals needed to diagnose them. Manual steps are not always wrong, particularly for high-risk approvals, but undocumented manual steps are dangerous. If a release requires a manual action, the action, authority, evidence, and audit record should be explicit. Overengineering is also a risk. Not every use case requires a feature store, real-time serving, or sophisticated orchestration. Architecture should reflect latency, scale, risk, reuse, and organizational capability. Conversely, underengineering a high-impact system by relying on notebooks and shared credentials is equally problematic. Teams should also avoid confusing model drift with business failure, using accuracy metrics that do not match the decision, ignoring training–serving skew, retaining resources indefinitely, and allowing platform teams to become bottlenecks. Self-service templates, clear golden paths, documentation, and product-oriented platform ownership help maintain balance. Current developments and strategic directionModern platforms increasingly combine lakehouse storage, workflow orchestration, containerized execution, managed cloud services, policy-as-code, and declarative deployment. GitOps practices extend version-controlled operations by treating a repository as the desired state for infrastructure or applications, with automated reconciliation. Software bills of materials, signed artifacts, provenance attestations, and supply-chain verification are gaining importance. They help organizations understand what is inside a deployed image and whether an artifact was produced through an approved process. Open standards for lineage, telemetry, and model interfaces also improve portability across tools. Generative AI introduces additional operational concerns: prompt and retrieval versioning, evaluation of nondeterministic outputs, provenance of source material, latency and token cost, prompt injection, sensitive-data leakage, and human review. Traditional model metrics may be insufficient, so task-specific evaluation sets, safety tests, trace sampling, and feedback analysis are required. Platform engineering is also moving toward internal products rather than collections of infrastructure components. A successful platform measures developer lead time, deployment recovery, reliability, adoption, support burden, and user satisfaction. Its purpose is to improve organizational capability while preserving governance and technical autonomy. Best-practice principlesA practical operating model can be guided by the following principles: 1. Treat data, models, pipelines, and infrastructure as versioned products. 2. Make provenance and ownership visible before production release. 3. Test data semantics, not only code execution. 4. Automate repeatable controls while retaining proportionate human judgment. 5. Build deployment and rollback paths before the first production release. 6. Monitor technical, data, model, business, security, and cost signals together. 7. Prefer immutable artifacts and reproducible environments. 8. Design platforms around supported golden paths and self-service interfaces. 9. Apply least privilege, data minimisation, and secure supply-chain practices. 10. Retire obsolete models, data products, credentials, and infrastructure deliberately. Chapter SummaryDataOps, MLOps, and platform engineering provide complementary approaches for operating dependable data and AI systems. DataOps applies engineering discipline to data products; MLOps manages the broader lifecycle of machine-learning systems; and platform engineering builds reusable foundations that make reliable practices accessible to delivery teams. Reproducibility depends on versioning code, data, environments, processes, artifacts, and deployments. Automated testing must address software, schemas, data quality, leakage, performance, fairness, and operational behaviour. CI/CD and deployment strategies such as canary, blue-green, shadow, and champion–challenger releases reduce delivery risk. Infrastructure as code supports consistency and recovery, while registries, metadata, lineage, and observability support governance and diagnosis. Effective operation also requires ownership, security, ethical oversight, cost management, incident response, and controlled automation. The central professional lesson is that production analytics is a socio-technical capability, not merely a collection of cloud tools. Key TermsDataOps: A socio-technical practice for reliable, collaborative, and automated delivery of data products. MLOps: The discipline of managing machine-learning development, deployment, monitoring, governance, and retirement. Platform engineering: The design of reusable internal platforms that provide supported self-service capabilities to delivery teams. Data product: An operational data output with defined users, quality expectations, ownership, and lifecycle controls. Reproducibility: The ability to recreate or explain a result using recorded inputs, code, configuration, and execution conditions. Data lineage: A record of relationships among data sources, transformations, datasets, models, and outputs. Data contract: An explicit agreement concerning the schema, semantics, quality, and delivery expectations of a data interface. Infrastructure as code: The management of infrastructure through versioned, reviewable, and executable definitions. Continuous integration: The frequent integration of code changes supported by automated building and testing. Continuous delivery: Keeping validated software or analytical artifacts in a deployable state. Model registry: A managed repository of model versions, artifacts, metadata, evaluation evidence, and lifecycle status. Observability: The ability to infer internal system state from outputs such as metrics, logs, and traces. Data drift: A change in the distribution or characteristics of input data. Concept drift: A change in the relationship between input variables and the target outcome. Training–serving skew: A mismatch between feature processing during training and feature processing during production inference. Data leakage: The unintended use of information unavailable at prediction time, producing misleading evaluation results. Canary deployment: A release strategy that directs a small amount of traffic to a new version before broader promotion. Champion–challenger evaluation: The comparison of a currently deployed model with a candidate model before replacement. Provenance: Evidence describing the origin, transformations, dependencies, and history of an artifact or result. Service-level objective: A defined target for a service characteristic such as availability, latency, freshness, or quality. Review QuestionsShort Answer Questions1. How do DataOps and MLOps differ in their primary operational focus? 2. What is the purpose of a model registry? 3. Define training–serving skew and explain why it is dangerous. 4. Name three types of tests that may be applied to a data pipeline. 5. What is the role of infrastructure as code in cloud analytics? Long Answer Questions1. Explain how versioning, metadata, lineage, and artifact management together support reproducible machine-learning deployment. 2. Discuss the role of CI/CD in data and ML systems, including situations in which automatic deployment should be limited. 3. Describe a platform-engineering architecture for a cloud analytics organization and explain the responsibilities of its major layers. 4. Explain how system monitoring, data monitoring, model monitoring, business monitoring, and cost monitoring complement one another. 5. Critically discuss the security, ethical, and governance requirements of an automated retraining system. Analytical / Application Questions1. A daily pipeline completes successfully but produces a table with 40 percent fewer records and no error message. Design a testing and observability response that would detect, diagnose, and manage this failure. 2. A bank wants to replace a production credit-risk model with a more accurate candidate whose subgroup performance is uncertain. Recommend a validation, approval, deployment, and monitoring strategy. 3. An organization has five independent teams using notebooks, manually configured cloud resources, and shared credentials. Propose a phased DataOps, MLOps, and platform-engineering improvement plan, identifying likely trade-offs and risks. 22. Multiple Choice Questions with AnswersQuestion 1Which statement best distinguishes MLOps from DataOps? A. MLOps concerns only cloud infrastructure, whereas DataOps concerns only databases. B. MLOps manages the lifecycle of learning systems, including training and model monitoring, while DataOps focuses primarily on reliable data delivery. C. MLOps replaces the need for data governance, whereas DataOps provides governance only. D. MLOps is a manual process, whereas DataOps is always fully automated. Correct Answer: B. MLOps manages the lifecycle of learning systems, including training and model monitoring, while DataOps focuses primarily on reliable data delivery. Question 2A training pipeline completes successfully after a duplicated sales partition is ingested. Which control would most directly prevent this defect from reaching model training? A. A container image scan B. A duplication or uniqueness data-quality test used as a deployment gate C. A blue-green deployment D. A model latency dashboard Correct Answer: B. A duplication or uniqueness data-quality test used as a deployment gate Question 3Which set of information provides the strongest basis for reproducing a deployed model result? A. The model name and the date of deployment B. The latest source code only C. The code commit, data snapshot, dependency environment, configuration, model artifact, and run metadata D. A screenshot of the experiment dashboard Correct Answer: C. The code commit, data snapshot, dependency environment, configuration, model artifact, and run metadata Question 4A new model is first run on live inputs, but its outputs are not used for business decisions. Which deployment strategy is being used? A. Shadow deployment B. Blue-green deployment C. Canary deployment D. Rollback deployment Correct Answer: A. Shadow deployment Question 5Which observation is an example of concept drift rather than data drift? A. The average transaction amount changes over time. B. A categorical feature contains a newly introduced value. C. The relationship between customer attributes and default risk changes after a market event. D. The number of records in a daily partition decreases. Correct Answer: C. The relationship between customer attributes and default risk changes after a market event. Question 6What is the primary purpose of infrastructure as code? A. To eliminate the need for security review B. To express infrastructure in versioned and reviewable definitions that can be applied consistently C. To guarantee that cloud resources never incur costs D. To replace all application testing Correct Answer: B. To express infrastructure in versioned and reviewable definitions that can be applied consistently Question 7A model has excellent offline accuracy because a feature includes a value recorded only after the prediction outcome occurs. What problem has most likely occurred? A. Data leakage B. Canary failure C. Infrastructure drift D. Container underutilization Correct Answer: A. Data leakage Question 8Which platform-engineering practice best supports self-service while preserving organizational standards? A. Allowing every team to use shared administrator credentials B. Providing reusable templates, approved defaults, automated controls, and clear interfaces C. Preventing delivery teams from viewing infrastructure configuration D. Requiring the platform team to manually execute every deployment Correct Answer: B. Providing reusable templates, approved defaults, automated controls, and clear interfaces Question 9Why is monitoring prediction distributions alone insufficient for assessing model health? A. Prediction distributions are never measurable. B. They cannot reveal system latency or availability. C. A stable prediction distribution does not prove that accuracy, fairness, data quality, or business outcomes remain acceptable. D. Prediction distributions are relevant only during training. Correct Answer: C. A stable prediction distribution does not prove that accuracy, fairness, data quality, or business outcomes remain acceptable. Question 10Which response is most appropriate when an automated retraining job detects drift in a high-impact application? A. Immediately deploy the retrained model without review. B. Delete all historical training data. C. Investigate the drift, validate the candidate against technical and governance criteria, and require proportionate approval before promotion. D. Disable all monitoring to prevent false alarms. Correct Answer: C. Investigate the drift, validate the candidate against technical and governance criteria, and require proportionate approval before promotion.
|
