Near-Right Architecture — Azure AI Engineer (AI-300)
Two options were architecturally valid — you picked the one that violates a constraint buried in the scenario. Read constraints before evaluating answers.
Technically Sound Isn't the Same as Exam Correct
Routing real-time inference traffic through Azure Event Hubs before hitting a model endpoint is defensible—Event Hubs handles high-throughput ingestion and decouples producers from consumers. The problem is that the scenario's governing constraint is latency, not throughput. An asynchronous buffer adds round-trip time the requirement explicitly rules out. The distractor works architecturally. It fails professionally. The exam tests the latter.
The Scenario
The question asks you to design a globally distributed web application with real-time bidirectional communication via WebSockets. Two options: Azure Front Door with backend pools, or Traffic Manager with regional Application Gateways. Both achieve global distribution. But Front Door operates at Layer 7 with HTTP/HTTPS — it supports WebSocket connections. Traffic Manager is DNS-based and does not proxy traffic at all, so it cannot maintain WebSocket connections across failovers. The trap is that Traffic Manager sounds like the "global load balancer" answer, but it only does DNS resolution, not connection proxying.
How to Spot It
- •Azure Front Door vs. Traffic Manager is a Layer 7 vs. DNS-level distinction. If the scenario needs connection proxying, SSL offloading, or WebSocket support, Traffic Manager is eliminated. If it only needs DNS-based routing with health probes, Front Door may be over-engineering.
- •Pay attention to "real-time," "bidirectional," or "persistent connections." These require a proxy-based load balancer (Front Door, Application Gateway), not DNS-only routing (Traffic Manager).
- •When both architectures distribute traffic globally, the tiebreaker is always in the connection semantics — HTTP request-response vs. persistent connections vs. raw TCP.
Decision Rules
Whether to add the new model version as a second named deployment under the existing Azure ML managed online endpoint and shift traffic via percentage-based allocation rules, versus provisioning a separate managed online endpoint for the new version and routing traffic through an external load balancer or DNS swap.
Whether to register the new model version as a named deployment behind the existing Azure Machine Learning managed online endpoint and control exposure via traffic-weight percentages, versus deploying to a separate endpoint resource that isolates the new version but routes rollback through DNS or application-layer URL changes that cannot satisfy a sub-minute SLA.
Whether to centralize curated environment definitions in Azure Machine Learning Registries for cross-workspace promotion, or distribute Conda YAML specs via Azure Blob Storage and recreate environments locally in each workspace.
Whether workspace-local model registration is sufficient or whether a cross-workspace Azure Machine Learning Registry with lifecycle-stage gating is required to satisfy the cross-team lineage and promotion governance constraint.
Whether the chosen evaluation configuration satisfies evaluation-coverage-completeness by covering all explicitly required dimensions—groundedness and safety—or addresses only one dimension such as fluency, which looks correct but fails the dominant constraint.
Whether to trigger retraining through an Azure Machine Learning dataset monitor that fires only when drift coefficient exceeds a threshold, or through a fixed-schedule Azure Machine Learning Pipeline that retrains on a calendar interval regardless of actual drift magnitude.
Select multi-node distributed training on a right-sized Azure Machine Learning Compute cluster over a single oversized GPU VM when the combined dataset volume and time SLA require aggregate data-ingestion and compute throughput that a single node cannot deliver within budget.
Whether to store and version prompt templates in a Git repository with CI-enforced, reviewer-gated promotion (satisfying both reproducibility via commit SHA and auditability via PR approval history) or to adopt a near-right alternative such as Azure Blob Storage with versioning tags or an Azure Machine Learning prompt catalog that provides artifact retention and version identifiers but lacks native diff history, branch isolation, and reviewer-attribution workflows.
Whether to scope RBAC role assignments at the shared workspace level (near-right: role is ML-specific but grants cross-project access) or at the project-specific resource group and associated storage account level (correct: satisfies per-project least-privilege isolation).
Determine whether the IaC deployment configuration correctly layers both the network isolation boundary (private endpoint with publicNetworkAccess disabled) and the identity boundary (managed identity RBAC scoped to workspace resource group), versus a near-right option that satisfies only one of the two required boundaries.
Whether to scope the Contributor role assignment to the Foundry project resource group or to the broader subscription — only resource-group scope satisfies least-privilege, because subscription-scope Contributor grants write access to every resource in the subscription regardless of project membership.
Domain Coverage
Difficulty Breakdown
Related Patterns