Free Practice Questions for Microsoft AI-200 Exam

Detailed Explanation: Azure Key Vault references in App Service settings satisfy the requirement to keep secrets out of container images, source control, and directly stored application configuration. App Service resolves the referenced secret at runtime by using the app identity, so the application can consume the value as a normal setting without embedding credentials in the image. GitHub secrets are build/deployment secrets rather than a runtime App Service secret-delivery mechanism. Dockerfile ENV instructions would place secret material in the image configuration and violate the case requirements.

Study Guide Alignment: Security and operations: Key Vault, App Configuration, managed identity, OpenTelemetry, Azure Monitor, and KQL-based troubleshooting.

Official Microsoft Learn References: AI-200 Study Guide | Use Key Vault references for App Service and Functions | Managed identities for Azure resources

Strong consistency is required for the patient-status scenario because it provides linearizability : reads return the latest committed value. This is the appropriate guarantee when updates can originate from different locations and the application must never return an older patient status. Microsoft defines Strong as the highest Azure Cosmos DB consistency level and notes that it provides the strongest freshness guarantee, at the cost of greater latency and reduced availability compared with weaker models.

For health-monitoring data, Bounded Staleness is the intended consistency level. It explicitly limits how far reads can lag behind writes using a maximum number of versions (K) or a time interval (T). Conceptually, this matches a requirement that data may be current or only a limited number of versions behind.

For finalized billing data, Eventual consistency provides the lowest latency and highest availability. Once discharge processing is complete and no further billing writes occur , replicas eventually converge on the same final value. Microsoft specifically notes that, in the absence of further writes, weaker consistency levels ultimately yield the same converged data.

Azure Cosmos DB also permits requests to relax consistency below an account ' s Strong default , which is exactly the optimization pattern described here.

Study Guide references: Azure Cosmos DB for NoSQL → Strong consistency; Bounded Staleness; Eventual consistency; per-request consistency override; latency/availability trade-offs.

Use where , join , and summarize .

The where operator filters telemetry to the required scope, including records from the last hour and failed requests. For example, a predicate can restrict timestamp > ago(1h) and request success status in the same filtering expression.

Next, use join to correlate request telemetry with dependency telemetry. Application Insights assigns related telemetry a common operation_Id , and Microsoft specifically demonstrates joining the dependencies and requests tables on operation_Id to identify dependency calls associated with requests.

Finally, use summarize with avg(duration) grouped by the appropriate operation identifier or operation name. summarize performs aggregation over groups and is therefore the required operator for calculating average dependency duration. Microsoft documents dependency duration as supporting an Avg aggregation.

extend is unnecessary because no derived column is required, while distinct merely removes duplicate rows and cannot calculate averages or correlate two telemetry tables.

A representative structure is:

requests

| where timestamp > ago(1h) and success == false

| join (dependencies | where timestamp > ago(1h)) on operation_Id

| summarize avg_dependency_duration = avg(duration1) by operation_Name

Study Guide references: Azure Monitor Application Insights; KQL where; telemetry correlation using operation_Id; join; summarize; dependency duration analysis.

Use GitHub Actions because Proseware requires an automated, version-controlled deployment pipeline and explicitly prohibits local and command-line deployments. Microsoft documents GitHub Actions as a supported CI/CD mechanism for Azure Functions: a workflow stored under .github/workflows can build and deploy Function app code automatically in response to repository events such as pushes or pull requests. The Azure Functions deployment action can deploy the application package directly to the target Function app.

GitHub Actions also satisfies the infrastructure requirement. Microsoft provides first-class support for deploying Bicep templates through GitHub Actions , enabling Azure resources to be provisioned declaratively from the same source-controlled pipeline. A pull-request workflow can perform validation or Bicep what-if analysis before changes are merged, while a main-branch workflow can perform the actual deployment after approval. This provides repeatability, auditing, and separation from individual developer machines.

Azure Functions Core Tools and Azure CLI are commonly used for interactive/local deployments, which directly conflicts with the requirement to eliminate command-line deployment. Local Git deployment also fails the requirement for a centrally automated Bicep-based deployment process.

Study Guide references: Azure Functions CI/CD; GitHub Actions; infrastructure as code with Bicep; automated Azure deployments; version-controlled deployment workflows.

Detailed Explanation: The objective is to reduce RU consumption from vector similarity queries. Microsoft guidance identifies vector numeric precision and vector-index selection as major cost and performance levers. Using a lower supported vector precision can reduce storage and processing cost, while quantizedFlat and DiskANN are designed to reduce latency and RU consumption compared with flat search for appropriate data sizes. Strong consistency would increase resource cost rather than solve vector-search efficiency. A regular composite index is not a substitute for the vector index. Option B should be read as reducing vector numeric precision, not changing a generic “indexing precision” setting.

Study Guide Alignment: AI data-management workloads: Cosmos DB, PostgreSQL, caching, vector storage, vector retrieval, consistency, and connection optimization.

Official Microsoft Learn References: AI-200 Study Guide | Vector search in Azure Cosmos DB | Optimize Cosmos DB vector search performance

Configure deployment-level Tokens-per-Minute (TPM) and Requests-per-Minute (RPM) rate limits for the Azure OpenAI model deployment. Azure OpenAI quota is allocated to individual model deployments in TPM units, and Microsoft documents that the TPM assigned to a deployment directly maps to the rate limit enforced for inference requests against that deployment. An associated RPM limit is also enforced according to the model ' s TPM-to-RPM ratio.

Because all application users invoke the same deployment, this enforcement occurs at the deployment boundary rather than independently for each end user. Once request traffic would exceed the configured capacity, Azure applies throttling rather than allowing unrestricted token consumption. Microsoft Foundry additionally supports explicit token-management controls through AI Gateway, where a TPM limit can be set for a model deployment; requests exceeding the limit receive HTTP 429 Too Many Requests responses.

Content filtering governs safety categories, not consumption. An Azure AI Search vector-index limit controls search storage rather than generated tokens. Temperature changes sampling randomness and has no enforcement role in rate or cost control.

Study Guide references: Azure OpenAI quota management; TPM/RPM rate limits; deployment capacity; throttling; Foundry AI Gateway token management.

===============

Trigger for container images build: Base image update

Implementation of image builds: ACR Task

The correct trigger is Base image update because Proseware requires every custom container image to be rebuilt automatically whenever its Docker Hub base image changes. Azure Container Registry Tasks can detect base-image dependencies from the Dockerfile FROM instruction and automatically trigger a rebuild when that base image is updated. Microsoft confirms that ACR Tasks can track base images in public repositories such as Docker Hub and Microsoft Container Registry, as well as images stored in Azure Container Registry.

The build implementation must be an ACR Task . This directly satisfies the technical requirement that image-build automation run inside Azure Container Registry , eliminating dependencies on local developer machines or separate external build services. ACR Tasks provides cloud-based container building and can automate builds based on source-code commits, base-image updates, or scheduled triggers.

A GitHub workflow could orchestrate CI/CD, but using it as the actual image-building implementation would conflict with the explicit requirement that builds execute inside ACR. Docker Compose defines multi-container applications; it is not the native ACR build automation mechanism. A Commit trigger addresses source changes rather than the stated base-image update requirement, while Scheduled builds would introduce unnecessary periodic execution.

Study Guide references: Azure Container Registry Tasks; base-image dependency tracking; automated rebuilds; Docker Hub base-image triggers; cloud-native container builds.