This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Connect to and consume Azure services (20–25%)
   --> Develop and implement Azure Functions
      --> Build serverless APIs, including implementing triggers and bindings

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Azure Functions is a serverless compute service that allows developers to execute code in response to events without managing the underlying servers. For AI-enabled applications, Azure Functions can provide lightweight, scalable APIs and backend processing components that connect AI workloads to databases, messaging services, storage, and other Azure services.

For the AI-200 exam, an important area is understanding how to build serverless APIs using Azure Functions, particularly how triggers and bindings work together.

The key concepts include:

• HTTP triggers
• HTTP output bindings
• Function routes
• Authorization levels
• Input bindings
• Output bindings
• Binding expressions
• Multiple bindings
• Trigger versus binding
• Stateless serverless API design
• Connecting Functions to other Azure services
• Appropriate use of HTTP-triggered Functions

1. What Is Azure Functions?

Azure Functions is an event-driven serverless compute platform.

Instead of provisioning and maintaining virtual machines or application servers, you deploy individual functions that execute when an event occurs.

A function can be triggered by events such as:

• HTTP requests
• Azure Storage queue messages
• Blob changes
• Service Bus messages
• Event Grid events
• Event Hubs events
• Timer schedules

For example, an AI application might expose an HTTP endpoint:

POST /api/summarize

The request could contain a document that needs to be summarized.

The HTTP-triggered Function could:

1. Receive the request.
2. Validate the input.
3. Call an Azure AI service.
4. Store the result in a database.
5. Return the generated summary.

This allows the application to implement an API without maintaining a dedicated web server.

2. What Is a Trigger?

A trigger defines how a function is invoked.

Every Azure Function must have exactly one trigger.

For example:

HTTP request
      |
      v
HTTP trigger
      |
      v
Azure Function

The trigger provides the initial event or data that causes the function to execute.

Common triggers include:

For serverless APIs, the HTTP trigger is particularly important.

3. What Is an HTTP Trigger?

An HTTP trigger allows an Azure Function to execute when an HTTP request is received.

This makes HTTP-triggered Functions particularly useful for building:

• REST APIs
• Webhooks
• Backend endpoints
• AI inference APIs
• Data-processing APIs
• Lightweight microservices

For example:

Client
   |
   | POST /api/analyze
   v
Azure Function
   |
   +----> Azure AI service
   |
   +----> Database
   |
   v
HTTP response

The HTTP trigger can respond to specific HTTP methods such as:

• GET
• POST
• PUT
• PATCH
• DELETE

The supported methods are configured as part of the HTTP trigger.

4. HTTP Trigger Versus HTTP Output Binding

One of the most important concepts for the exam is distinguishing the trigger from the output binding.

The HTTP trigger receives the request:

HTTP request
     |
     v
HTTP trigger

The HTTP output sends the response:

Function
   |
   v
HTTP output
   |
   v
HTTP response

Therefore:

HTTP trigger = how the function is invoked

HTTP output = how the function sends an HTTP response

In most Azure Functions programming models, the function’s return value can be used to produce the HTTP response.

5. HTTP Routes

An HTTP-triggered Function has a URL endpoint.

By default, the route generally follows this pattern:

https://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>

For example:

https://my-ai-api.azurewebsites.net/api/analyze

You can customize the route.

For example, an API might use:

/api/products/{id}

A request such as:

GET /api/products/123

can cause the Function to receive:

id = 123

Route parameters are particularly useful when designing REST-style APIs.

6. HTTP Methods

An API endpoint should normally expose only the HTTP methods it actually needs.

For example:

GET    /api/products/{id}
POST   /api/products
PUT    /api/products/{id}
DELETE /api/products/{id}

A Function can be configured to respond to specific methods.

This allows a single Function endpoint to implement appropriate REST operations.

For example:

GET /api/orders/123

could retrieve an order, while:

POST /api/orders

could create an order.

Exam tip: Don’t confuse the HTTP method with the trigger. The HTTP trigger causes the Function to execute; the configured HTTP methods determine which types of requests the endpoint accepts.

7. Authorization Levels

HTTP-triggered Functions can use authorization levels to control who can invoke the function.

Common authorization levels include:

Anonymous

No Function key is required.

Useful for:

• Public endpoints
• Public webhooks
• APIs where authentication is handled elsewhere

However, anonymous does not mean that the endpoint should necessarily be considered secure. If sensitive operations are exposed, authentication and authorization should be implemented appropriately.

Function

A Function key is required.

This provides a simple mechanism for restricting invocation of the Function.

Admin

An administrative key is required.

This provides a higher level of access and should be used carefully.

