Case Study
This is a case study. Case studies are not timed separately. You can use as much exam time as you would like
to complete each case. However, there may be additional case studies and sections on this exam. You must
manage your time to ensure that you are able to complete all questions included on this exam in the time
provided.
To answer the questions included in a case study, you will need to reference information that is provided in the
case study. Case studies might contain exhibits and other resources that provide more information about the
scenario that is described in the case study. Each question is independent of the other question on this case
study.
At the end of this case study, a review screen will appear. This screen allows you to review your answers and to
make changes before you move to the next sections of the exam. After you begin a new section, you cannot
return to this section.
To start the case study
To display the first question on this case study, click the Next button. Use the buttons in the left pane to explore
the content of the case study before you answer the questions. Clicking these buttons displays information such
as business requirements, existing environment, and problem statements. If the case study has an All
Information tab, note that the information displayed is identical to the information displayed on the subsequent
tabs. When you are ready to answer a question, click the Question button to return to the question.
Background
You are a developer for Fabrikam, a company that specializes in payment processing. Fabrikam is developing
a solution to process payments for various events, such as music concerts. You develop an ASP.NET MVC
website that is hosted in Azure to support an upcoming music concert. The music concert is expected to
generate a large volume of ticket sales in a short amount of time.
The website uploads information to an Azure storage queue. A worker role in Azure retrieves information from
the queue and generates the concert tickets in a PDF file format after the financial transaction is approved.
You observe a delay between the time the website adds a message to a queue and the time it becomes
available to read from the queue. After examining the queue, you determine that no queue messages have a
DequeueCount value greater than zero. The website does not throw any errors.
Business Requirements
Payments
The music concert website must be able to submit event payment information for processing. The website must
remain responsive while submitting payment information. Customers must be able to add notes about their
orders to a free-form control on the website. These notes must be submitted with the payment when the
customer submits an order.
Customers often enter notes that exceed 7 KB in size.
Technical Requirements
Payment Submission and Processing
Event payment information must be sent from the website to a Windows Communication Foundation (WCF)
service worker role. The worker role must submit the information to the payment processor in JSON format.
Payment ProcessingYou have the following payment processing requirements:
If the number of messages in a queue goes above or below a specified threshold, worker role instances
must be created or deleted as needed. This process must be completed by using the least amount of effort.
It must be easy to reconfigure role instance thresholds.
Payments must be retrieved from the queue in the maximum batch sizes that are allowed by the queue and
pulled from the queue for 5 minutes.
The payment queue must not be re-created when processing payments.
During single Payment processing, the number of tickets available for an event must be updated. The
update operation must be retried for 30 seconds or 5 retry attempts, whichever occurs first. Each retry
should pause for at least two seconds and for one second longer than the previous attempt. If the update
fails, the payment should be placed in the poison queue.
Storage
You have the following storage requirements:
Payment information must be stored by using Azure Queue storage. Connection to the Azure storage
account has been established in a configured setting named StorageConnectionString, which is configured
for the web and worker roles.
A payment processing queue and a poison payment queue must be used when processing payments.
Azure Queue message content must be XML-safe and UTF-8 encoded.
An Azure storage account must be established for diagnostic information in a configured setting named
DiagnosticsStorageConnectionString, which is configured for both the web and worker roles.
Security and Monitoring
Security
The web role must be secured by using HTTPS.
Monitoring
You must collect diagnostic data for both the web and worker roles by using the Diagnostics module.
Diagnostics configuration changes must not require the code of the roles to be rebuilt. The diagnostic data is
used for debugging and troubleshooting, measuring performance, monitoring resource usage, traffic analysis
and capacity planning, and auditing.
Performance testing must evaluate the roles under normal and stress conditions without incurring changes for
running Azure. Memory allocation, function time, and multithreading concurrency issues must be evaluated.
Deployment
You purchase a custom domain name fabrikamfunding.com to host the website, web role, and worker roles.
You must deploy an HTTPS certificate with the web role, and you must update associated configuration files
accordingly.
Web role and worker role instance sizes must be specified as Medium. You must deploy one web role instance
named FabrikamFundingPaymentGenerator, and worker role instances named
FabrikamFundingPaymentProcessor.
Application Structure
Relevant portions of the app files are shown below. Line numbers are included for reference only and include a
two-character prefix that denotes the specific file to while they belong.
The SendMessageAsync method of the QueueManager class occasionally throws errors.
You need to correct the errors.
What should you do?
A.
Update the QueueManager to use the Put Message operation of the Queue Service REST API. Use HTTP
compression for all calls made to the REST API.
B.
Update the QueueManager to call the CloudQueueClient.SetServicePropertiesAsync method by using a
configured ServiceProperties object.
C.
Update the notes field to a byte array. Binary encode and decode the notes content when sending or
receiving an EventPayment class.
D.
Update the SendMessageAsync method of the QueueManager class to store the notes field in BLOB
storage. Update the EventPayment class to store the BLOB uniform resource identifier (URI). Extract the
notes BLOB information by using the BLOB URI in the ProcessMessagesAsync method of the
QueueManager class.