AI Engineering, Data Platforms and MLOps

Introduction

Artificial intelligence becomes economically and socially valuable only when models operate reliably in real environments. A model developed in a notebook is not yet a production AI system. Production deployment requires dependable data acquisition, reproducible training, secure interfaces, scalable computation, observability, governance, and processes for updating or retiring models. These concerns are addressed by AI engineering and MLOps.

AI engineering combines software engineering, data engineering, machine learning, cloud computing, systems design, and risk management. MLOps applies automation and operational discipline to the machine-learning lifecycle. The objective is not merely to deploy a model, but to maintain a system whose predictions remain useful, available, explainable, secure, and compliant as data, users, infrastructure, and business conditions change.

A production AI system can be represented as a sociotechnical system with five interacting layers:

1. Data layer: sources, ingestion, storage, transformation, quality, metadata, and access control.

2. Model layer: training, evaluation, packaging, registry, deployment, and updating.

3. Serving layer: APIs, batch jobs, streaming inference, edge runtimes, and user applications.

4. Platform layer: compute, networking, orchestration, observability, security, and cost management.

5. Governance layer: accountability, documentation, privacy, fairness, auditability, and lifecycle decisions.

Learning Objectives

By the end of this chapter, students should be able to:

• distinguish AI engineering, data engineering, DevOps, and MLOps;
• design a production data and model pipeline;
• compare cloud, on-premises, and edge deployment;
• select suitable APIs and inference patterns;
• explain model versioning, testing, monitoring, and rollback;
• calculate basic capacity and service-level quantities;
• identify security, privacy, fairness, and regulatory risks;
• design an LLMOps lifecycle for large language model applications; and
• evaluate a complete AI platform using technical and managerial criteria.

1. From Experimental Models to Production Systems

A machine-learning experiment generally assumes a fixed dataset, a controlled environment, and a human who can inspect failures. Production systems face changing inputs, concurrent users, hardware failures, delayed labels, adversarial behavior, and legal obligations. Consequently, model accuracy is only one dimension of quality.

Important operational qualities include:

• Correctness: predictions and business decisions meet defined requirements.
• Availability: the service is accessible when required.
• Latency: responses arrive within an acceptable time.
• Throughput: the system handles the required volume of requests or records.
• Scalability: capacity can increase as demand grows.
• Reliability: the system behaves consistently despite faults.
• Maintainability: components can be changed without uncontrolled effects.
• Reproducibility: a result can be recreated from recorded code, data, parameters, and environment.
• Safety and compliance: foreseeable harm and legal violations are controlled.

A useful distinction is between model performance and system performance. A classifier may have high area under the ROC curve but still be unsuitable if its features arrive late, its predictions cannot be explained, or its API fails during peak demand. Production readiness therefore requires a set of acceptance criteria covering both the model and its operating context.

DevOps and MLOps

DevOps integrates software development and IT operations through automation, continuous integration, continuous delivery, infrastructure as code, testing, and monitoring. MLOps extends these ideas to assets that are unique to machine learning: datasets, labels, features, model artifacts, training runs, evaluation reports, and data-dependent behavior.

The principal difference is that conventional software behavior is primarily determined by source code, whereas an ML system is determined by code, data, parameters, and the training environment. A change in any of these may change predictions. MLOps must therefore manage data drift, concept drift, training-serving skew, and model lineage in addition to software defects.

2. Data Platforms for AI

Data ingestion and storage

Data may arrive through batch files, relational databases, event streams, application APIs, sensors, or external providers. Batch ingestion is appropriate for periodic large-volume transfers; streaming ingestion is appropriate when events must be processed with low delay.

A modern platform commonly separates:

• Object or data lake storage, which stores raw and curated files at relatively low cost;
• Warehouse or lakehouse storage, which supports governed analytical queries; and
• Operational databases, which support transactional applications and current-state lookups.

