AI-200 sample questions — 25 answered and explained

az acr build runs a quick task: cloud build and push from a local or Git context.

ACR Tasks quick tasks move docker build into Azure. az acr build packs the current folder, sends it to the registry's task runner, builds it and pushes the tagged image to that registry. Import needs an existing image, docker build needs a local engine, and az acr run with --cmd runs a container rather than building one.

1. Note the constraint: no local Docker engine.
2. Identify the action: build from a Dockerfile, then push.
3. Choose the ACR Tasks quick-task command.

Exam tip: No Docker locally? az acr build builds and pushes in the cloud.

ACR Tasks builds for a target OS and architecture with --platform.

The quick task's --platform argument selects the target OS/architecture, for example linux/arm64, so the same Dockerfile is built for ARM64 without local emulation. A build argument such as TARGETARCH is only an input the Dockerfile can read; it doesn't change the platform the build runs for. Agent pools and import don't change the architecture either.

1. Identify the need: a different CPU architecture from the same Dockerfile.
2. Rule out options that only rename or copy the existing image.
3. Pick the argument that sets the target platform.

Exam tip: Cross-architecture image in ACR Tasks: az acr build --platform linux/arm64.

An ACR task can combine a source commit trigger with one or more timer triggers.

A task created from a GitHub context gets a commit trigger, which needs a personal access token so ACR can create the webhook. A timer trigger is added with --schedule and a five-field cron expression in UTC: minute, hour, day, month, day of week. "0 2 * * Sun" is 02:00 on Sundays. A six-field expression with seconds isn't supported, swapping the first two fields changes the time, and disabling the commit trigger drops half the requirement.

1. Map each requirement to a trigger: commit trigger and timer trigger.
2. Remember the commit trigger needs a Git access token.
3. Read the cron fields in order: minute, hour, day, month, weekday (UTC).

Exam tip: ACR Tasks cron = five fields, UTC; commit triggers need a Git token.

Base image update triggers track the runtime base image only, and poll public registries periodically.

Two facts decide this. First, ACR Tasks tracks base image updates only for the application (runtime) image, here aspnet:8.0, not for intermediate build-stage images such as sdk:8.0. Second, for base images in public Docker Hub or MCR repositories, ACR checks for updates at a random interval between 10 and 60 minutes; only base images in an Azure container registry trigger immediately. The trigger is enabled by default, and the task has already run once, so its dependencies are recorded.

1. Identify which FROM is the runtime base: the last stage.
2. Recall that build-stage images aren't tracked.
3. Recall the timing: public registries are polled every 10 to 60 minutes, ACR bases trigger immediately.

Exam tip: Base image triggers watch the final-stage FROM; public bases are polled, ACR bases fire at once.

A base image trigger needs one completed run to discover the image's dependencies.

ACR Tasks discovers base image dependencies dynamically while it builds. Until the task has built the image at least once, it has no record that the application depends on base/node:20, so a push to that tag queues nothing. Running the task once (for example with az acr task run) fixes it. The other options misstate defaults, timings or supported locations.

1. Check the defaults: base image trigger is on.
2. Check the location: same registry, so updates trigger immediately.
3. Notice the task never ran, so no dependency is recorded yet.

Exam tip: Run a new task once so it can learn its base image.

Base image triggers follow updates to the exact tag in FROM, so base images need stable tags.

A base image update trigger fires when the image behind the referenced tag changes. Publishing each patch under a new version tag never changes node:20.11.1, so nothing triggers. If the platform team also updates a stable tag such as node:20 with each patch and the application references it, every patch triggers a rebuild. A timer rebuild or import doesn't help because the Dockerfile still pins the old tag.

1. Ask what tag the Dockerfile references and whether it ever changes.
2. Recall that new version tags don't trigger base image updates.
3. Reference a stable tag that the base image maintainers move with each patch.

Exam tip: Base image triggers need a stable tag that moves; new version tags never fire them.

Composite indexes are traversed forwards or backwards: a definition works when it matches the ORDER BY or is its exact reverse, with the same path order.

For ORDER BY category ASC, price DESC, the index (category ascending, price descending) matches directly, and (category descending, price ascending) is the full reverse, which the engine reads backwards. Partially reversed definitions fail because the combined sort order differs, and swapping the path sequence fails because the first sort key changes.

