Task 2.3: Deploy machine learning models for production environments

• AMirror at most 50% to green while it takes no live traffic, and add a live share later

  Correct

  Mirroring is capped at 50%, and a deployment can't take live and mirrored traffic at once.

• BMirror 60% of requests to green and also route 5% of live traffic to green at the same time

  Incorrect

  The mirror cap is 50%, and green can't receive both kinds of traffic.

• CMirror 60% to green, since the cap applies only to Kubernetes online endpoints

  Incorrect

  The 50% cap applies to managed online endpoints like this one, so 60% can't be mirrored.

• DMirror 50% to green and also mirror 10% to a second deployment named orange

  Incorrect

  Traffic can be mirrored to only one deployment in an endpoint.

Traffic mirroring copies a share of live traffic to a deployment without changing what clients receive. The maximum mirrored share is 50%, which limits the effect on the endpoint's bandwidth quota; you can mirror to only one deployment; and a deployment receives either live or mirrored traffic, not both.

• ASet the azureml-model-deployment HTTP header to green

  Correct

  The header routes the request to that deployment, bypassing traffic rules.

• BCall the green deployment's own scoring URI, separate from the endpoint

  Incorrect

  Deployments are reached through the endpoint's URI, not their own.

• CSet green's traffic to 1% for the tester's session only

  Incorrect

  Traffic rules apply to everyone, not to one session.

• DAdd a query parameter deployment=green to the scoring URI

  Incorrect

  The documented mechanism is the HTTP header.

When you invoke an endpoint you can name the deployment that should receive the request, with --deployment-name in the CLI, deployment_name in the SDK, or the azureml-model-deployment HTTP header in a REST call. The request then bypasses the traffic control settings, so a deployment at 0% can still be tested.

• ARaise request_timeout_ms so that waiting requests aren't rejected during the bursts

  Incorrect

  A longer timeout doesn't raise the parallel request cap behind the 429.

• BAdd a CPU-based autoscale rule at 70%, which adds instances during the bursts

  Incorrect

  CPU never reaches 70%, so the rule wouldn't fire, and the per-instance setting is the bottleneck.

• CLower the deployment to one instance with a larger VM size and the same max_concurrent_requests_per_instance value

  Incorrect

  One instance with concurrency 1 allows only two requests in parallel.

• DRaise max_concurrent_requests_per_instance to 4, allowing up to 24 requests in parallel

  Correct

  The limit is 2 x max concurrency x instances, which is only 6 today.

For managed online endpoints, a 429 Too many pending requests means the model gets more requests than it can handle: at most 2 * max_concurrent_requests_per_instance * instance_count requests are processed in parallel and the rest are rejected. Review request_settings and scale_settings. With autoscaling, resend with exponential backoff while instances are added.

• AStudio and ARM templates can also create local endpoints

  Incorrect

  Only the Azure CLI and Python SDK support local endpoints.

• BA local endpoint supports only one deployment

  Correct

  Local endpoints are limited to one deployment per endpoint.

• CTraffic rules, authentication and probe settings aren't supported locally

  Correct

  These are listed limitations of local endpoints.

• DA registered model can be referenced by name locally without downloading it

  Incorrect

  Registered models must be downloaded and referenced by path.

• EDocker isn't needed; the deployment runs as a plain Python process

  Incorrect

  Local endpoints need Docker Engine installed and running.

Local endpoints run the deployment in a local Docker environment created by the Azure CLI or Python SDK; studio and ARM templates don't support them. They support one deployment per endpoint, no traffic rules, authentication or probe settings, and only local model files and a local conda file, so registered models must be downloaded first.

• AWithin the workspace only

  Incorrect

  Names are unique across the region, not just the workspace.

• BWithin the resource group only

  Incorrect

  Uniqueness is regional.

• CGlobally across all of Azure

  Incorrect

  The scope is the region.

• DWithin the Azure region

  Correct

  Only one endpoint can use a given name in a region.

Endpoint names must be unique within an Azure region. For example, in westus2 there can be only one endpoint named my-endpoint.

• ADelete the failed deployment; it might still incur charges

  Correct

  A failed deployment that passed compute creation can be billed.

• BNothing; failed deployments aren't billed once they've failed

  Incorrect

  Charges can accrue after compute is created.

• CScale it to zero instances and keep it

  Incorrect

  Deleting it is the documented step.

• DRestart the endpoint to release the compute

  Incorrect

  Restarting doesn't remove the deployment.

Managed online endpoints use VMs for deployments. If a deployment request failed after the stage where compute is created, the failed deployment incurs charges; delete failed deployments once you finish debugging to save cost.

• AA local endpoint with the --local flag

  Incorrect

  Local endpoints need Docker Engine.

• BA managed online endpoint in a dev workspace

  Incorrect

  That deploys to Azure instead of debugging locally.

• CThe Azure ML inference HTTP server Python package

  Correct

  It exposes the scoring function as a local HTTP endpoint without Docker Engine.

• DThe endpoint's Test tab in studio

  Incorrect

  That tests a deployed endpoint, not local code.

The Azure Machine Learning inference HTTP server is a Python package that exposes your scoring function as an HTTP endpoint. You can use it to debug the scoring script locally without Docker Engine, before deploying to local endpoints.

• Ainputs, as MLflow serving uses

  Incorrect

  MLflow's own server uses inputs; Azure Machine Learning uses input_data.

• Binput_data

  Correct

  Azure Machine Learning uses input_data to generate its Swagger contract.

• Cdataframe_split

  Incorrect

  That's an MLflow serving format, not the key here.

• Dpayload

  Incorrect

  That isn't the documented key.

The sample request for an MLflow no-code deployment uses the input_data key instead of inputs, which MLflow serving uses, because Azure Machine Learning needs a different input format to generate Swagger contracts for the endpoint automatically.