Exam consideration: If a question asks for an HTTP endpoint that should require a Function key, Function authorization is the relevant setting.

8. What Are Bindings?

Bindings provide a declarative way for Azure Functions to connect to other services.

There are two primary types:

• Input bindings
• Output bindings

Bindings allow developers to avoid writing all of the connection and resource-management code themselves.

For example, instead of manually creating an Azure Storage client, authenticating to Storage, and retrieving a blob, a Function can use a blob input binding.

Conceptually:

Function
   |
   +---- Input binding ----> Azure Storage
   |
   +---- Output binding ---> Database

Bindings are optional.

A Function can have:

• A trigger only
• A trigger + input binding
• A trigger + output binding
• A trigger + multiple input/output bindings

9. Trigger Versus Input Binding

A trigger and an input binding are related but serve different purposes.

Trigger

Determines when the function executes.

Input binding

Provides additional data to the function.

For example:

HTTP request
     |
     v
HTTP trigger
     |
     v
Function
     |
     +---- Blob input binding
     |          |
     |          v
     |       Blob data

The HTTP request causes the Function to execute.

The blob input binding provides additional data.

10. Output Bindings

An output binding allows a Function to write data to another service.

For example, an HTTP Function could receive a request and write the result to Azure Storage.

HTTP request
     |
     v
Function
     |
     +----> Storage output binding

Another example:

HTTP request
     |
     v
AI processing Function
     |
     +----> Cosmos DB
     |
     +----> HTTP response

Output bindings can simplify integration with supported Azure services.

11. Multiple Bindings

A Function can use multiple bindings.

For example, an AI API might:

1. Receive an HTTP request.
2. Read customer information from Cosmos DB.
3. Call an AI service.
4. Write the result to Blob Storage.
5. Return an HTTP response.

Conceptually:

                   +--> Cosmos DB input
                   |
HTTP request ---> Function ---> Blob Storage output
                   |
                   +--> HTTP response

The Function still has only one trigger, but it can have multiple additional bindings.

12. Binding Expressions

Binding expressions allow information from one binding to be used dynamically by another binding.

For example, suppose a queue message contains:

customer123

A binding expression could use that value to determine which resource should be accessed.

Conceptually:

Queue message
     |
     | customer123
     v
Queue trigger
     |
     v
Binding expression
     |
     v
Customer-specific resource

This can reduce hardcoded configuration and make Functions more flexible.

Binding expressions commonly use curly-brace syntax such as:

{parameter}

13. Application Settings and Connection Information

Bindings commonly reference configuration values through application settings.

For example:

MyStorageConnection

could identify an application setting containing the connection information required by a storage binding.

This is preferable to hardcoding connection strings directly into source code.

For example, avoid:

connectionString = "DefaultEndpointsProtocol=..."

Instead, reference configuration:

connection = "MyStorageConnection"

The actual configuration can then be supplied through the Function App’s settings.

For production workloads, secrets should be managed securely, commonly using Azure Key Vault and managed identities where appropriate.

14. Building a Serverless API

A typical serverless API using Azure Functions can follow this architecture:

                  Client
                    |
                    | HTTPS
                    v
              HTTP Trigger
                    |
                    v
              Azure Function
             /      |       \
            /       |        \
           v        v         v
      Cosmos DB   Azure AI   Service Bus
         |          |           |
         +----------+-----------+
                    |
                    v
              HTTP Response

The Function acts as the lightweight API layer.

This architecture is particularly useful for AI applications because the Function can coordinate several backend services without requiring a traditional application server.

15. Example: AI Inference API

Consider an AI application that exposes:

POST /api/analyze

The request contains:

{
  "text": "Customer feedback..."
}

The Function could:

1. Receive the HTTP request.
2. Parse the JSON.
3. Validate the input.
4. Send the text to an AI service.
5. Store the result.
6. Return JSON to the client.

The response might look like:

{
  "sentiment": "positive",
  "confidence": 0.94
}

The Function therefore acts as an API façade around the AI processing workflow.

16. Choosing Between HTTP Triggers and Other Triggers

The trigger should match how the workload is initiated.

Use an HTTP trigger when:

• A client needs to call an API.
• A web application needs an endpoint.
• A webhook needs to invoke the Function.
• An application needs synchronous request/response behavior.

Use a queue or messaging trigger when:

• Work should be processed asynchronously.
• Requests may arrive faster than they can be processed.
• You need decoupling between components.
• Long-running processing should not block an HTTP request.

For example:

HTTP API
   |
   v
Service Bus
   |
   v
Function
   |
   v
AI processing

may be preferable to:

HTTP API
   |
   v
AI processing
   |
   v