The choice should reflect access patterns, consistency requirements, data volume, latency, governance, and cost. A data lake is not automatically a data platform: without cataloguing, quality controls, ownership, and lifecycle policies, it can become an unmanaged data swamp.

ETL, ELT, and feature pipelines

In ETL, data is extracted, transformed, and then loaded into a target system. In ELT, raw data is loaded first and transformed using the target platform. Both approaches can be valid. ELT is often attractive when scalable analytical compute is available, while ETL may be useful when transformation must occur before data enters a controlled environment.

A feature pipeline converts raw observations into variables used by a model. It should define data types, units, missing-value treatment, time windows, aggregation logic, and leakage controls. A particularly important design principle is that training features must be calculated using information available at the prediction time. For example, using a customer’s eventual repayment status to construct a feature would create target leakage and produce misleading validation results.

Feature stores may provide an offline store for training and an online store for low-latency serving. Their value lies not only in storage, but also in consistent feature definitions, ownership, freshness tracking, and reuse.

Data quality

Data quality should be measured rather than assumed. Common dimensions include completeness, validity, uniqueness, consistency, timeliness, and accuracy. Quality checks may verify schema, permitted ranges, null rates, referential integrity, duplication, distribution changes, and unexpected category values.

Checks should operate at several stages:

• ingestion validation rejects malformed records;
• transformation validation checks intermediate tables;
• training validation checks class balance, leakage, and temporal splits;
• serving validation checks request schemas and feature freshness; and
• monitoring checks production distributions and outcomes.

Data contracts formalize expectations between producers and consumers. A contract may specify field names, types, units, allowable nulls, semantic meaning, update frequency, and compatibility rules. Contract violations should generate alerts or controlled rejection rather than silently corrupting training data.

Reproducibility and lineage

A reproducible training run records the source-code version, data snapshot or query, feature definitions, hyperparameters, random seeds where relevant, software dependencies, hardware environment, evaluation results, and model artifact. A lineage graph connects an input source to transformations, training runs, models, deployments, and predictions. This supports debugging, audit, scientific comparison, and controlled rollback.

Random seeds improve repeatability but do not guarantee identical results across hardware, libraries, parallel execution, or nondeterministic kernels. Reproducibility should therefore be treated as an engineering target with documented tolerances, not as an assumption based solely on setting a seed.

3. Model Lifecycle and Deployment Patterns

A practical lifecycle contains the following stages:

1. problem definition and risk classification;

2. data acquisition and exploration;

3. feature and label design;

4. training and validation;

5. independent evaluation;

6. packaging and registration;

7. deployment to a controlled environment;

8. monitoring and incident response;

9. retraining, promotion, rollback, or retirement.

A model registry stores approved model artifacts and metadata. Typical stages include development, validation, staging, production, and archived. Promotion should be based on documented criteria rather than informal approval. A model version should be immutable after registration; changes create a new version.

Deployment patterns

Batch inference processes records periodically and writes predictions to storage. It is suitable for planning, recommendations updated daily, and large workloads without strict response-time requirements.

Online inference exposes a service that returns predictions for individual or grouped requests. It is suitable for interactive applications, fraud screening, and real-time personalization.

Streaming inference processes events continuously and may maintain state over time windows. It is useful for monitoring, industrial telemetry, and event-driven decisions.

Embedded or edge inference places the model near the data source, such as a mobile device, vehicle, camera, or industrial controller. It reduces network dependence and can improve privacy and latency, but introduces constraints on memory, power, hardware diversity, and update management.

Shadow deployment sends production inputs to a candidate model without using its outputs for decisions. It measures behavior safely. Canary deployment exposes a small proportion of users or traffic to the candidate and expands exposure if predefined metrics remain acceptable. Blue-green deployment maintains two environments and switches traffic between them, enabling rapid rollback at the cost of duplicated infrastructure.

APIs and serving

A prediction API should define authentication, authorization, request and response schemas, error behavior, versioning, timeouts, rate limits, and observability fields. Idempotency may be required for requests that trigger downstream actions. APIs should not expose sensitive features or internal implementation details unnecessarily.

