AZ-204 Quality Control & Assurance 4 — Questions and Answers
Question 1: A developer needs to test how an Azure Service Bus consumer handles poison messages. What is the best practice in a test environment?
- Delete the dead-letter queue before each test run
- Send malformed messages and assert the consumer moves them to the dead-letter sub-queue after max delivery attempts (Correct answer)
- Set MaxDeliveryCount to 0 to disable retries
- Disable sessions on the queue to simplify testing
Correct answer: Send malformed messages and assert the consumer moves them to the dead-letter sub-queue after max delivery attempts
Intentionally sending invalid messages and verifying they land in the dead-letter queue validates the poison-message handling path without impacting production queues.
Question 2: Which Azure Cosmos DB feature helps you validate that changes to your data model do not break existing queries before deploying to production?
- Automatic indexing policy validation via the Azure portal query explorer (Correct answer)
- Point-in-time restore
- Multi-region writes
- TTL (Time to Live) configuration
Correct answer: Automatic indexing policy validation via the Azure portal query explorer
The Azure portal's Data Explorer lets you run queries against a copy of your container with a new indexing policy to verify correctness before applying changes.
Question 3: When writing integration tests for an Azure SQL Database, which approach best isolates each test from side effects of other tests?
- Use a shared connection string across all tests without transactions
- Wrap each test in a transaction and roll it back in teardown (Correct answer)
- Delete all rows after every test class
- Run tests sequentially on the production database
Correct answer: Wrap each test in a transaction and roll it back in teardown
Wrapping each test in a transaction that is rolled back on teardown ensures the database returns to a clean state without permanently modifying data.
Question 4: You need to enforce that no NuGet package with a known critical vulnerability is used in your Azure DevOps build. Which component enables this?
- Azure Artifacts upstream sources with a vulnerability deny list
- A pipeline task running 'dotnet list package --vulnerable' and failing on critical findings (Correct answer)
- Azure Policy applied to the subscription
- Setting PackageReference versions to '*' in .csproj
Correct answer: A pipeline task running 'dotnet list package --vulnerable' and failing on critical findings
'dotnet list package --vulnerable' queries NuGet security advisories and the pipeline task can be scripted to exit with a non-zero code if critical vulnerabilities are found.
Question 5: In Azure Application Insights, what does 'Sampling' do and why is it relevant to QA?
- Sampling deletes telemetry older than 30 days to reduce storage costs
- Sampling reduces the volume of telemetry ingested by keeping a representative subset, which can mask infrequent errors in QA analysis (Correct answer)
- Sampling compresses log messages to reduce bandwidth
- Sampling only applies to availability test results
Correct answer: Sampling reduces the volume of telemetry ingested by keeping a representative subset, which can mask infrequent errors in QA analysis
Adaptive or fixed-rate sampling discards a percentage of telemetry, so rare error events may not appear in reports, which is important to understand when analyzing QA results.
Question 6: Which HTTP status code returned by an Azure API Management policy or backend signals that a request was throttled, and how should an automated test assert this?
- 400 Bad Request — assert response body contains 'throttle'
- 429 Too Many Requests — assert the response status code equals 429 (Correct answer)
- 503 Service Unavailable — assert Retry-After header is present
- 401 Unauthorized — assert WWW-Authenticate header
Correct answer: 429 Too Many Requests — assert the response status code equals 429
HTTP 429 is the standard throttling response; tests should assert on the exact status code to confirm rate-limit policies are enforced correctly.
Question 7: A QA engineer wants to validate that an Azure Event Grid subscription delivers events to a webhook endpoint within an SLA of 5 seconds. What is the most practical testing strategy?
- Monitor Event Grid metrics in production only
- Publish a test event and measure the elapsed time until the webhook receives the callback, failing if it exceeds 5 seconds (Correct answer)
- Check Event Grid Dead Letter storage after 24 hours
- Use Event Grid's built-in latency guarantee without testing
Correct answer: Publish a test event and measure the elapsed time until the webhook receives the callback, failing if it exceeds 5 seconds
Publishing a synthetic event from a test harness and timestamping webhook receipt provides an end-to-end latency measurement that can be asserted against the SLA threshold.
AZ-204 Quality Control & Assurance 4
A developer needs to test how an Azure Service Bus consumer handles poison messages.
What is the best practice in a test environment?