Free AI-300 practice test

Azure Machine Learning managed virtual networks support FQDN outbound rules, which allow outbound traffic to specific fully qualified domain names over HTTPS. Adding an FQDN rule for 'mcr.microsoft.com' is the correct and supported way to allow access to Microsoft Artifact Registry from a managed network with internet outbound blocked. Service tag outbound rules (option A) in managed networks are used for Azure service tags that represent Azure service IP ranges, not for container registry FQDN access; additionally, the 'MicrosoftContainerRegistry' service tag covers the data plane of Azure Container Registry, not MCR specifically. Private endpoint outbound rules (option C) are for private endpoints to your own Azure resources, not for public Microsoft endpoints. User-defined routes (option D) are not a concept within the Azure ML managed virtual network — UDRs apply to customer-managed VNets, not the managed network abstraction.

The correct command is 'az ml online-endpoint update' with the '--traffic' flag specifying deployment name/percentage pairs as a space-separated string. This updates the traffic allocation on the endpoint level. Option C is incorrect because traffic weights are managed at the endpoint level, not the deployment level; 'az ml online-deployment update' does not have a '--traffic-weight' flag. Option D is incorrect because 'az ml online-endpoint create' is for initial creation, not updating traffic, and '--traffic-split' is not the correct flag syntax. Option B confuses '--mirror-traffic', which is used for mirroring a percentage of traffic to a deployment for testing purposes without serving it to users, not for live traffic splitting.

For identity-based (credential-less) datastore access, two things are required: (1) the workspace's managed identity must be granted an appropriate data-plane role — 'Storage Blob Data Contributor' (or at minimum 'Storage Blob Data Reader') — on the storage account; and (2) the datastore must be registered with credential type 'none' so Azure ML uses the managed identity at runtime instead of a key or SAS token. Uploading an access key to Key Vault (option D) is used for key-based authentication, which contradicts the policy. Assigning 'Contributor' on the workspace to the storage account's service principal (option A) is backwards and irrelevant. Enabling the trusted services firewall exception (option E) may be needed for network access in certain configurations but is not a prerequisite for identity-based datastore authentication in a standard setup.

Azure Machine Learning registries are designed precisely for cross-workspace and cross-subscription asset sharing and migration. By creating a registry accessible to both subscriptions and promoting (copying) models, environments, and components into it, all teams in the new subscription can consume them immediately with full version history and metadata—no manual re-registration of each asset is needed. Option A (YAML export and re-registration) works but is highly manual and operationally expensive for large asset catalogs; it also does not preserve lineage. Option D (Azure Resource Mover) does not support Azure Machine Learning workspaces as a movable resource type in the same way—ML workspace migrations are not supported via Resource Mover, and even if they were, it would move the entire workspace rather than selectively migrating assets. Option B (storage account snapshot) would copy underlying artifact files but would not reconstruct the ML asset metadata, versioning, and registry entries that Azure ML uses to track models, environments, and components.

Setting allow_reuse=True on pipeline steps causes Azure ML to cache the output of each step keyed to its inputs and code. On a re-run (after fixing or retrying the failed step), all steps whose inputs and code are unchanged will be skipped and their cached outputs reused, so only the failed step re-executes. Option A would suppress the error and propagate incomplete data downstream, corrupting results. Option C is incorrect: Azure ML pipelines do not have a 'debug' mode that provides automatic step-level retry. Option B avoids the problem partially but introduces operational complexity and does not solve transient failures within a single pipeline run.

Changing the primary metric to AUC_weighted or average_precision_score_weighted ensures that Automated ML optimizes for a metric that is sensitive to the minority class performance, unlike accuracy which is dominated by the majority class. A model that predicts only non-default will score poorly on AUC or average precision. Enabling class_weight='balanced' in featurization affects how some learners handle class imbalance, but it does not fix the metric selection problem—accuracy will still reward the trivial classifier. Increasing experiment_timeout_minutes allows more iterations but does not change the optimization objective, so Automated ML may still select the trivially accurate model. Setting enable_early_stopping=False prevents early termination of individual model training but does not address the flawed metric choice.