Synchronous APIs are appropriate when a response is needed immediately. Asynchronous APIs are preferable for long-running jobs: the client submits a request, receives a job identifier, and later retrieves the result. Message queues can absorb bursts and decouple producers from consumers.

Model packaging may use containers, language-specific artifacts, or standardized inference protocols. Container images should be minimal, pinned to controlled dependencies, scanned for vulnerabilities, and rebuilt through a trusted pipeline.

4. Capacity, Reliability, and Scalability

Capacity planning connects business demand to infrastructure. If a system receives an average of \(R\) requests per second and each request requires an average service time \(S\) seconds of compute on one worker, the approximate worker utilization is

\[

U = R S.

\]

This relation assumes a single equivalent worker and average rates; it is not a complete queueing model. For stable operation, utilization should remain below 1, and practical systems reserve headroom for bursts, variance, failures, and maintenance. If each worker can process \(C\) requests per second under the target latency and the peak arrival rate is \(P\), a basic lower bound on workers is \(\lceil P/C \rceil\). Additional workers may be required for redundancy and autoscaling delay.

For example, if peak demand is 240 requests per second and one inference worker sustains 40 requests per second at the required latency, at least \(\lceil 240/40 \rceil = 6\) workers are needed for capacity. If one worker must remain available during failure, at least 7 workers should be provisioned, before considering further operational headroom.

The latency budget divides an end-to-end target among network transfer, feature retrieval, preprocessing, model inference, postprocessing, and downstream actions. Average latency alone is insufficient; percentiles such as p95 or p99 reveal tail behavior. A service-level objective might require that 99% of valid requests complete within a specified time over a defined measurement period.

Reliability engineering uses redundancy, health checks, timeouts, retries with backoff, circuit breakers, graceful degradation, and disaster recovery. Retries must be bounded: indiscriminate retries can amplify overload. Recovery objectives should be explicit:

• Recovery time objective (RTO): maximum acceptable time to restore service.
• Recovery point objective (RPO): maximum acceptable amount of data or state that may be lost.

5. Testing and Continuous Delivery

Testing an AI system requires more than unit tests. A layered strategy includes:

• Unit tests for transformations, feature calculations, validation rules, and utility code;
• Integration tests for databases, feature stores, queues, model servers, and APIs;
• Contract tests for producer-consumer schemas;
• Data tests for distributions, missingness, ranges, and leakage indicators;
• Model tests for predictive metrics, calibration, subgroup performance, robustness, and resource use;
• End-to-end tests for complete business workflows;
• Load and stress tests for throughput, latency, and failure behavior; and
• Security tests for authentication, authorization, dependency vulnerabilities, prompt injection, and data exposure.

A model should not be promoted solely because its aggregate accuracy exceeds a threshold. Evaluation should use a holdout set representing the intended operating population and, where time matters, a temporal split. Thresholds should be selected using validation data and then assessed on untouched test data. Confidence intervals or repeated evaluation can communicate uncertainty, especially when samples are small.

Continuous integration validates code and artifacts for every change. Continuous delivery automates packaging and deployment to controlled environments. Continuous deployment releases automatically only when risk, testing, and governance requirements permit it. High-risk applications may require manual approval and documented evidence.

6. Monitoring and Lifecycle Management

Monitoring should cover four categories:

1. Infrastructure monitoring: CPU, memory, accelerator utilization, disk, network, restarts, and hardware health.

2. Service monitoring: request rate, errors, timeouts, queue depth, and latency percentiles.

3. Data monitoring: missingness, schema changes, ranges, category frequencies, feature freshness, and distribution shifts.

4. Model monitoring: prediction distributions, confidence, calibration, drift, subgroup performance, business outcomes, and safety incidents.

Data drift refers to changes in input distributions. Concept drift refers to changes in the relationship between inputs and the target. A model may experience data drift without performance loss, or performance loss without an easily detected shift in simple feature distributions. Therefore, drift alarms are signals for investigation, not automatic proof that retraining is required.

