AZ-204 Question #73: Real Exam Question with Answer & Explanation

Question

Case Study 1 - Litware Inc Background You are a developer for Litware Inc., a SaaS company that provides a solution for managing employee expenses. The solution consists of an ASP.NET Core Web API project that is deployed as an Azure Web App. Overall architecture Employees upload receipts for the system to process. When processing is complete, the employee receives a summary report email that details the processing results. Employees then use a web application to manage their receipts and perform any additional tasks needed for reimbursement. Receipt processing Employees may upload receipts in two ways: Uploading using an Azure Files mounted folder Uploading using the web application Data Storage Receipt and employee information is stored in an Azure SQL database. Documentation Employees are provided with a getting started document when they first use the solution. The documentation includes details on supported operating systems for Azure File upload, and instructions on how to configure the mounted folder. Solution details Users table Web Application You enable MSI for the Web App and configure the Web App to use the security principal name WebAppIdentity. Processing Processing is performed by an Azure Function that uses version 2 of the Azure Function runtime. Once processing is completed, results are stored in Azure Blob Storage and an Azure SQL database. Then, an email summary is sent to the user with a link to the processing report. The link to the report must remain valid if the email is forwarded to another user. Logging Azure Application Insights is used for telemetry and logging in both the processor and the web application. The processor also has TraceWriter logging enabled. Application Insights must always contain all log messages. Requirements Receipt processing Concurrent processing of a receipt must be prevented. Disaster recovery Regional outage must not impact application availability. All DR operations must not be dependent on application running and must ensure that data in the DR region is up to date. Security Users' SecurityPin must be stored in such a way that access to the database does not allow the viewing of SecurityPins. The web application is the only system that should have access to SecurityPins. All certificates and secrets used to secure data must be stored in Azure Key Vault. You must adhere to the principle of least privilege and provide privileges which are essential to perform the intended function. All access to Azure Storage and Azure SQL database must use the application's Managed Service Identity (MSI) Receipt data must always be encrypted at rest. All data must be protected in transit User's expense account number must be visible only to logged in users. All other views of the expense account number should include only the last segment, with the remaining parts obscured. In the case of a security breach access to all summary reports must be revoked without impacting other parts of the system. Issues Upload format issue Employees occasionally report an issue with uploading a receipt using the web application. They report that when they upload a receipt using the Azure File Share, the receipt does not appear in their profile. When this occurs, they delete the file in the file share and use the web application, which returns a 500 Internal Server error page. Capacity issue During busy periods, employees report long delays between the time they upload the receipt and when it appears in the web application. Log capacity issue Developers report that the number of log message in the trace output for the processor is too high, resulting in lost log messages. Application code Processing.cs Database.cs ReceiptUploader.cs ConfigureSSE.ps1 Drag and Drop Question You need to ensure disaster recovery requirements are met. What code should you add at line PC16? To answer, drag the appropriate code fragments to the correct locations. Each code fragment may be used once, more than once, or not at all. You may need to drag the split bar between panes or scroll to view content. NOTE: Each correct selection is worth one point. Answer:

Explanation

Explanation: Disaster Recovery Retry Policy (Line PC16)

Context

The code is using Polly, the .NET resilience and transient-fault-handling library. The goal is to implement a retry policy so that transient failures (e.g., brief regional outages) don't immediately surface as errors — satisfying the DR requirement that "regional outage must not impact application availability."

The completed line PC16 looks like this:

RetryPolicy retryPolicy = Policy.Handle<Exception>().Retry(3);

Placement 1: RetryPolicy

Role: Type declaration for the variable.

• In Polly, when you call .Retry(...) on a synchronous policy builder, the return type is RetryPolicy (or RetryPolicy<T> for typed results).
• You must declare the variable with this concrete Polly type so the compiler knows what kind of policy object is being stored.

Why not the others?

• Policy — the static class used to start building a policy (e.g., Policy.Handle<>()), not a variable type.
• RetryOptions — not a standard Polly type; a common distractor.
• ReconnectRetryPolicy — not a Polly type at all.

Placement 2: Retry(3)

Role: Builds the synchronous retry policy with 3 attempts.

• .Retry(3) tells Polly to retry the wrapped operation up to 3 times on failure before letting the exception propagate.
• This is synchronous, matching the surrounding synchronous processing code pattern.

Why not the others?

• WaitAndRetryAsync(3, i => TimeSpan.FromMilliseconds(100)) — async version with delay; would require await and an async context. Also over-engineered for what the question asks.
• CircuitBreaker(3, TimeSpan.FromMilliseconds(100)) — a different resilience pattern; it stops calling a failing service temporarily. Appropriate for preventing cascade failures, not for simply retrying transient errors.
• Retry(3); with a semicolon alone is a method call, not a type — it can't go in position 1.

Common Mistakes

Key Takeaway

For synchronous transient-fault retry in Polly: declare as RetryPolicy, terminate the builder with .Retry(n). This satisfies the DR requirement by transparently retrying operations that may fail briefly during a regional disruption — without requiring the application itself to be redesigned.

No community discussion yet for this question.