1. Write down the ORDER BY sequence and directions.
2. Accept a definition with the same sequence and the same directions.
3. Also accept the definition with the same sequence and every direction flipped; reject partial flips and reordered paths.

Exam tip: A composite index serves an ORDER BY when it matches it exactly or is its exact reverse.

Session consistency gives read-your-writes for a client session at single-replica read cost.

The requirement is per-user: each writer must see its own writes. Session consistency provides exactly that through a session token while reading from one replica. Strong and Bounded Staleness read from two replicas and cost about twice as much per read. Consistent prefix and Eventual do not guarantee read-your-writes.

1. Identify whose reads need the guarantee: the user who wrote the data.
2. Map read-your-writes for a client to Session consistency.
3. Reject stronger levels that cost more and weaker levels that drop the guarantee.

Exam tip: Read-your-own-writes at the lowest cost = Session consistency (the default).

The account default can be relaxed per client or request; levels below Bounded Staleness read one replica and halve read RU.

Strong and Bounded Staleness reads use a local minority quorum of two replicas, so a read costs about twice as many RUs as at Session, Consistent Prefix or Eventual. The SDK can set a weaker level on the client the recommendations API uses, which leaves the account default and the payments service unchanged. Bounded staleness does not reduce cost, the multi-region write change is both a configuration change and incompatible with Strong, and autoscale does not change per-read cost.

1. Note the constraint: no account change, and only this API is affected.
2. Recall that read RU doubles at Strong and Bounded Staleness.
3. Relax consistency on this API's client to a single-replica level such as Session.

Exam tip: Lower one app's read cost under a Strong account: relax consistency on that app's client, below Bounded Staleness.

Session consistency is scoped to the session token; another client gets read-your-writes only if it presents that token.

The worker has its own client, so its session token cache has no record of the API's write and its reads behave like Eventual consistency for that partition. Forwarding the session token returned by the write and supplying it on the worker's read restores the read-your-writes guarantee without changing the account. Strong works but raises read cost for everyone, Consistent prefix is weaker, and retries are a best-effort workaround.

1. Notice that the writer and the reader are different clients.
2. Recall that Session guarantees follow the session token, which each client caches separately.
3. Share the token instead of raising the account-wide level.

Exam tip: Read-your-writes across processes under Session: pass the session token along with the work item.

The vector embedding policy describes each vector path: path, dataType, dimensions and distanceFunction.

Cosmos DB for NoSQL needs a container vector embedding policy (vectorEmbeddings) before VectorDistance can compare vectors. Each entry has a path, a data type (float32, float16, int8 or uint8), dimensions and a distance function (cosine, dotproduct or euclidean). The vector index in the indexing policy is optional and names only the path and index type.

1. List the settings asked for: path, dimensions, data type, metric.
2. Match them to the policy that describes vector data: the vector embedding policy.
3. Keep the indexing policy for the index type only.

Exam tip: Vector embedding policy = what the vectors are; vector index = how they are indexed.

Index choice depends on dimensions (flat ≤ 505; quantizedFlat and diskANN ≤ 4,096) and the number of vectors a search spans (quantizedFlat up to about 50,000).

The 3,072 dimensions rule out flat, whose limit is 505. Of the two remaining types, quantizedFlat is a brute-force search over quantized vectors with near-exact recall and is Microsoft's recommendation when 50,000 or fewer vectors are in scope. diskANN is approximate and pays off on larger sets. No index at all costs more per query.

1. Check the dimension count against each index type's limit.
2. Check how many vectors each search spans.
3. Pick the brute-force compressed index for a small set that needs near-exact recall.

Exam tip: Over 505 dimensions and up to about 50,000 vectors in scope: quantizedFlat.

The index decision follows the number of vectors a query spans after filters and partition scoping, not the container's total.

The tempting answer is diskANN because the container holds 6 million vectors. But every query is scoped to one tenant, so each search covers at most 15,000 vectors, well inside quantizedFlat's guidance of 50,000 or fewer. quantizedFlat is a brute-force search with near-exact recall and stable results, while diskANN is approximate and Microsoft notes its results can vary between runs. flat is ruled out by the dimension limit, and no index raises cost.