Ground-truth labels are often delayed. A fraud outcome may be known weeks later, while a recommendation may have implicit and biased feedback. Monitoring should distinguish leading indicators, such as input shift, from lagging indicators, such as verified outcomes.

Retraining policies may be scheduled, trigger-based, or hybrid. Automatic retraining is dangerous when corrupted data or feedback loops can produce a new but inferior model. A safe policy includes data validation, reproducible training, comparison with the incumbent, approval gates, canary release, and rollback.

Model retirement is part of lifecycle management. A model should be retired when its purpose ends, data becomes unavailable, risk changes, a superior replacement is validated, or maintenance cost exceeds value. Retired artifacts and records may need to be preserved for audit and reproducibility.

7. Cloud, Edge, and Platform Architecture

Cloud platforms provide elastic compute, managed storage, orchestration, observability, identity services, and specialized accelerators. They support rapid experimentation and global deployment but create concerns about cost variability, vendor dependence, data residency, shared responsibility, and network dependence.

On-premises platforms may be required for sovereignty, predictable costs, specialized hardware, or highly sensitive data. They offer greater infrastructure control but typically require more internal expertise and capital investment. Hybrid architectures combine environments, for example keeping regulated data on-premises while using cloud-based training on approved de-identified data.

Edge computing places inference near the data source. Benefits include low latency, offline operation, reduced bandwidth, and local processing of sensitive data. Limitations include constrained compute, difficult fleet management, intermittent connectivity, physical tampering, and model fragmentation across hardware versions. Edge systems need signed updates, device identity, secure boot where available, local logging, and a recovery mechanism.

Platform engineering should provide reusable “golden paths”: standard project templates, approved base images, secure CI/CD pipelines, observability libraries, model registry integration, and documented deployment patterns. Standardization reduces duplicated effort while allowing exceptions through an explicit review process.

8. Security, Privacy, and Responsible AI

AI systems expand the attack surface because they combine software, data, models, and external inputs. Threats include credential theft, insecure dependencies, data poisoning, model extraction, membership inference, adversarial inputs, denial of service, unauthorized model changes, and sensitive information leakage.

Essential controls include least-privilege identity, encryption in transit and at rest, network segmentation, secrets management, vulnerability scanning, signed artifacts, immutable audit logs, backup and recovery, and separation of development and production access. Training data access should be limited to legitimate purposes and logged.

Privacy engineering may use data minimization, retention limits, pseudonymization, access controls, aggregation, and—where appropriate—privacy-preserving learning methods. Pseudonymization does not make data anonymous if re-identification remains possible. Privacy impact assessments should consider the complete lifecycle, not only training.

Responsible AI requires documented intended use, prohibited use, affected groups, known limitations, human oversight, appeal processes, and incident response. Fairness evaluation should be tied to the decision context. Group metrics can reveal disparities, but no single fairness metric resolves all ethical trade-offs. Improving one metric may worsen another, especially when base rates differ. Evaluation should therefore involve domain experts and affected stakeholders.

Regulatory obligations vary by jurisdiction and application. High-impact uses may require risk management, transparency, record keeping, human oversight, data governance, and post-deployment monitoring. Organizations should maintain model cards, data sheets, risk assessments, approval records, and evidence supporting claims about performance and limitations.

9. LLMOps and Generative AI Systems

LLMOps adapts MLOps to large language models and retrieval-augmented generation (RAG). A generative AI application may include a foundation model, system instructions, prompt templates, a document-ingestion pipeline, an embedding model, a vector index, retrieval and reranking, tool calls, guardrails, output validation, and human review.

Important LLMOps assets include:

• versioned prompts and system policies;
• model and tokenizer versions;
• curated document collections and chunking rules;
• embedding and index versions;
• evaluation datasets containing normal, adversarial, and domain-specific queries;
• traces of retrieval, tool use, latency, token usage, and outputs; and
• safety and privacy test results.

