Passing the AZ-203 exam - Part 6

May 21, 2020

Connect and Consume 3rd Party Services

This is Part 3 of the AZ-203 study guide. In this post we'll cover:

Develop an App Service Logic App

A Logic App is a workflow you define to execute actions based on events, kind of an IFTTT version for your Azure subscription.

👉 For example, you could define a Logic App to check the blobs you have in a container and if they are older than a month, send a message to a queue so that an app could process them and move them to a less expensive archive storage.

💡 In the exam, I was asked to drag-drop activities into a workflow.

Retry Policies

Review the 4 different retry policies and their JSON representations.

Retry Policy Details
Default 4 exponential retries: intervals of 7.5 seconds, 12.5, 19.5....
Fixed interval interval: PT20S (every 20 seconds express in ISO format)
Exponential interval Minimun interval: PT10S, Maximum interval: PT1H
None Don't resend the request

Further reading: Retry Policies documentation 📖

Azure Search

Creating and populating a search index with data.


// The operations related to managing indexes are performed using a `SearchServiceClient` object.

var serviceClient = new SearchServiceClient(
    new SearchCredentials(adminApiKey)

Create an index

// Create an index with a list of fields with the [IsSearchable] attribute in the Order class.

var definition = new Index()
    Name = "orders",
    Fields = FieldBuilder.BuildForType<Order>()

Prepare a batch of documents for upload

var indexClientForUpload = serviceClient.Indexes.GetClient("orders");

var batch = IndexBatch.Upload(orders); // orders being an array of Order objects.

Actually upload the orders



var indexClientForQuery = new SearchIndexClient(
    new SearchCredentials(queryApiKey)

var parameters = new SearchParameters() 
    Select = new[] { "orderNumber" }

var results = indexClientForQuery.Documents.Search<Order>("1234", parameters);

⚠️ NOTE: If results are missing in a search, make sure the properties in your class are "searchable".

API Gateways

💡Know the 3 policy types: inbound, outbound and backend.

Policy Type Details Common uses
Inbound Applied on the request when coming into the API authentication, rate limiting, caching
Outbound Applied on outbound information from the API filter and transformation of data, caching
Backend Applied before calling a backend service and after a response from that service transformation of data (xml-json), retry

💡If you are asked what type of policy to use to secure API access with OpenID, the answer is the validate-jwt policy.

Event Grid

The Event Grid can be really helpful to build the backbone of serverless applications and event-driven applications.

💡What's an event? A report in change of state of something. Events are then sent to topics. All subscribers of the topic will receive the event.

    "destination": {
        "endpointBaseUrl": "",
        "endpointType": "WebHook",      // ⚠️
        "endpointUrl": null
    "filter": {
        "includedEventTypes": [
            "Microsoft.Storage.BlobCreated"         // ⚠️ 
        "subjectBeginsWith": "/blobServices/default/containers/testcontainer"

⚠️ Make sure to understand the JSON for configuring a blob-created event subscription.

# ⚠️ What are webhooks?
A common means of consuming events.

Further reading:

Service Bus

A service bus is a fully managed message broker that gives you these benefits:

  • Decoupled applications and services
  • Session management
  • Routing
  • Dead-lettering
  • Scheduling

Create a queue

# ⚠️ Creating a service bus queue in Azure CLI
az servicebus queue create
    --namespace-name az203sb
    -g servicebus
    -n testqueue

Or the equivalent powershell command:

# ⚠️ Creating a service bus queue in Powershell
    -ResourceGroupName servicebus
    -NamespaceName az203sb
    -name testqueue
    -EnablePartitioning false

⚠️ Note that there are some questions in the exam where the answers are in Powershell.

Service Bus Routing

A service bus queue is inherently for handling asynchronous calls. Fire and forget. So, if you need a response, before you can continue execution, how do you handle that? Let's look at a few examples.

Single reply queue (correlationId)

CorrelationId = MessageId

Single Reply Queue

This works fine for a single client. But, as soon as you introduce a second client, since there is a shared queue, you can't tell which reply belongs to which client.

One way this can be solved is by using a queue for each client, which we'll see next.

Reply queue for each client

ReplyTo = client

In this scenario, each client has the responsibility to create its own temporary queue. Then, each client sends along with its requests sends the ReplyTo property.

Reply Queue for Each Client

This actually works well with some messaging systems, for example, RabbitMQ, but in the end it doesn't scale that well.

Sessions (replyToSessionId)

# ⚠️ 
ReplyToSessionId = session number


Profile picture

Written by Carlos Torres a software engineer who loves building things Follow him on Twitter