1. Work out how many vectors one query actually searches: the tenant's share, not the container total.
2. Apply the size guidance (quantizedFlat up to about 50,000 vectors in scope).
3. Check the remaining constraints: dimensions within limit, stable near-exact results.

Exam tip: Size the vector index by the vectors a filtered query spans, not by the container's total count.

In peek-lock mode a message that is never settled is redelivered when its lock expires, and the delivery count rises each time.

Processing succeeds, but the broker never hears about it. Each time the lock expires the message becomes available again and its delivery count increases; at the default maximum delivery count of 10 it is moved to the dead-letter subqueue with MaxDeliveryCountExceeded. Calling complete_message before closing the receiver fixes it. The other options would produce different reasons or no redelivery at all.

1. Match the reason code: MaxDeliveryCountExceeded means repeated deliveries.
2. Successful processing plus redelivery means settlement is missing.
3. Default max delivery count is 10, matching about ten deliveries.

Exam tip: Processed but redelivered until MaxDeliveryCountExceeded = the receiver never completes the message.

A subscription receives a message if any of its rules matches; new subscriptions start with a $Default rule whose filter is always true.

Rules on a subscription are evaluated independently and combine as OR: if any rule matches, the message is copied in. The $Default rule (a 1=1 true filter) created with the subscription therefore matches everything, so adding priority = 'high' alongside it changes nothing. Remove $Default (or create the subscription with the SQL filter as its default rule). The sys. prefix is for system properties, a correlation filter has the same OR problem, and sessions are unrelated.

1. New subscriptions come with a $Default true-filter rule.
2. Multiple rules combine as OR: any match copies the message.
3. So the narrowing rule only works once $Default is removed.

Exam tip: A subscription gets a copy if ANY rule matches; remove the $Default true filter before relying on your own filter.

Correlation filters handle exact-match conditions on message properties and are the more efficient filter type; SQL filters add expressions at higher cost.

Both conditions are equality checks on a system property (Subject) and an application property (region), which is exactly what a correlation filter expresses; Microsoft recommends correlation filters over SQL filters when they suffice because they are cheaper to evaluate at high volume. The SQL equality rule works but costs more, LIKE is both costlier and broader, and a rule action changes properties rather than selecting messages.

1. All conditions are exact equality.
2. Exact equality on properties is a correlation filter's job.
3. The efficiency constraint favours correlation over SQL.

Exam tip: Exact property matches: correlation filter (cheaper). Expressions, ranges, LIKE: SQL filter.

Service Bus sessions give ordered, exclusive processing per session ID, and they must be enabled when the queue or subscription is created.

Ordering per customer with parallelism across customers is the session pattern: senders put the customer ID in session_id, each worker accepts a session and holds an exclusive lock on that customer's messages, receiving them in order. Sessions are a creation-time setting, so the team needs a new session-enabled queue. Message ID is for de-duplication, and receive mode changes nothing about ordering.

1. Ordered per key + parallel across keys = sessions.
2. Sessions cannot be turned on for an existing queue.
3. The session key travels in session_id, not message_id.

Exam tip: Per-key FIFO in Service Bus = session_id on messages + a queue created with sessions enabled.

Service Bus duplicate detection drops messages whose application-set MessageId was already seen within a configurable history window.

With duplicate detection on, the queue records each MessageId for the history window (10 minutes by default, from 20 seconds up to 7 days) and silently drops any later message with the same ID; the send still reports success. It only works if the sender sets a deterministic MessageId such as the order ID, and it can only be enabled when the queue is created (Standard or Premium tier). Correlation and session IDs are not compared, and TTL does not de-duplicate.

1. The duplicates come from sender retries, so de-duplicate at the broker on enqueue.
2. Duplicate detection is a creation-time setting.
3. It compares only MessageId, so make it business-derived.

Exam tip: Broker-side de-duplication = duplicate detection enabled at creation + a deterministic message_id.

Scheduled messages are enqueued but stay invisible to receivers until their scheduled enqueue time.

ServiceBusSender.schedule_messages (or setting scheduled_enqueue_time_utc before send_messages) hands the message to the broker, which makes it available at the chosen UTC time and returns a sequence number that can cancel the schedule. Time-to-live controls expiry, deferral needs a receive first, and lock duration only applies once a message is received.

