6.3. Practice Questions

Twenty questions, organized by official exam domain and weighted like the real thing. Answer before reading the rationale — the explanation of why the wrong answers are wrong is where the learning lives.

Domain 1: Develop Containerized Solutions on Azure

Q1. Your team's images build FROM python:3.12-slim. Security requires that when the upstream base image is patched, your dependent images rebuild automatically — without introducing an external CI system. What should you configure?

• A. A scheduled ACR task that rebuilds nightly
• B. An ACR task with a base image update trigger
• C. A webhook from Docker Hub to an Azure Function that calls az acr build
• D. GitHub Actions with a cron workflow

Answer: B. ACR Tasks natively track the FROM line and rebuild when the base image changes (3.1.2). A rebuilds on a schedule, not on the patch event — you could run vulnerable for a day, or rebuild pointlessly. C hand-builds what B provides natively. D is an external CI system, which the scenario excludes.

Q2. You deploy a FastAPI container listening on port 8000 to App Service. The container starts, logs show no errors, but every request times out. What fixes it?

• A. Scale the App Service plan up one tier
• B. Enable Always On
• C. Add a health-check endpoint to the container
• D. Set the WEBSITES_PORT app setting to 8000

Answer: D. App Service assumes port 80; WEBSITES_PORT declares the container's actual listening port (3.1.3). A treats a wiring problem with capacity. B keeps instances warm but doesn't route traffic. C improves observability without touching the routing mismatch.

Q3. A Container App reads an API key from a secret. You update the secret's value, but running replicas keep using the old key. Why?

• A. Secrets are application-scope changes — no new revision is created; restart the revisions
• B. Secret changes create a new revision, but traffic is still weighted to the old one
• C. The KEDA scaler caches secret values until the next scale event
• D. Secrets are immutable in Container Apps and require a new secret name

Answer: A. Secrets are app-scope: updated in place, no revision minted, and running revisions read secrets at startup (3.2.1). B describes revision-scope behavior — image or env-var changes. C invents a scaler behavior; KEDA uses secrets for its connections but doesn't gate app config. D is false — values are updatable; consumers just must restart.

Q4. Embedding workers process a Service Bus queue in Container Apps. Overnight the queue is empty; at 9 a.m. thousands of messages arrive. Costs must be zero when idle and processing must keep up with bursts. Which scale configuration is correct?

• A. HTTP scale rule, min replicas 1, max 30
• B. CPU utilization rule at 70%, min replicas 0
• C. KEDA azure-servicebus rule on queue length, min replicas 0, max 30
• D. KEDA cron rule scaling to 30 replicas during business hours

Answer: C. Queue length is the leading signal, and event-driven rules support scale-to-zero (3.2.2). A scales on web traffic the workers don't receive, and min 1 violates zero-idle-cost. B: queue consumers idle at low CPU while backlog grows — and CPU rules can't scale to zero. D burns 30 replicas whether or not messages exist.

Q5. An AKS pod shows CrashLoopBackOff. kubectl logs pod-name returns only a normal startup banner. What is the next diagnostic command?

• A. kubectl describe node
• B. kubectl logs pod-name --previous
• C. kubectl delete pod pod-name
• D. kubectl get events --watch

Answer: B. The crash evidence died with the previous container instance; --previous retrieves its logs (3.2.4). A inspects node capacity — a Pending diagnosis, not a crash loop. C destroys evidence and changes nothing. D shows restart events you already know are happening, not the crash reason.

Domain 2: Develop AI Solutions by Using Azure Data Management Services

Q6. A chat API retrieves a conversation document; the code has both the document's id and its partition key. Which retrieval minimizes RU cost?

• A. query_items with WHERE c.id = @id scoped to the partition
• B. query_items with cross-partition mode enabled
• C. read_item(item=id, partition_key=pk)
• D. query_items with a composite index on id and partition key

Answer: C. A point read is ~1 RU for a 1 KB item — the cheapest operation in Cosmos DB (2.1.1). A works but engages the query engine, costing several times more. B adds fan-out cost for no reason. D optimizes a query you shouldn't be running.

Q7. A chat application requires that each user immediately sees their own sent messages, at the lowest possible RU cost. Which consistency level fits?

• A. Session
• B. Strong
• C. Bounded staleness
• D. Eventual

Answer: A. Session guarantees read-your-own-writes within the session token at 1x read cost — precisely the stated requirement (2.1.2). B and C satisfy the requirement but at double the RU and added latency — the works-but-wasteful distractor. D is cheap but can't guarantee the user sees their own message.