Fairness assessment measures performance disparities across demographic or categorical subgroups (here, language subgroups), satisfying requirement 1. Interpretability (feature importance) surfaces global and local feature attribution scores, explaining which input features drive individual predictions, satisfying requirement 2. Error analysis identifies cohorts and input segments with the highest error rates, helping engineers find systematic failure modes, satisfying requirement 3. Counterfactual analysis generates what-if perturbations for individual instances to explain prediction boundaries but does not address group fairness or systematic error patterns. Data explorer provides statistical summaries and distributions of the dataset but is not an evaluation component for the three stated requirements. Causal analysis estimates causal treatment effects of features on outcomes, which is relevant for intervention planning but does not address fairness, feature attribution for predictions, or error cohort identification.

Azure Machine Learning model monitoring natively supports alert-based retraining triggers when monitored signals—such as data drift or prediction drift—exceed configured thresholds. Both data drift and prediction drift signals can fire Azure Monitor alerts that can be connected to retraining pipelines via webhooks or event-based triggers. A scheduled calendar interval is a valid retraining trigger, but it is implemented through Azure ML pipeline schedules or Azure Data Factory, not through the model monitoring system itself. A manual approval gate in Azure DevOps is a pipeline release management feature, not a monitoring-native retraining trigger. Request volume limits are not a built-in monitoring signal in Azure ML model monitors.

Options A, B, and C represent the canonical ML monitoring-based retraining triggers: (A) input data drift indicates the model may be operating outside its training distribution; (B) prediction drift indicates the model's behavior has changed, possibly due to concept drift; (C) degraded model quality (MAE above threshold) against ground truth directly measures production performance degradation. Option D (library update) is a dependency management/DevOps trigger, not a model performance trigger. Option E (decreased request volume) is a business KPI change, not an ML model quality signal — it may indicate reduced business activity rather than model degradation. Option F (new data partition) might warrant retraining but is a data governance decision, not a monitoring signal; it does not independently indicate the current model is degraded.

A managed online endpoint with a real-time deployment is designed for synchronous, low-latency, high-throughput scoring scenarios. A batch endpoint processes data asynchronously in bulk and is not suited for sub-100ms synchronous requests, even with a mini-batch size of one. A pipeline endpoint triggered by Azure Data Factory introduces orchestration overhead and is designed for workflow automation, not real-time inference. A serverless batch deployment with auto-scaling disabled would not handle high concurrency and introduces latency from batch scheduling.

To eliminate public internet exposure, you must both disable public network access (publicNetworkAccess: 'Disabled') so the service rejects requests arriving over the public endpoint, AND deploy a Private Endpoint so that the hub is reachable via a private IP address within the virtual network. Together these two settings enforce fully private connectivity. Option D (DDoS Protection) adds resilience against volumetric attacks but does not restrict public access to the resource itself. Option B (NAT gateway) controls outbound traffic from a subnet but does nothing to make the Foundry hub private. Option A (NSG allow-all on 443) would actually open inbound traffic rather than restricting it, the opposite of the requirement.

Scoping the 'Azure AI Developer' role to Department A's project resource grants the necessary permissions (model deployment, prompt flow management) within that project only, with no inherited access to other projects. Azure RBAC is additive and scoped, so a role assignment at the project level does not propagate to sibling projects. Option A is wrong because assigning the role at the hub scope grants access to all child projects, violating the isolation requirement. Option C is wrong because 'Contributor' at the hub scope also grants broad access, and deny assignments add unnecessary complexity and are not the recommended least-privilege approach. Option D is wrong because combining 'Reader' at hub scope with 'Owner' at project scope still provides read visibility across the hub's shared resources and 'Owner' is more permissive than needed.