RAG can improve grounding by retrieving relevant organizational information, but retrieval quality is not guaranteed. Failures include missing documents, stale indexes, poor chunk boundaries, irrelevant context, contradictory sources, and prompt injection contained in retrieved content. Access control must be applied during retrieval; a language model must not be allowed to cite documents the user is unauthorized to view.

LLM evaluation should combine automated and human methods. Useful dimensions include factual grounding, relevance, completeness, refusal behavior, toxicity, privacy leakage, instruction following, latency, and cost. Exact-match metrics are inadequate for many open-ended tasks. Evaluation sets should include difficult edge cases and should be protected from contamination where feasible.

Token consumption affects cost and latency. Caching, smaller task-specific models, prompt compression, batching, routing, and retrieval optimization can reduce expense. However, optimization must not silently reduce safety or answer quality. Tool execution should use allowlists, scoped credentials, input validation, output validation, and confirmation for consequential actions.

10. Applied Case: Illustrative Smart-Facility Predictive Maintenance System

Background

A university operates chilled-water pumps in several buildings. Unexpected failures interrupt research laboratories and produce expensive emergency repairs. The facilities team wants to predict failures early enough to schedule maintenance.

Problem

Sensors generate vibration, temperature, pressure, and current readings at one-minute intervals. Historical failure labels are incomplete, and sensors occasionally go offline. The system must provide a maintenance risk score, support an operator dashboard, and avoid automatic shutdown decisions.

Analysis

The team identifies three risks. First, a model could learn from maintenance records entered after a failure, causing leakage. Second, buildings have different operating conditions, so a model trained on one building may not generalize. Third, labels are delayed and failures are rare, making accuracy an inappropriate primary metric.

Approach and solution

The data platform ingests sensor events through a streaming gateway and stores immutable raw data in object storage. A curated time-series table records sensor values, device identity, timestamps, calibration status, and quality flags. A data contract specifies units, maximum delay, and missingness behavior.

Features are computed using only measurements available before a prediction timestamp. Examples include rolling temperature statistics, vibration trends, and the proportion of missing readings in the preceding interval. Training uses time-based validation so that future information does not enter the past. The team evaluates precision-recall behavior, recall at a controlled alert rate, calibration, and performance by building and equipment type.

The model is registered with its training-data snapshot, feature code, evaluation report, and approved use limitations. An online service returns risk scores to the dashboard, while a batch process produces daily maintenance summaries. The service does not issue shutdown commands. Alerts require operator confirmation and include contributing signals and data-quality warnings.

Monitoring tracks sensor freshness, missingness, score distributions, alert volume, service latency, and confirmed failures. A shadow deployment compares a candidate model with the incumbent. Because confirmed labels arrive after maintenance investigations, performance monitoring combines delayed outcome evaluation with immediate checks for sensor and prediction anomalies.

Outcome

In this illustrative case, the platform enables earlier inspection and provides an auditable connection between sensor data, model versions, and maintenance decisions. Its success is not defined solely by a high validation score. It depends on reducing avoidable downtime without creating excessive false alarms, while preserving operator authority and system safety.

Learning points

The case demonstrates that production AI is a workflow rather than a model endpoint. Temporal data discipline prevents leakage; data contracts improve reliability; human oversight limits harm; monitoring must account for delayed labels; and operational outcomes must be measured alongside technical metrics.

11. Managerial and Professional Implications

AI platform decisions should be evaluated across value, risk, time, and sustainability. Building a custom platform may provide control but require substantial specialist staffing. Managed services can accelerate delivery but create dependency and may limit transparency. Total cost includes compute, storage, data transfer, observability, security, human review, incident response, retraining, and retirement—not only inference charges.

Teams should establish clear ownership. Product owners define objectives and acceptable risk; data engineers own ingestion and quality; ML engineers own training and serving; platform engineers own infrastructure and reliability; security and privacy specialists assess controls; domain experts validate usefulness and harm; and governance functions maintain accountability. Small organizations may combine roles, but responsibilities must still be explicit.