1. Requirement: the message must not be receivable until a known time.
2. Delayed availability at a known time is scheduling.
3. TTL, lock duration and deferral do not delay first delivery.

Exam tip: Deliver later at a known time: schedule_messages / scheduled_enqueue_time_utc.

Secret rotation in Key Vault is event-driven: SecretNearExpiry via Event Grid triggers your own rotation function.

Key Vault has no built-in generator for secret values. The documented pattern publishes SecretNearExpiry to Event Grid ahead of the expiration date; a subscribed function creates a new password, writes it as a new secret version and updates the database. Rotation policies are for keys, lifetime actions for certificates, and SecretNewVersionCreated reacts to a rotation rather than starting one.

1. Note the asset: a secret, not a key or certificate.
2. Secrets rotate through Event Grid plus custom code.
3. Choose the event that fires ahead of expiry.

Exam tip: Secrets: SecretNearExpiry -> Event Grid -> function that sets a new version and updates the target.

The near-expiry event needs an expiration date on the secret version; rotation functions also set the next one.

Key Vault publishes SecretNearExpiry ahead of a secret version's expiration date. A secret created without an expiration date never qualifies, so the event never fires and the function never runs, with nothing in the logs. Rotation samples create the secret with an expiry and have the function set a new expiry on each version it writes.

1. The function never ran, so the event was never delivered.
2. Ask what SecretNearExpiry is relative to: the version's expiration date.
3. Check whether the secret has one; without it no event fires.

Exam tip: No expiration date, no SecretNearExpiry event, no rotation.

Secret rotation needs both a trigger (SecretNearExpiry) and write permission for the rotating identity.

Event-driven rotation has two moving parts. The trigger is an Event Grid subscription for SecretNearExpiry, which Key Vault raises before the expiration date. The function then needs to write a new version, so its identity needs Key Vault Secrets Officer on an RBAC vault. Secrets User can't write, rotation policies are a key feature, and SecretNewVersionCreated fires after a version is stored, so it reports a rotation rather than starting one.

1. Identify the trigger that fires before expiry.
2. Identify the permission needed to write a new version.
3. Reject key-only features and events that fire only after a new version exists.

Exam tip: Rotation = SecretNearExpiry subscription + an identity that can set secrets.

Two-credential rotation alternates keys: regenerate the one not in use and publish it as the new version.

Resources with two credentials, like storage account keys, allow rotation without downtime. Successive secret versions alternate between key1 and key2: the function regenerates the alternate key (not the one in the latest version) and stores it as the new version. Apps still holding the previous version keep working for a full rotation cycle while they pick up the new key.

1. Note that the resource has two valid credentials.
2. Never regenerate the credential the apps are currently using.
3. Regenerate the alternate one and publish it as the new version.

Exam tip: With two keys, rotate the one not in use; apps then have a full cycle to switch.

Keys support native autorotation through a rotation policy; secrets don't.

Key Vault keys can have a rotation policy whose lifetime action rotates the key at a set time after creation (the interval must be at least seven days). Key Vault creates the new version itself, and services using a versionless key URI pick it up. An event-driven function is the pattern for secrets and adds code, expiry alone replaces nothing, and lifetime actions in certificate policies apply to certificates.

1. Note the asset type: a key, used as a CMK.
2. Keys have built-in rotation policies; no code is needed.
3. Reject the code-based and certificate options.

Exam tip: Keys rotate natively with a rotation policy; secrets need Event Grid plus a function.

Pick the rotation mechanism per object type: rotation policy for keys, event plus function for secrets.

Two facts decide this. Keys support a rotation policy, so the RSA key rotates with zero code. Secrets have no native generator; the password lives in the vendor's system, so a function triggered by SecretNearExpiry must change it there and store the new version. Writing functions for both works but adds code the team wanted to avoid, and the other options rely on policies that don't exist for secrets.

1. Classify each item: a key and a secret.
2. Use the native rotation policy wherever it exists (keys).
3. Use event-driven code only where it's unavoidable (secrets in external systems).

Exam tip: Least code: rotation policy for keys, SecretNearExpiry + function only for secrets.