Microsoft AZ-204 Practice Test - Questions Answers, Page 5

As a solution architect/developer, you should consider using Service Bus queues when:

Your solution requires the queue to provide a guaranteed first-in-first-out (FIFO) ordered delivery.

Reference:

https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-azure-and-service-bus-queues-compared-contrasted

Box 1: Reoccurance..

To regularly run tasks, processes, or jobs on specific schedule, you can start your logic app workflow with the built-in Recurrence - Schedule trigger. You can set a date and time as well as a time zone for starting the workflow and a recurrence for repeating that workflow.

Set the interval and frequency for the recurrence. In this example, set these properties to run your workflow every week.

Box 2: Condition..

To run specific actions in your logic app only after passing a specified condition, add a conditional statement. This control structure compares the data in your workflow against specific values or fields. You can then specify different actions that run based on whether or not the data meets the condition.

Box 3: Put a message on a queue

The path for any item that is not archived must be placed in an existing queue.

Note: Under If true and If false, add the steps to perform based on whether the condition is met.

Box 4: ..tier it to Cool or Archive tier.

Archive item.

Box 5: List blobs 2

Reference:

https://docs.microsoft.com/en-us/azure/connectors/connectors-native-recurrence

https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-control-flow-loops

https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-control-flow-conditional-statement

A service bus instance has already been created (Step 2 below). Next is step 3, Create a Service Bus queue.

Note:

Steps:

Step 1: # Create a resource group

resourceGroupName="myResourceGroup"

az group create --name $resourceGroupName --location eastus

Step 2: # Create a Service Bus messaging namespace with a unique name

namespaceName=myNameSpace$RANDOM

az servicebus namespace create --resource-group $resourceGroupName --name $namespaceName --location eastus

Step 3: # Create a Service Bus queue

az servicebus queue create --resource-group $resourceGroupName --namespace-name $namespaceName --name BasicQueue

Step 4: # Get the connection string for the namespace

connectionString=$(az servicebus namespace authorization-rule keys list --resource-group $resourceGroupName --namespace-name $namespaceName --name RootManageSharedAccessKey --query primaryConnectionString --output tsv)

Reference:

https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-quickstart-cli

Create an Azure Function App that uses an Azure Service Bus Queue trigger.

Reference:

https://docs.microsoft.com/en-us/azure/azure-functions/functions-create-storage-queue-triggered-function

Box 1: Create a single Service Bus Namespace To begin using Service Bus messaging entities in Azure, you must first create a namespace with a name that is unique across Azure. A namespace provides a scoping container for addressing Service Bus resources within your application.

Box 2: Create a Service Bus Topic for each restaurant for which a driver can receive messages.

Create topics.

Box 3: Create a Service Bus subscription for each restaurant for which a driver can receive orders.

Topics can have multiple, independent subscriptions.

Reference:

https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-messaging-overview

Box 1: NotificationHubClient

Box 2: NotificationHubClient

Box 3: CreateClientFromConnectionString

// Initialize the Notification Hub

NotificationHubClient hub = NotificationHubClient.CreateClientFromConnectionString(listenConnString, hubName);

Box 4: SendWindowsNativeNotificationAsync

Send the push notification.

var result = await hub.SendWindowsNativeNotificationAsync(windowsToastPayload);

Reference:

https://docs.microsoft.com/en-us/azure/notification-hubs/notification-hubs-push-notification-registration-management

https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/app-service-mobile/app-service-mobile-windows-store-dotnet-get-started-push.md

Azure Functions can run on either a Consumption Plan or a dedicated App Service Plan. If you run in a dedicated mode, you need to turn on the Always On setting for your Function App to run properly. The Function runtime will go idle after a few minutes of inactivity, so only HTTP triggers will actually "wake up" your functions. This is similar to how WebJobs must have Always On enabled.

Scenario: Notification latency: Users report that anomaly detection emails can sometimes arrive several minutes after an anomaly is detected.

Anomaly detection service: You have an anomaly detection service that analyzes log information for anomalies. It is implemented as an Azure Machine Learning model. The model is deployed as a web service.

If an anomaly is detected, an Azure Function that emails administrators is called by using an HTTP WebHook.

Reference:

https://github.com/Azure/Azure-Functions/wiki/Enable-Always-On-when-running-on-dedicated-App-Service-Plan

Box 1: AzureServiceTokenProvider()

Box 2: tp.GetAccessTokenAsync("..")

Acquiring an access token is then quite easy. Example code:

private async Task<string> GetAccessTokenAsync()

{

var tokenProvider = new AzureServiceTokenProvider();

return await tokenProvider.GetAccessTokenAsync("https://storage.azure.com/");

}

Reference:

https://joonasw.net/view/azure-ad-authentication-with-azure-storage-and-managed-service-identity

Scenario: 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.

Box 1: DirectoryTransferContext

We transfer all files in the directory.

Note: The TransferContext object comes in two forms: SingleTransferContext and DirectoryTransferContext. The former is for transferring a single file and the latter is for transferring a directory of files.

Box 2: ShouldTransferCallbackAsync

The DirectoryTransferContext.ShouldTransferCallbackAsync delegate callback is invoked to tell whether a transfer should be done.

Box 3: False

If you want to use the retry policy in Copy, and want the copy can be resume if break in the middle, you can use SyncCopy (isServiceCopy = false).

Note that if you choose to use service side copy ('isServiceCopy' set to true), Azure (currently) doesn't provide SLA for that. Setting 'isServiceCopy' to false will download the source blob loca

Reference:

https://docs.microsoft.com/en-us/azure/storage/common/storage-use-data-movement-library

https://docs.microsoft.com/en-us/dotnet/api/microsoft.windowsazure.storage.datamovement.directorytransfercontext.shouldtransfercallbackasync?view=azure-dotnet