A mature operating model uses service-level objectives, risk-based approval, incident playbooks, post-incident learning, and periodic review of whether the system remains necessary. Documentation should be written for both technical maintainers and decision-makers.

12. Challenges and Limitations

MLOps does not eliminate uncertainty. Monitoring cannot detect every failure, especially when labels are delayed or outcomes are poorly defined. Automated pipelines can scale bad decisions faster than manual processes. Data drift metrics may produce false alarms, while static thresholds may miss contextual changes. Reproducibility can be difficult when external data, proprietary models, or nondeterministic hardware are involved.

There are also organizational barriers: unclear ownership, weak data stewardship, incentives favoring rapid deployment, insufficient domain participation, and underinvestment in maintenance. Technical debt accumulates through undocumented features, fragile dependencies, one-off environments, and untested assumptions. Finally, no platform architecture is universally optimal. Appropriate design depends on workload, risk, latency, volume, regulatory context, skills, and budget.

Best-Practice Checklist

• Define the decision, users, harm scenarios, and success measures before selecting a model.
• Treat data, code, models, prompts, indexes, and environments as versioned assets.
• Enforce data contracts, quality checks, lineage, and leakage prevention.
• Separate development, staging, and production access.
• Use layered testing, realistic temporal evaluation, and capacity tests.
• Deploy through reproducible artifacts with approval and rollback mechanisms.
• Monitor infrastructure, service behavior, data, model outcomes, and safety.
• Design for delayed labels and investigate drift rather than reacting blindly.
• Apply least privilege, encryption, secure secrets, signed artifacts, and audit trails.
• Include domain experts, affected stakeholders, and human oversight in high-impact systems.
• For LLMs, version prompts and retrieval assets, test injection and leakage, and constrain tool use.
• Budget for operations, retraining, incident response, and retirement from the beginning.

Chapter Summary

AI engineering turns machine-learning research into dependable production systems. MLOps extends DevOps by versioning and automating data, features, models, experiments, and deployment environments. A robust AI platform includes governed ingestion, quality controls, lineage, reproducible training, model registries, secure APIs, appropriate deployment patterns, capacity planning, testing, monitoring, and lifecycle management.

Cloud, on-premises, hybrid, and edge platforms offer different trade-offs in scalability, control, latency, privacy, cost, and operational complexity. Production readiness requires monitoring not only infrastructure and APIs, but also data quality, drift, delayed outcomes, subgroup behavior, and business impact. Security and responsible AI must be designed into the lifecycle through least privilege, privacy controls, documentation, human oversight, and risk-based governance.

LLMOps adds prompt, retrieval, embedding, tool, output, and safety management to conventional MLOps. Across all architectures, the central principle is that a model is one component of a continuously managed sociotechnical system. Success depends on reliable operations, accountable decisions, and evidence that the system remains fit for purpose.

Key Terms

AI engineering: The disciplined design and operation of AI-enabled software and platforms.

MLOps: Practices that automate and govern the lifecycle of machine-learning systems.

Data contract: An explicit agreement defining data schema, meaning, quality, and delivery expectations.

Feature pipeline: A process that transforms raw data into model input variables.

Feature store: A system that manages reusable features for training and serving.

Data drift: Change in the distribution of model inputs over time.

Concept drift: Change in the relationship between inputs and the target outcome.

Training-serving skew: A difference between feature computation during training and production serving.

Model registry: A controlled repository for model artifacts, metadata, and promotion stages.

Batch inference: Generating predictions periodically for a collection of records.

Online inference: Returning predictions through an interactive service request.

Canary deployment: Gradually exposing a new version to a limited portion of traffic.

Shadow deployment: Running a candidate model without using its predictions for decisions.

Service-level objective: A defined target for an operational measure such as availability or latency.

Recovery time objective: The maximum acceptable time to restore a service.

Recovery point objective: The maximum acceptable amount of data loss after failure.

