References:
https://docs.microsoft.com/en-us/azure/azure-monitor/app/custom-operations-tracking Explanation:
Example:
public async Task Enqueue(string payload)
{
// StartOperation is a helper method that initializes the telemetry item
// and allows correlation of this operation with its parent and children.
var operation = telemetryClient.StartOperation<DependencyTelemetry>("enqueue " + queueName); operation.Telemetry.Type = "Azure Service Bus"; operation.Telemetry.Data = "Enqueue " + queueName; var message = new BrokeredMessage(payload);
// Service Bus queue allows the property bag to pass along with the message.
// We will use them to pass our correlation identifiers (and other context)
// to the consumer.
message.Properties.Add("ParentId", operation.Telemetry.Id);
message.Properties.Add("RootId", operation.Telemetry.Context.Operation.Id); Reference:
https://docs.microsoft.com/en-us/azure/azure-monitor/app/custom-operations-tracking

Explanation:

To create an internal load balancer, create a service manifest named internal-lb.yaml with the service type LoadBalancer and the azure-load-balancer-internal annotation as shown in the following example:
YAML:
apiVersion: v1
kind: Service
metadata:
name: internal-app
annotations:
service.beta.kubernetes.io/azure-load-balancer-internal: " true "
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: internal-app
References:
https://docs.microsoft.com/en-us/azure/aks/internal-lb

Explanation:

Box 1: Strong
When the consistency level is set to strong, the staleness window is equivalent to zero, and the clients are guaranteed to read the latest committed value of the write operation.
Scenario: Changes to the Order data must reflect immediately across all partitions. All reads to the Order data must fetch the most recent writes.
Note: You can choose from five well-defined models on the consistency spectrum. From strongest to weakest, the models are: Strong, Bounded staleness, Session, Consistent prefix, Eventual Box 2: SQL Scenario: You identify the following requirements for data management and manipulation:
Order data is stored as nonrelational JSON and must be queried using Structured Query Language (SQL).
Topic 7, VanArsdel. Ltd
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 questions in 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 section 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 in 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
VanArsdel. Ltd. is a global office supply company. The company is based in Canada and has retail store locations across the world. The company is developing several cloud-based solutions to support their stores, distributors, suppliers, and delivery services.
Current environment
Requirements
The application components must meet the following requirements:
Corporate website
* Secure the website by using SSL
* Minimize costs tor data storage and hosting.
* Implement native GitHub workflows for continuous integration and continuous deployment (Cl/CO).
* Distribute the website content globally for local use.
* Implement monitoring by using Application Insights and availability web tests including SSL certificate validity and custom header value verification.
* The website must have 99.95 percent uptime.
Corporate website
The company provides a public website located at htlp://www. vanaisdelttd.com. The website consists of a React JavaScript user interface, HTML,CSS, image assets, and several APIs hosted in Azure functions.
Retail store locations
* Azure Functions must process data immediately when data is uploaded to Blob storage. Azure Functions must update Azure Cosmos D3 by using native SQL language queries.
* Audit store sale transaction information nightly to validate data, process sates financials, and reconcile inventory.
Delivery services
* Store service telemetry data in Azure Cosmos DB by using an Azure Function. Data must include an item id.
the delivery vehicle license plate, vehicle package capacity, and current vehicle location coordinates.
* Store delivery driver profile information in Azure Active Directory Azure AD) by using an Azure Function called from the corporate website.
Inventory services
The company has contracted a third-party to develop an API for inventory processing that requires access to a specific blob within the retail store storage account for three months to include read-only access to the data.
Security
* All Azure Functions must centralize management and distribution of configuration data for different environments and geographies, encrypted by using a company-provided RSA-HSM key.
* Authentication and authorization must use Azure AD and services must use managed identities where possible.
Retail Store Locations
* You must perform a point-in-time restoration of the retail store location data due to an unexpected and accidental deletion of data.
* Azure Cosmos DB queries from the Azure Function exhibit high Request Unit (RU) usage and contain multiple, complex queries that exhibit high point read latency for large items as the function app is scaling.