Azure AI Foundry serverless API endpoints for foundation models do not natively support traffic-weight splitting between two model versions under a single endpoint in the way managed compute endpoints do. The correct approach is to deploy both versions as separate endpoints and use an API gateway such as Azure API Management to implement weighted routing policies, giving 10% traffic to the new version and 90% to the old. Option B describes a feature more aligned with managed compute endpoints for custom models, not serverless foundation model endpoints, where version-level traffic splitting is not directly available. Creating separate Foundry projects (option C) adds unnecessary management overhead and Azure Front Door is not an appropriate tool for this scenario. Azure Monitor (option D) provides observability, not traffic routing control.

Setting the managed virtual network isolation mode to 'Allow Only Approved Outbound' ensures that all outbound traffic from the hub is restricted to explicitly approved private endpoints for dependent services (Storage, Key Vault, etc.), preventing any traffic from reaching the public internet. 'Allow Internet Outbound' (option D) still permits general internet traffic, which violates the requirement. IP allowlists (option A) control inbound public access but do not prevent outbound traffic from traversing the internet. Placing the hub in a customer VNet without enabling the managed VNet feature (option B) does not automatically enforce private connectivity for dependent managed services.

The built-in groundedness evaluator in Azure AI Foundry measures whether the model's response is supported by the retrieved context. It requires the 'query' (user input), 'response' (model output), and 'context' (retrieved documents or passages) fields. 'ground_truth' is used by other evaluators such as the similarity or F1 evaluators, not groundedness. Option B is incorrect because groundedness does not compare against a ground-truth answer—it checks whether the response is grounded in the provided context. Option C omits the query, which is needed to frame what is being asked. Option D omits the response, leaving nothing to evaluate.

Fluency evaluates the grammatical correctness, natural phrasing, and readability of the generated text—exactly what the team needs to ensure responses do not feel machine-like. Groundedness (option B) checks factual support from context documents, not readability. Relevance (option C) measures whether the response answers the question, not how naturally it is phrased. Coherence (option D) measures logical flow and consistency across sentences, which overlaps somewhat but is distinct from surface-level grammatical fluency. For patient-facing naturalness, Fluency is the primary metric.

Relevance measures how well the model's response addresses the user's question or intent—it is query-centric and does not require external context documents. Groundedness (option D) measures whether the response is factually supported by retrieved context, not whether it answers the question. Coherence (option B) measures the logical flow and consistency of the response text. Fluency (option C) measures grammatical correctness and readability of the response. Only Relevance directly captures whether the answer is on-topic relative to what was asked.

Option B (oversampling or weighted sampling) is a standard technique to address class imbalance, ensuring the model trains on enough ICU examples to learn their patterns without discarding the majority class. Option D (synthetic augmentation with expert validation) is particularly valuable here — generating additional ICU note summaries using a capable LLM and validating them with clinical experts expands the rare class while maintaining quality. Option C is incorrect — removing 80% of training data would impoverish the model's ability to generalize and wastes most of the available data. Option E (uniform 256-token chunking) is a chunking strategy unrelated to class imbalance; clinical notes vary in length for valid reasons. Option A describes using a production-distribution test set, which would systematically underreport ICU performance — the test set should be stratified equally across note types to measure performance on both fairly, as stated in the problem's evaluation requirement.

When answers are incomplete because context is fragmented across chunks, the appropriate fix is to increase chunk size so that related content (e.g., a function signature plus its parameters and description) is contained in a single retrievable unit. Option B (smaller chunks) would worsen the fragmentation problem. Option A (lower threshold) would bring in more chunks but many would be less relevant, increasing noise rather than improving completeness. Option D (character-level chunking) is a granularity change unrelated to the contextual completeness problem and could introduce its own alignment issues with token-based embedding models.

Generating synthetic data (C) expands the training distribution and reduces overfitting caused by limited examples. Reducing the learning rate multiplier (A) prevents the model from memorizing the small training set, improving generalization. Increasing epochs significantly (D) on a small dataset worsens overfitting. Deduplication (E) is good practice but will further shrink an already limited dataset and does not help generalization directly here. Switching to a larger base model (B) does not inherently solve overfitting and may make it worse on a tiny dataset without other regularization.