Model lineage: Traceability linking data, transformations, training, models, deployments, and outputs.

LLMOps: Operational practices for large language model applications.

Retrieval-augmented generation: Generating responses using information retrieved from an external knowledge source.

Model card: Documentation describing a model’s purpose, performance, limitations, and appropriate use.

Review Questions

Short Answer Questions

1. Why is model accuracy alone insufficient for judging production AI quality?

2. Distinguish data drift from concept drift.

3. What is the purpose of a model registry?

4. Give two advantages and two limitations of edge inference.

5. Why must feature computation be consistent between training and serving?

Long Answer Questions

1. Explain the architecture and responsibilities of a production MLOps platform.

2. Compare batch, online, streaming, and edge inference, including appropriate use cases.

3. Describe a layered testing strategy for a high-impact machine-learning application.

4. Explain how security, privacy, fairness, and accountability should be incorporated into the AI lifecycle.

5. Discuss the additional assets, risks, and evaluation requirements introduced by LLMOps.

Analytical / Application Questions

1. A prediction service receives a peak of 360 requests per second. Each worker sustains 45 requests per second at the required latency. Calculate the minimum capacity workers and recommend how you would account for redundancy and burst headroom.

2. Design a monitoring and retraining policy for a fraud model whose verified labels arrive 30 days after prediction. Identify leading indicators, lagging indicators, approval gates, and rollback conditions.

3. An organization wants to deploy a RAG assistant over confidential legal documents. Propose an architecture that addresses document-level authorization, prompt injection, model hallucination, auditability, and cost control.

Multiple Choice Questions with Answers

Question 1

Which asset is especially important to version in MLOps in addition to source code?

A. Only the user interface color scheme

B. Training data and model artifacts

C. The office seating plan

D. The organization’s logo

Correct Answer: B. Training data and model artifacts

Question 2

Which deployment pattern runs a candidate model without using its predictions for operational decisions?

A. Canary deployment

B. Blue-green deployment

C. Shadow deployment

D. Batch deployment

Correct Answer: C. Shadow deployment

Question 3

A service receives 240 requests per second, and one worker handles 40 requests per second at the required latency. What is the minimum number of workers for capacity alone?

A. 4

B. 5

C. 6

D. 8

Correct Answer: C. 6

Question 4

Which problem occurs when training features use information unavailable at prediction time?

A. Target leakage

B. Autoscaling

C. Load balancing

D. Data compression

Correct Answer: A. Target leakage

Question 5

Which metric category measures request latency, error rate, and queue depth?

A. Service monitoring

B. Data monitoring

C. Model fairness monitoring

D. Label monitoring only

Correct Answer: A. Service monitoring

Question 6

What is the primary purpose of a data contract?

A. To guarantee a model will be accurate

B. To define expectations for data structure and quality

C. To replace encryption

D. To eliminate the need for testing

Correct Answer: B. To define expectations for data structure and quality

Question 7

Which statement best describes concept drift?

A. The input schema has been renamed

B. The relationship between inputs and the target has changed

C. The model container has increased in size

D. The inference server has more memory

Correct Answer: B. The relationship between inputs and the target has changed

Question 8

Which control is most directly associated with limiting a service to only the permissions it needs?

A. Least privilege

B. Data augmentation

C. Prompt compression

D. Feature scaling

Correct Answer: A. Least privilege

Question 9

In a retrieval-augmented generation system, authorization should be applied before content is supplied to the model because:

A. It reduces tokenizer vocabulary

B. It prevents users from receiving documents they are not allowed to access

C. It guarantees factual answers

D. It removes the need for monitoring

Correct Answer: B. It prevents users from receiving documents they are not allowed to access

Question 10

Which statement about model retirement is correct?

A. Retirement is unnecessary if the model is accurate

B. Retirement is part of responsible lifecycle management

C. Retirement means deleting all audit records immediately

D. Retirement is the same as canary deployment

Correct Answer: B. Retirement is part of responsible lifecycle management