HTTP response

when AI processing could take significant time.

17. Synchronous Versus Asynchronous APIs

This distinction is important when designing serverless AI applications.

Synchronous

The client waits for the Function to complete.

Client
  |
  | Request
  v
Function
  |
  | Process
  v
Client receives response

This works well when processing is relatively quick.

Asynchronous

The API accepts the request and places work into a messaging system.

Client
  |
  v
HTTP Function
  |
  v
Service Bus
  |
  v
Processing Function
  |
  v
AI workload

The client doesn’t have to wait for the complete operation.

This architecture can improve resilience and scalability.

18. HTTP Function Response Codes

A well-designed API should return appropriate HTTP status codes.

Common examples include:

For example, if an API accepts an AI processing request and queues it for asynchronous processing, a 202 Accepted response may be appropriate.

19. Error Handling

Serverless APIs should explicitly handle expected errors.

For example:

Request
   |
   v
Validate input
   |
   +---- Invalid ---> 400 Bad Request
   |
   v
Process request
   |
   +---- Resource missing ---> 404
   |
   +---- Unexpected failure -> 500
   |
   v
200 OK

Don’t expose sensitive internal information in error responses.

For example, avoid returning:

SQL connection string:
Server=...
Password=...

or detailed internal stack traces to clients.

20. Connection Management

An important practical consideration when developing HTTP-triggered Azure Functions is connection management.

Creating a new HTTP client or network connection for every Function invocation can lead to connection exhaustion and degraded performance.

Applications should use appropriate connection reuse patterns rather than repeatedly creating unmanaged HTTP clients.

This becomes particularly important for Functions that call:

• Azure AI services
• REST APIs
• Databases
• Storage
• Other backend services

21. Serverless API Design Best Practices

Keep Functions focused

A Function should ideally have a clear responsibility.

Avoid creating one enormous Function that:

• Validates requests
• Performs database operations
• Calls multiple AI models
• Sends emails
• Processes files
• Publishes events
• Performs unrelated business logic

Smaller, focused Functions are generally easier to test and maintain.

Use configuration instead of hardcoding

Store environment-specific configuration outside application code.

Protect sensitive APIs

Use appropriate authentication and authorization.

Validate requests

Don’t assume that incoming JSON is valid.

Return appropriate status codes

Use HTTP semantics consistently.

Design for retries

Backend services may retry operations. Functions should avoid unintended duplicate side effects.

Avoid unnecessary synchronous processing

If an operation can take a long time, consider an asynchronous architecture using messaging.

Reuse connections

Avoid connection exhaustion caused by creating network clients unnecessarily.

22. Important AI-200 Exam Distinctions

The following distinctions are especially important to remember.

A particularly important exam rule is:

A Function has exactly one trigger, but it can have multiple input and output bindings.

23. Key Takeaways

For the AI-200 exam, remember these points:

1. Azure Functions provides serverless compute.
2. A trigger determines when a Function runs.
3. Every Function has exactly one trigger.
4. HTTP triggers are used to create serverless APIs and receive webhooks.
5. HTTP output provides the response to an HTTP-triggered request.
6. Input bindings provide additional data to a Function.
7. Output bindings allow a Function to write to supported services.
8. A Function can have multiple input and output bindings.
9. Binding expressions allow dynamic values to flow between bindings.
10. Application settings should be used for configuration rather than hardcoding secrets.
11. HTTP methods and routes define how an HTTP API endpoint behaves.
12. Asynchronous workloads can use messaging services rather than keeping HTTP requests open.
13. Appropriate HTTP status codes should communicate success and failure conditions.
14. Connection reuse is important for high-throughput HTTP Functions.
15. For production applications, authentication, authorization, secure configuration, validation, and error handling are essential.

Practice Exam Questions

Question 1

A developer is building a serverless API that should execute whenever a client sends an HTTP POST request. Which Azure Functions feature should the developer use to initiate the Function?

A. HTTP trigger
B. HTTP output binding
C. Queue output binding
D. Timer trigger

Correct Answer: A

Explanation: An HTTP trigger causes an Azure Function to execute when an HTTP request is received. An HTTP output binding is used to produce the HTTP response, while a queue output binding sends data to a queue. A timer trigger executes according to a schedule.

Question 2

A Function receives an HTTP request and needs to write the resulting document to Azure Blob Storage without explicitly creating and managing a Blob Storage client in application code. What should the developer use?

A. HTTP trigger
B. Blob Storage output binding
C. Timer trigger
D. HTTP route parameter

Correct Answer: B