Q8. After adding 1536-dimension embeddings to documents in a Cosmos DB container, write RU charges tripled. Queries never filter on the embedding property. What's the fix?

• A. Switch the container to autoscale throughput
• B. Reduce embeddings to 768 dimensions
• C. Change consistency from session to eventual
• D. Add /embedding/* to excludedPaths in the indexing policy

Answer: D. The default policy indexes every path — including a huge float array — inflating every write; the vector index is a separate mechanism, so exclusion costs nothing (2.1.3). A changes billing shape, not per-write cost. B halves the waste instead of eliminating it, and degrades embedding quality. C affects read cost, not write cost.

Q9. Your pipeline uses the Cosmos DB change feed to keep a vector store synchronized. Documents deleted from the source container remain searchable in the vector store. Why, and what's the standard fix?

• A. The lease container is misconfigured; recreate it
• B. The change feed doesn't expose deletes; use a soft-delete flag (with TTL) that arrives as an update
• C. The change feed batches deletes; reduce the poll interval
• D. Deletes require strong consistency to appear in the feed

Answer: B. Deletes never appear in the change feed by design; soft delete converts them into observable updates (2.1.4). A would stall all processing, not just deletes. C and D describe behaviors that don't exist — the feed omits deletes at any interval and any consistency level.

Q10. A team created an IVFFlat index on an empty chunks table, then bulk-loaded 5 million embeddings. Similarity searches are fast but miss obviously relevant documents. What should they do?

• A. Rebuild the index now that the data is loaded
• B. Raise max_connections to allow more parallel searches
• C. Switch the query operator from <=> to <->
• D. Move the database to a Burstable tier with more storage

Answer: A. IVFFlat computes its clusters from data present at build time; an empty-table build yields meaningless clusters and poor recall (2.2.3). B addresses throughput, not recall. C changes the distance metric — and mismatching the index opclass would bypass the index entirely. D is a sizing change pointed away from the problem.

Q11. After a KEDA scale-out to 30 workers, PostgreSQL begins refusing connections and vector query latency spikes. Which change fixes both symptoms?

• A. Raise max_connections to 1000
• B. Add a read replica for the workers
• C. Route workers through PgBouncer on port 6432
• D. Upgrade to a higher-vCPU General Purpose SKU

Answer: C. Pooling multiplexes worker connections onto few server processes, ending refusals and protecting the RAM the vector index needs (2.2.5). A spends that same RAM on connection overhead — latency worsens. B adds read capacity but each replica still faces unpooled storms. D buys headroom without fixing the connection-per-worker pattern.

Domain 3: Connect to and Consume Azure Services

Q12. Uploaded documents must each be processed exactly once from a business perspective, must survive worker crashes, and processing may take minutes. Which transport is correct?

• A. Event Grid custom topic with a webhook handler
• B. Redis list consumed by workers
• C. Cosmos DB change feed on an uploads container
• D. Service Bus queue with peek-lock and idempotent consumers

Answer: D. This is a command with a processing obligation: peek-lock custody, lock-expiry redelivery, DLQ quarantine, and idempotency for the at-least-once duplicates (4.1.1). A pushes facts with 24h best-effort retry — not a work queue. B has no lock/redelivery semantics; a crashed worker loses the popped item. C only works if uploads already land in Cosmos DB and still lacks per-message custody.

Q13. Blob-created events must notify three independent systems, but only for .pdf files in the /contracts container. Where does the filtering belong?

• A. Subject and suffix filters on each Event Grid subscription
• B. An Azure Function that receives all events and discards non-matching ones
• C. A Service Bus topic with a single subscription per system
• D. Storage lifecycle rules that move PDFs to a monitored container

Answer: A. Subscription filters (subject begins-with /contracts, suffix .pdf) deliver only relevant events, keeping publisher and consumers decoupled (4.1.2). B pays an invocation for every event just to throw most away — filtering in code is the anti-pattern the feature exists to remove. C re-platforms facts onto the message species and still needs filter logic. D contorts storage design to simulate routing.

Q14. A malformed message repeatedly crashes queue consumers, and the queue has stopped draining. Which mechanism quarantines it, and what must you remember afterward?

• A. Duplicate detection removes it; nothing further needed
• B. MaxDeliveryCount moves it to the DLQ; a separate process must explicitly read and resolve DLQ messages
• C. TTL expiry discards it; increase TTL for valid messages
• D. The DLQ auto-replays it once consumers are patched

Answer: B. Each crash abandons the message; after the delivery-count ceiling it dead-letters, unblocking the queue — and the DLQ is drained only by an explicit receiver (4.1.1). A dedupes by message ID, unrelated to poison handling. C would eventually discard it but also silently discards delayed valid work. D is the feature-that-doesn't-exist distractor.

Q15. A function triggered by Service Bus messages must load one Cosmos DB document whose id arrives in the message payload, then write a result document. The team wants minimal SDK code. What's the right structure?

• A. Two functions: one HTTP-triggered for the read, one queue-triggered for the write
• B. A single function using the Cosmos SDK for both operations
• C. A Service Bus trigger plus a Cosmos DB input binding using a {msg.docId} binding expression and a Cosmos DB output binding
• D. A Service Bus trigger plus two Cosmos DB input bindings

Answer: C. One trigger, declarative input via binding expression, declarative output — zero SDK plumbing (4.2.1). A splits one workflow across two entry points for no reason. B works but is exactly the boilerplate bindings eliminate. D misuses an input binding for a write; outputs need an output binding.

Q16. An interactive chat API runs on Functions. Users complain the first request after quiet periods takes 6+ seconds; the fix must also allow VNet integration. Cost is secondary. Which plan?

• A. Consumption with more instances
• B. Dedicated plan with autoscale disabled
• C. Consumption with a timer trigger pinging every 5 minutes
• D. Premium with pre-warmed instances

Answer: D. Premium eliminates cold starts via pre-warmed minimum instances and supports VNet integration (4.2.2). A: every Consumption instance still starts cold. B avoids cold starts but sacrifices event-driven scaling and is the blunt-instrument answer. C is the folk remedy — unreliable, and it doesn't provide VNet integration.

Domain 4: Secure, Monitor, and Troubleshoot Azure Solutions

Q17. Compliance requires database credentials to rotate every 90 days with no application redeployment. Which architecture satisfies this?

• A. Store credentials in App Configuration and update them quarterly
• B. Key Vault secret with a SecretNearExpiry Event Grid subscription triggering a rotation Function; apps fetch the latest version via managed identity
• C. Enable Key Vault's automatic secret rotation policy
• D. Bake credentials into the container image and rebuild quarterly via ACR Tasks

Answer: B. Rotation for secrets is assembled automation: near-expiry event → Function → new credential in the target + new secret version; latest-version fetch means no redeploy (5.1.1). A puts a secret in the settings binder — wrong container, no audit. C exists for keys, not secrets. D is the leaked-credential anti-pattern with extra automation.

Q18. Ten microservices share non-secret settings and feature flags, but also need a database connection string. What's the correct arrangement?

• A. Everything in Key Vault; services read settings and secrets uniformly
• B. Everything in App Configuration for a single configuration surface
• C. Settings and flags in App Configuration; the connection string in Key Vault, exposed through a Key Vault reference in App Configuration
• D. Settings in App Configuration; the connection string duplicated into each service's app settings

Answer: C. Each substance in its container, connected by a reference — apps read one surface while the secret stays vaulted and audited (5.1.2). A drags every TopK=10 read through vault throttling and audit noise. B stores a secret in the binder — the section's core misconception. D re-creates the sprawl (ten copies to rotate) that centralization exists to end.

Q19. Traces show a request entering the API and orchestrator, but work done by queue-triggered workers appears as unrelated new traces. What restores end-to-end correlation?

• A. Propagate W3C trace context in Service Bus message application properties and restore it in the consumer
• B. Increase the sampling rate to 100%
• C. Add the worker's Application Insights connection string to the API
• D. Log the queue message ID in both services

Answer: A. Queues don't carry HTTP headers; context must ride in message properties or the trace breaks exactly at the async boundary (5.2.1). B records more of the same broken traces. C points telemetry at a destination — correlation is about context, not destination. D enables manual archaeology, not trace correlation.

Q20. Which KQL query correctly charts hourly p95 dependency latency for the chat endpoint over the last day?

• A. render timechart | dependencies | where timestamp > ago(1d) | summarize percentile(duration, 95)
• B. summarize percentile(duration, 95) by bin(timestamp, 1h) | dependencies | where operation_Name == "POST /chat"
• C. dependencies | summarize percentile(duration, 95) | where timestamp > ago(1d) | render timechart
• D. dependencies | where timestamp > ago(1d) and operation_Name == "POST /chat" | summarize percentile(duration, 95) by bin(timestamp, 1h) | render timechart

Answer: D. Table first, filter early, aggregate with time bins, render last — the assembly line in order (5.2.2). A and B start with an operator instead of the table — invalid by construction. C aggregates before filtering, so the summarize consumes all history and the subsequent where filters a column that no longer exists.