Explanation: An output binding provides a declarative way for a Function to write data to another supported Azure service. A Blob Storage output binding can write the Function’s output to a blob without requiring the developer to implement all of the storage interaction manually.

Question 3

A Function needs to retrieve additional data from Azure Storage after being invoked by an HTTP request. Which configuration best satisfies this requirement?

A. Configure two HTTP triggers.
B. Configure a second HTTP output binding.
C. Configure an HTTP trigger and an input binding.
D. Configure two Function authorization keys.

Correct Answer: C

Explanation: The HTTP trigger determines when the Function runs, while an input binding can provide additional data to the Function. A Function must have exactly one trigger, but it can have additional input bindings.

Question 4

An HTTP-triggered Function should only respond to requests using the POST method. What should the developer configure?

A. A storage input binding
B. A timer schedule
C. A custom output binding
D. The HTTP trigger’s allowed HTTP methods

Correct Answer: D

Explanation: The HTTP trigger can be configured with the HTTP methods to which it responds. Restricting the endpoint to POST prevents other HTTP methods from invoking that endpoint.

Question 5

A developer needs an HTTP Function endpoint with the following URL pattern:

/api/orders/12345

where 12345 represents an order identifier. What Azure Functions feature should be used to define the 12345 portion dynamically?

A. Route parameter
B. Output binding
C. Timer expression
D. Function key

Correct Answer: A

Explanation: HTTP route parameters allow portions of the URL to be captured and passed to the Function. A route such as /api/orders/{id} can capture 12345 as the id parameter.

Question 6

An Azure Function needs to receive an HTTP request, retrieve information from a database, write a result to storage, and return an HTTP response. How should the Function be configured?

A. Four triggers
B. One HTTP trigger with appropriate input/output bindings
C. One database trigger and three HTTP triggers
D. Four separate timer triggers

Correct Answer: B

Explanation: A Function has exactly one trigger. In this scenario, the HTTP request should be the trigger, while database and storage interactions can be implemented using appropriate bindings. The HTTP response is also produced by the HTTP output mechanism.

Question 7

A developer wants to prevent an HTTP-triggered Function from being publicly invokable without a Function key. Which authorization level should be used?

A. Anonymous
B. Public
C. Function
D. None

Correct Answer: C

Explanation: The Function authorization level requires a Function key when invoking the HTTP endpoint. Anonymous does not require a Function key. Authentication and authorization requirements should still be evaluated in the context of the overall application architecture.

Question 8

An AI API accepts a request and places the work into a queue for processing by another Function. The API should immediately tell the client that the request has been accepted for processing rather than waiting for the AI operation to finish. Which HTTP status code is most appropriate?

A. 404
B. 500
C. 201
D. 202

Correct Answer: D

Explanation: 202 Accepted is appropriate when a request has been accepted for processing but the processing has not completed. This pattern is useful for asynchronous AI workloads where the client shouldn’t have to maintain an open HTTP request while the backend performs potentially lengthy processing.

Question 9

A Function receives a queue message and uses information from that message to determine which blob should be accessed through another binding. Which Azure Functions feature can dynamically pass values between bindings?

A. Binding expressions
B. Authorization levels
C. HTTP methods
D. Function keys

Correct Answer: A

Explanation: Binding expressions allow values from trigger metadata, binding data, and other supported sources to be incorporated dynamically into binding configuration. This allows Functions to avoid hardcoding resource names and paths.

Question 10

An HTTP-triggered Function calls an external AI service. Under heavy load, the Function begins experiencing connection exhaustion because a new HTTP client is created for every invocation. What is the best approach?

A. Increase the HTTP response timeout indefinitely.
B. Disable the HTTP trigger.
C. Use an appropriate connection-reuse pattern rather than repeatedly creating HTTP clients.
D. Add another HTTP trigger to the same Function.

Correct Answer: C

Explanation: Repeatedly creating and disposing HTTP clients can contribute to connection exhaustion and poor performance. HTTP clients and connections should be managed using an appropriate reuse pattern for the runtime and language being used. Adding triggers or changing the response timeout does not address the underlying connection-management problem.

Final Exam Review

If you remember only a handful of concepts for this AI-200 topic, make them these:

Trigger = starts the Function.

Binding = connects the Function to another resource.

Input binding = brings data into the Function.

Output binding = sends data from the Function to another resource.

HTTP trigger = serverless API entry point.

HTTP output = response to the API caller.

One Function = exactly one trigger, potentially multiple bindings.

And for scenario questions, focus on why the Function is being invoked and what resources it needs to interact with. Those two questions usually reveal whether the correct answer involves a trigger, an input binding, an output binding, or an HTTP configuration.

Go to the AI-200 Exam Prep Hub main page