Tag: Azure Functions

azure, Cloud computing, Cybersecurity, Microsoft Certification, SC-500, security October 10, 2026October 10, 2026

Implement and configure security controls for Azure Functions, including authentication and network access (SC-500 Exam Prep)

This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Secure compute (20–25%)
   --> Implement security for application platform services
      --> Implement and configure security controls for Azure Functions, including authentication and network access

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.

Introduction

Azure Functions is a serverless compute service that allows organizations to execute code in response to events without managing the underlying server infrastructure.

From a security perspective, an Azure Function should not be treated simply as “code that runs in Azure.” A secure Function App requires controls across several layers:

Authentication
Authorization
Managed identities
Secrets and credentials
Inbound network access
Outbound network access
Private endpoints
Virtual network integration
Access restrictions
Secure connections to dependent Azure services
Least-privilege Azure RBAC

For the SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads exam, it is particularly important to understand the difference between:

Authenticating callers to a Function App

and

Authenticating a Function App to other Azure resources.

These are separate security problems and are commonly tested through scenario-based questions.

1. Azure Functions Security Architecture

A secure Function App can be thought of as having several security boundaries:

                    Internet / Client
                           |
                           v
                +----------------------+
                | Authentication /     |
                | Authorization        |
                +----------------------+
                           |
                           v
                +----------------------+
                | Network Access       |
                | Restrictions         |
                +----------------------+
                           |
                           v
                +----------------------+
                | Azure Function App   |
                +----------------------+
                    /            \
                   /              \
                  v                v
        Managed Identity       VNet Integration
                |                    |
                v                    v
       Azure Resources       Private Resources

The controls solve different problems:

Security concern	Primary control
Who can call the Function?	Authentication/authorization
What can the caller do?	Application authorization/RBAC
How does the Function access Azure resources?	Managed identity
Which networks can reach the Function?	Access restrictions/private endpoints
How does the Function reach private resources?	VNet integration
How is traffic kept off the public internet?	Private endpoints/private networking
How are Azure management operations controlled?	Azure RBAC

Understanding these distinctions is fundamental to this SC-500 topic.

2. Authentication vs. Authorization

Authentication and authorization are related but different.

Authentication

Authentication answers:

Who are you?

For example:

Is this user authenticated with Microsoft Entra ID?
Is this application presenting a valid token?
Is this client certificate valid?

Authorization

Authorization answers:

What are you allowed to do?

For example:

Can this user call the API?
Can this identity access a particular database?
Can this application read a particular Key Vault secret?

A secure Function App generally needs both.

			
Client
   |
   | Authentication
   v
"Who are you?"
   |
   v
Authenticated identity
   |
   | Authorization
   v
"What can you access?"

		

3. Function-Level Authentication

Azure Functions provides several mechanisms for controlling access to functions.

For HTTP-triggered functions, the function’s authorization level can be configured as:

Anonymous
Function
Admin

The authorization level is separate from the broader App Service authentication/authorization capability.

This distinction is important.

Anonymous

An HTTP request can invoke the function without providing a function key.

This should be used only when the function is intentionally public or when another security layer provides the required protection.

Function

The caller must provide a function key.

Function keys are intended to help control access to specific functions or the function app, but they should not be treated as a replacement for strong identity-based authentication for applications requiring user or application identity.

Admin

The caller requires the host-level master/admin key.

Because this key has extensive privileges, it should be protected carefully and should not be distributed to ordinary clients.

4. Function Keys Are Not the Same as Microsoft Entra Authentication

This is an important SC-500 distinction.

A function key essentially proves:

“The caller possesses the required secret.”

Microsoft Entra authentication provides an identity-based authentication mechanism.

For applications requiring:

User identity
Application identity
Conditional Access
Centralized identity management
Token-based authentication
Enterprise authorization

Microsoft Entra ID is generally the stronger architectural choice.

5. Built-In Authentication and Authorization

Azure Functions runs on the Azure App Service platform, so it can use the platform’s built-in authentication and authorization capabilities, commonly called App Service Authentication or Easy Auth.

These capabilities can authenticate users or clients before requests reach the Function code. Microsoft Entra ID is one of the supported identity providers.

A simplified flow is:

			
Client
   |
   | HTTP request
   v
Azure Functions
   |
   v
Authentication layer
   |
   +---- Not authenticated ----> Authentication challenge
   |
   +---- Authenticated --------> Function

		

This means developers don’t necessarily have to implement the entire authentication protocol themselves.

6. Requiring Authentication

For a protected HTTP Function App, the authentication configuration can require authentication rather than allowing unauthenticated requests.

This creates a security boundary in front of the application.

For example:

			
Internet
   |
   v
Authentication
   |
   +---- Unauthenticated --> Denied/challenged
   |
   +---- Authenticated ----> Function

		

This is useful for:

Enterprise APIs
Internal applications
Business applications
APIs consumed by authenticated applications
Functions that expose sensitive information

The Function’s own application-level authorization logic can then determine what an authenticated identity is allowed to do.

7. Microsoft Entra ID Authentication

Microsoft Entra ID can be used to authenticate users and applications calling a Function App.

For example:

			
User/Application
       |
       | Microsoft Entra token
       v
Function App
       |
       | Validate token
       v
Authenticated caller

		

This provides a much stronger identity model than simply distributing a shared function key to every consumer.

The application can then use claims and identity information to implement appropriate authorization.

8. Authentication Does Not Automatically Grant Authorization

An authenticated user isn’t necessarily authorized to perform every operation.

For example:

			
User
 |
 | Valid Entra token
 v
Function
 |
 +-- Read customer data       YES
 |
 +-- Delete customer data     NO

		

Authentication establishes identity.

Authorization determines what that identity is permitted to do.

This distinction is particularly important when designing APIs.

9. Managed Identities

Managed identity is one of the most important security features for Azure Functions.

A managed identity allows the Function App to authenticate to supported Microsoft Entra-protected Azure resources without storing credentials in application code or configuration.

Azure manages the identity, eliminating the need for you to provision and rotate a secret.

The architecture is:

			
Azure Function
      |
      | Managed Identity
      v
Microsoft Entra ID
      |
      | Access token
      v
Azure Resource

		

Examples of resources a Function might access include:

Azure Key Vault
Azure Storage
Azure SQL Database
Azure Service Bus
Azure App Configuration
Other Microsoft Entra-protected services

10. System-Assigned vs. User-Assigned Managed Identity

Azure Functions supports both major types of managed identity.

System-assigned managed identity

The identity is created as part of the Function App’s lifecycle.

If the Function App is deleted, its system-assigned identity is also removed.

This is useful when:

The identity belongs exclusively to one Function App.

User-assigned managed identity

A user-assigned managed identity is an independent Azure resource.

It can be assigned to multiple resources and has its own lifecycle.

This is useful when:

An identity needs to be managed independently or potentially shared across multiple resources.

Microsoft’s current Functions guidance also identifies user-assigned identities as more flexible for identity-based connections.

11. Managed Identity and Azure Key Vault

Suppose a Function needs a database password.

A poor architecture would be:

			
Function App
   |
   +-- database password

A better architecture is:

			
Function App
      |
Managed Identity
      |
      v
Microsoft Entra ID
      |
      v
Azure Key Vault
      |
      v
Secret

		

The Function doesn’t need to store a Key Vault password.

Instead, its managed identity receives only the permissions it needs.

This follows the principle of:

Least privilege + credential elimination

12. Managed Identity and Azure SQL

A Function can also use a managed identity to access Azure SQL Database.

For example:

			
Function App
     |
Managed Identity
     |
     v
Microsoft Entra ID
     |
     v
Azure SQL Database

		

The managed identity is granted the appropriate database permissions.

This eliminates the need to store a SQL username and password in the Function’s configuration.

This is a common SC-500 scenario:

“The application must access Azure SQL without storing database credentials.”

The preferred answer is generally:

Use a managed identity with appropriate permissions.

13. Identity-Based Connections

Azure Functions can use identity-based connections instead of connection strings containing secrets.

Microsoft’s current Functions guidance recommends managed identities with Microsoft Entra ID whenever possible because this approach eliminates secrets.

For example, rather than:

			
StorageConnection =
DefaultEndpointsProtocol=https;
AccountName=...;
AccountKey=...

the Function can use an identity-based connection where supported.

This reduces the risk associated with:

Credential theft
Credential leakage
Secret rotation
Secrets appearing in deployment files
Secrets appearing in source control

14. Protect Function Application Settings

Function Apps commonly use application settings to store configuration.

Sensitive values should not be casually placed into configuration files or source control.

Examples of sensitive values include:

API keys
Connection strings
Passwords
Client secrets
Access tokens

Prefer:

Managed identity
Microsoft Entra authentication
Azure Key Vault
Identity-based connections

when supported by the scenario.

The overall goal is:

Minimize long-lived secrets.

15. Network Security for Azure Functions

Authentication answers:

Who can call the Function?

Network security answers:

From where can the Function be reached?

These are separate controls.

Azure Functions provides several networking mechanisms, including:

Access restrictions
Private endpoints
Service endpoints
Virtual network integration
Network security groups for appropriate outbound scenarios
User-defined routes
NAT Gateway
App Service Environment options

The exact capabilities depend on the Functions hosting plan. Current Functions networking guidance distinguishes capabilities across Flex Consumption, Consumption, Premium, Dedicated/App Service Environment, and Container Apps hosting.

16. Access Restrictions

Access restrictions allow you to control inbound access to a Function App.

You can create rules based on factors such as:

IP addresses
IP ranges
Virtual network subnets
Service tags

Rules are evaluated according to their priority.

When access restrictions contain rules, an implicit deny-all behavior exists after the configured rules unless the unmatched rule behavior is otherwise configured.

For example:

			
Rule 100
Corporate subnet       ALLOW
Rule 200
Trusted application IP ALLOW
Default
Everything else        DENY

		

This is useful when a Function should be reachable only from known networks.

17. IP Restrictions vs. Authentication

These controls solve different problems.

IP restrictions

Control:

Where the request originates.

Authentication

Controls:

Who the caller is.

A strong security design can use both.

For example:

			
Request
   |
   +--> Network restriction
   |       |
   |       +-- Not allowed --> DENY
   |
   +--> Authentication
           |
           +-- Not authenticated --> DENY
           |
           +-- Authenticated --> Function

		

This is defense in depth.

18. Private Endpoints

A private endpoint provides private connectivity to a Function App through Azure Private Link.

The private endpoint receives a private IP address from a virtual network.

This allows clients on an appropriate private network to access the Function without relying on its public endpoint.

Conceptually:

			
Corporate Network
       |
 VPN / ExpressRoute
       |
       v
Azure VNet
       |
       v
Private Endpoint
       |
       v
Azure Function

		

This is particularly useful for:

Internal APIs
Sensitive applications
Enterprise workloads
Hybrid applications
Workloads that must not be publicly accessible

19. Private Endpoint vs. VNet Integration

This distinction is extremely important for SC-500.

Private endpoint

Primarily controls:

Inbound connectivity to the Function App.

VNet integration

Primarily controls:

Outbound connectivity from the Function App.

Think of it this way:

             INBOUND
                |
                v
         Private Endpoint
                |
          Function App
                |
                v
          VNet Integration
                |
             OUTBOUND

Azure’s current networking guidance explicitly separates inbound private endpoints from outbound virtual network integration.

20. Virtual Network Integration

VNet integration allows a Function App to access resources in an Azure virtual network.

This is primarily an outbound capability.

For example:

                 Azure VNet
                     |
        +------------+------------+
        |                         |
        v                         v
Function App                Private SQL
        |
        |
   VNet Integration

The Function can use VNet integration to reach:

Private endpoints
Resources in the same VNet
Peered VNets
Service-endpoint-protected resources
Resources reachable over ExpressRoute

Regional VNet integration is the recommended current approach where applicable.

21. VNet Integration Does Not Automatically Make the Function Private

This is an important exam trap.

Suppose you configure:

Function App → VNet integration

That does not automatically mean:

Internet → Function App is blocked.

VNet integration is primarily about outbound traffic.

If the goal is to prevent public inbound access, consider:

Private endpoint
Public network access configuration
Access restrictions
Appropriate network architecture

22. Combining Private Endpoint and VNet Integration

For a highly secured Function App, you may need both.

For example:

                    Corporate Network
                           |
                           v
                        Azure VNet
                           |
                    +------+------+
                    |             |
                    v             |
             Private Endpoint     |
                    |             |
                    v             |
              Function App        |
                    |             |
                    | VNet        |
                    | Integration |
                    v             |
              Private Database <---+

Here:

The private endpoint controls inbound private access.
VNet integration allows the Function to access private resources.
The database can itself be protected by a private endpoint.
Managed identity can provide authentication.

This creates multiple independent security layers.

23. DNS and Private Endpoints

Private networking isn’t complete merely because a private endpoint exists.

DNS must resolve the service name to the private endpoint’s address.

For example:

			
Function / Client
      |
      | DNS lookup
      v
private DNS zone
      |
      v
10.x.x.x
      |
      v
Private Endpoint

		

Azure Functions networking guidance notes that appropriate DNS configuration is required when using private endpoints.

Therefore, a scenario involving:

“The private endpoint exists, but the Function cannot connect”

should prompt you to investigate:

Private DNS
DNS resolution
VNet connectivity
Network security rules
Routing

24. Service Endpoints

Service endpoints can be used with supported Azure services to restrict access to selected virtual network subnets.

For Functions, service endpoints can also participate in inbound access restriction scenarios.

However, service endpoints and private endpoints are not the same.

Service endpoint

Extends a virtual network identity to a supported Azure service and allows access to be restricted to selected subnets.

Private endpoint

Provides a private IP address in the virtual network through Azure Private Link.

For modern highly isolated architectures, private endpoints are often preferred when eliminating public exposure is the objective.

25. Outbound Traffic Control

Securing inbound access isn’t enough.

A compromised Function could potentially attempt to communicate with:

Malicious external services
Unapproved APIs
Command-and-control infrastructure
Unauthorized data destinations

VNet integration can route outbound traffic through an Azure virtual network.

NSGs can control outbound traffic on the integration subnet, and user-defined routes can direct traffic through desired network paths.

For example:

			
Function App
     |
VNet Integration
     |
     v
Integration Subnet
     |
     v
Azure Firewall
     |
     +---- Approved destinations
     |
     +---- Blocked destinations

		

This provides centralized control over outbound traffic.

26. NAT Gateway for Predictable Outbound IP

In scenarios where an external service requires an allowlist of public IP addresses, a NAT Gateway can provide a predictable outbound public IP.

The architecture can look like:

			
Function App
     |
VNet Integration
     |
Integration Subnet
     |
NAT Gateway
     |
Static Public IP
     |
Internet

		

This is useful when:

A partner API requires IP allowlisting.
A third-party service permits only known source IPs.
Security teams need a predictable egress address.

A NAT Gateway addresses outbound source IP consistency, not inbound application authentication.

27. Private Access to Dependent Azure Services

A common secure architecture is to protect both the Function and the resources it accesses.

For example:

             Private Network
                   |
          +--------+--------+
          |                 |
          v                 v
   Private Endpoint   Private Endpoint
          |                 |
          v                 v
    Azure Function       Azure SQL
                            |
                       Managed Identity

This provides two separate protections:

Network protection

Private connectivity prevents unnecessary public exposure.

Identity protection

Managed identity controls which Function is authorized to access the database.

This is stronger than relying on network location alone.

28. Protecting Storage Used by Functions

Azure Functions often relies on Azure Storage for platform operations and triggers.

Security considerations include:

Restricting storage network access
Using private endpoints where appropriate
Using identity-based connections where supported
Applying least-privilege access
Avoiding unnecessary storage account keys
Protecting the Function’s host storage

Current Functions guidance supports identity-based connections for supported host and binding scenarios, with capabilities depending on the hosting plan.

29. Function App Authentication and Network Security Work Together

Consider a financial API.

A strong architecture could be:

			
Corporate Application
        |
        | Private network
        v
   Private Endpoint
        |
        v
   Azure Function
        |
   Entra Authentication
        |
        v
    Authorization
        |
        v
 Managed Identity
        |
        v
   Azure SQL

		

Each layer answers a different security question:

Question	Control
Can the request reach the Function?	Private endpoint/network controls
Who is calling?	Microsoft Entra authentication
What can the caller do?	Authorization
How does Function access SQL?	Managed identity
Where is SQL located?	Private networking
What permissions does Function have?	Least-privilege RBAC/database permissions

30. Authentication and Authorization for APIs

Azure Functions are frequently used to implement APIs.

A secure API should consider:

Authentication

Use Microsoft Entra ID or another appropriate identity provider.

Authorization

Determine what authenticated identities can access.

Network security

Restrict which networks can reach the API.

Transport security

Use HTTPS.

Application security

Validate:

Input
Tokens
Claims
Permissions
Request size
Application state

The platform’s authentication layer is not a substitute for sound application authorization logic.

31. Don’t Confuse Azure RBAC with Application Authorization

Azure RBAC controls access to Azure resources and management operations.

For example:

Who can configure the Function App?

Application authorization answers a different question:

Which authenticated application user can call /deleteCustomer?

Therefore:

			
Azure RBAC
     |
     +-- Azure resource management
     
Application authorization
     |
     +-- Application/API operations

		

Both may be necessary.

32. Secure Deployment and Administration

Security should also cover who can modify the Function App.

Azure RBAC can control administrative operations such as:

Creating Function Apps
Modifying configuration
Changing networking
Assigning identities
Managing deployment settings

Follow least privilege when assigning administrative roles.

A developer who needs to deploy application code doesn’t necessarily need unrestricted subscription-level permissions.

33. Defense in Depth for Azure Functions

A mature Function security architecture might contain all of the following:

                Client
                  |
            HTTPS / TLS
                  |
                  v
       Network restrictions
                  |
                  v
         Private Endpoint
                  |
                  v
        Entra Authentication
                  |
                  v
          Authorization
                  |
                  v
          Azure Function
                  |
          Managed Identity
                  |
                  v
          Azure Key Vault
                  |
                  v
         Private Database

No single control is expected to solve every security problem.

This is the essence of defense in depth.

34. Common SC-500 Exam Traps

Trap 1: VNet integration means private inbound access

Incorrect.

VNet integration primarily provides outbound connectivity.

For private inbound access, consider a private endpoint or appropriate access restrictions.

Trap 2: Private endpoint authenticates users

Incorrect.

A private endpoint provides network-level private connectivity.

You may still need Microsoft Entra authentication and authorization.

Trap 3: Function keys are equivalent to Entra ID

Incorrect.

Function keys are shared secrets.

Microsoft Entra ID provides identity-based authentication and is generally more appropriate for enterprise identity scenarios.

Trap 4: Managed identity authenticates users

Incorrect.

Managed identity is primarily used by the Function App to authenticate to Azure resources.

Trap 5: Authentication means authorization

Incorrect.

A successfully authenticated caller may still lack permission to perform a particular operation.

Trap 6: Network restrictions replace authentication

Incorrect.

A request originating from an approved network isn’t necessarily from an authorized user.

Use defense in depth.

Trap 7: Private endpoint controls outbound traffic

Incorrect.

The private endpoint is used for inbound access to the Function App.

VNet integration handles outbound connectivity.

35. Azure Functions Security Decision Matrix

Requirement	Recommended control
Authenticate users to an HTTP Function	Microsoft Entra ID / App Service authentication
Authenticate applications to a Function API	Microsoft Entra ID / appropriate token-based authentication
Restrict callers by source IP	Access restrictions
Allow access only from a VNet	Appropriate private networking/service endpoint/access restriction design
Eliminate public inbound exposure	Private endpoint + appropriate public network configuration
Allow Function to access private Azure resources	VNet integration
Authenticate Function to Azure SQL	Managed identity
Authenticate Function to Key Vault	Managed identity
Avoid storing Azure credentials	Managed identity
Control outbound traffic	VNet integration + NSGs/UDRs/firewall as appropriate
Provide predictable outbound IP	NAT Gateway
Protect Function management operations	Azure RBAC
Centralize secrets	Azure Key Vault
Authenticate without custom authentication code	App Service Authentication

36. End-to-End Secure Function Architecture

Consider an enterprise Function that exposes an internal API and accesses sensitive data.

A strong architecture might be:

                         Corporate Users
                               |
                         VPN / ExpressRoute
                               |
                               v
                         Azure VNet
                               |
                       Private Endpoint
                               |
                               v
                     +------------------+
                     |  Azure Function  |
                     +------------------+
                         |          |
                         |          |
              Entra Auth |          | Managed Identity
                         |          |
                         v          v
                  Authorization   Key Vault
                                    |
                                    |
                                    v
                              Azure SQL
                                    ^
                                    |
                              Private Endpoint

The security controls work together:

Private Endpoint limits network exposure.
Microsoft Entra ID authenticates callers.
Authorization controls what authenticated callers can do.
Managed Identity authenticates the Function to Azure services.
Key Vault protects secrets.
Azure SQL private endpoint minimizes database exposure.
Azure RBAC controls management access.
VNet integration provides private outbound connectivity.

37. Key Takeaways for the SC-500 Exam

The most important concepts to remember are:

Authentication

Use Microsoft Entra ID and App Service Authentication when you need strong identity-based authentication for Function callers.

Authorization

Authentication does not automatically grant permission to perform operations.

Managed identity

Use managed identities whenever possible to eliminate credentials from Function code and configuration.

Private endpoint

Think:

Private inbound access.

VNet integration

Think:

Private outbound connectivity.

Access restrictions

Think:

Allow or deny inbound traffic based on IP addresses, subnets, service endpoints, or service tags.

Key Vault

Think:

Centralized protection of secrets, keys, and certificates.

Azure RBAC

Think:

Management-plane and Azure-resource authorization.

Defense in depth

The strongest architecture combines identity, network, application, and resource-level controls rather than relying on one security feature.

Practice Exam Questions

Question 1

A company has an Azure Function that exposes an internal business API. The security team requires that users authenticate using Microsoft Entra ID before they can access the API.

Which solution should you implement?

A. Enable a system-assigned managed identity on the Function App

B. Enable anonymous access and validate the user’s IP address

C. Store a shared function key in the client application

D. Configure App Service Authentication/Authorization with Microsoft Entra ID

Answer: D

Explanation: App Service Authentication/Authorization, also known as Easy Auth, can require callers to authenticate using Microsoft Entra ID before requests reach the Function application. A managed identity serves a different purpose: it allows the Function to authenticate to other Azure resources.

Question 2

An Azure Function needs to read secrets from Azure Key Vault. The security team prohibits storing client secrets or passwords in the Function App configuration.

What should you implement?

A. An anonymous HTTP trigger

B. A managed identity assigned to the Function App with appropriate Key Vault permissions

C. A function key stored in Key Vault

D. A public Key Vault endpoint without authentication

Answer: B

Explanation: A managed identity allows the Function to authenticate to Microsoft Entra-protected resources such as Key Vault without storing credentials in the application. The identity should receive only the permissions it needs.

Question 3

A Function App must access an Azure SQL Database that is accessible only through a private endpoint. Which networking capability should the Function use to reach the private database?

A. An inbound access restriction

B. A public IP address on the Function

C. Virtual network integration

D. App Service Authentication

Answer: C

Explanation: VNet integration provides outbound connectivity from a Function App into an Azure virtual network. It allows the Function to reach private endpoints and other resources reachable through the virtual network.

Question 4

A company wants its Azure Function to be accessible only through a private IP address in an Azure virtual network. Public access to the Function must be eliminated.

Which capability is most appropriate?

A. Function-level authentication keys

B. NAT Gateway

C. VNet integration only

D. A private endpoint with appropriate public network access restrictions

Answer: D

Explanation: A private endpoint provides private inbound connectivity to the Function through an Azure virtual network. VNet integration alone is primarily an outbound networking feature and doesn’t make the Function’s inbound endpoint private.

Question 5

An organization wants to allow an Azure Function to receive requests only from two corporate subnets. Requests from all other networks should be denied.

Which feature should the security engineer configure?

A. Function App access restrictions

B. Managed identity

C. Microsoft Entra application registration only

D. NAT Gateway

Answer: A

Explanation: Access restrictions provide priority-ordered inbound allow/deny rules and can use IP addresses and virtual network subnets. When rules are configured, an implicit deny-all behavior exists after the configured rules unless the unmatched behavior is otherwise configured.

Question 6

A developer says, “We enabled VNet integration, so our Function App can no longer be reached from the internet.”

Why is this statement incorrect?

A. VNet integration is used only for DNS

B. VNet integration is primarily an outbound networking capability and does not by itself make the Function’s inbound endpoint private

C. VNet integration automatically disables Microsoft Entra authentication

D. VNet integration applies only to Azure Storage

Answer: B

Explanation: VNet integration primarily allows outbound access from the Function App into a virtual network and resources reachable through it. Private inbound access requires an appropriate private endpoint or other inbound access-control mechanism.

Question 7

A security architect needs a Function App to access Azure SQL without storing a database username and password. The database should authorize the Function based on its Azure identity.

Which solution should be used?

A. Anonymous access to Azure SQL

B. A function key

C. A managed identity with appropriate Microsoft Entra/database permissions

D. A public SQL endpoint with a hard-coded password

Answer: C

Explanation: Azure Functions supports managed identity authentication to Azure SQL. The identity can be granted the appropriate database permissions, eliminating the need to store a username and password in the Function.

Question 8

A Function App is receiving authenticated requests from Microsoft Entra users. One authenticated user should be allowed to read customer information but must not be allowed to delete customer records.

Which control is primarily responsible for making this distinction?

A. Private endpoint

B. VNet integration

C. Authentication

D. Authorization

Answer: D

Explanation: Authentication establishes who the caller is. Authorization determines what that authenticated identity is permitted to do. The application must therefore enforce the appropriate permissions for operations such as reading and deleting customer records.

Question 9

A company needs all outbound traffic from a Function App to pass through a centralized network security device so that destinations can be inspected and controlled.

Which architecture is most appropriate?

A. VNet integration combined with appropriate routing and a network security device such as Azure Firewall

B. A private endpoint on the Function App only

C. App Service Authentication

D. Function-level authorization keys

Answer: A

Explanation: VNet integration provides the outbound path into the virtual network. Network routing, NSGs, user-defined routes, and an appropriate firewall architecture can then be used to control outbound traffic. A private endpoint primarily addresses inbound connectivity to the Function.

Question 10

A security team is reviewing a Function App architecture. The application currently uses a private endpoint for inbound access and a managed identity for access to Azure Key Vault. The team wants the Function to access an Azure SQL Database through a private endpoint as well.

Which additional capability is required for the Function to reach the SQL private endpoint?

A. Anonymous authentication

B. Function-level admin authorization

C. Virtual network integration

D. A second public IP address

Answer: C

Explanation: The Function needs outbound connectivity into the virtual network containing or providing access to the SQL private endpoint. VNet integration provides this outbound connectivity. The existing private endpoint on the Function controls inbound access to the Function itself, while managed identity controls authorization to Key Vault.

Final Exam Review

For SC-500, remember this simple model:

                  WHO?
                   |
            Authentication
                   |
                   v
                Function
                   |
                  WHAT?
                   |
             Authorization
                   |
          +--------+--------+
          |                 |
       INBOUND           OUTBOUND
          |                 |
 Private Endpoint      VNet Integration
 Access Restrictions        |
          |                 |
          |             Private Resources
          |                 |
          +--------+--------+
                   |
             Managed Identity
                   |
                   v
          Azure Resources

The four concepts most worth memorizing are:

Authentication → Who can call the Function?

Authorization → What can the caller do?

Private endpoint/access restrictions → Who or what can reach the Function?

VNet integration → Where can the Function connect outbound?

And whenever a question says “without storing credentials”, immediately consider managed identity.

Go to the SC-500 Exam Prep Hub main page

AI-200, azure, Azure AI, Microsoft Certification August 15, 2026

Configure and deploy function apps (AI-200 Exam Prep)

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
      --> Configure and deploy function apps

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 enables developers to execute application code in response to events without managing the underlying server infrastructure.

For the AI-200: Developing AI Cloud Solutions on Azure exam, you should understand how to configure and deploy function apps, including:

Function app hosting plans
Function app configuration
Application settings
Runtime and operating-system configuration
Deployment methods
Zip deployment
Running functions from deployment packages
Deployment slots
Flex Consumption deployment
Continuous deployment
Configuration considerations for production
Common deployment problems and troubleshooting

The key exam skill is not simply knowing how to create a function app. You need to understand why you would choose a particular hosting or deployment approach for a given scenario.

1. What Is an Azure Function App?

An Azure Function is a piece of code that executes in response to a trigger.

A function app is the Azure resource that provides the execution environment for one or more functions.

For example, an AI application might contain functions that:

Receive an HTTP request.
Process a message from Azure Service Bus.
Respond to an Event Grid event.
Read a file uploaded to Azure Blob Storage.
Process a timer event.
Write results to a database.

The function app provides the common configuration and hosting environment for these functions.

Conceptually:

                    Azure Function App
                           |
          +----------------+----------------+
          |                |                |
      HTTP Function   Queue Function   Timer Function
          |                |                |
       REST API       AI Processing    Scheduled Job

Functions within the same function app generally share:

Runtime configuration
Application settings
Deployment configuration
Hosting resources
Some networking configuration
Monitoring configuration
Authentication configuration

Therefore, functions that have significantly different configuration or scaling requirements may be better placed in separate function apps.

2. Function App Hosting Plans

One of the most important concepts for AI-200 is understanding that the hosting plan affects scaling, cost, networking, deployment, and available features.

Current Azure Functions hosting options include:

Consumption
Flex Consumption
Elastic Premium
Dedicated/App Service
Azure Container Apps

The exact capabilities differ between plans.

Consumption Plan

The traditional Consumption plan is designed around serverless execution.

You generally pay based on function execution and resource consumption rather than maintaining dedicated compute capacity.

Characteristics include:

Automatic scaling
Serverless execution model
Consumption-based pricing
Potential cold starts
Limited control compared with Premium or Dedicated plans

The traditional Consumption plan should not be confused with Flex Consumption, which is the newer serverless option.

3. Flex Consumption

Flex Consumption is a newer Azure Functions hosting plan and is particularly important for current Azure development.

It is:

Linux-based
Serverless
Dynamically scalable
Consumption-based
Designed to provide more configuration flexibility than the traditional Consumption plan

Microsoft currently describes Flex Consumption as the recommended serverless hosting plan for Azure Functions.

Flex Consumption provides capabilities such as:

Configurable instance memory
Fast or large-scale-out options
Private networking
Always-ready instances for reducing cold starts
Support for deployment packages
Rolling updates for zero-downtime deployments

One particularly important exam distinction is that Flex Consumption uses a different deployment model from traditional Consumption.

Flex Consumption uses One Deploy as its deployment technology.

Important distinction

Do not assume:

“Zip deployment is the standard deployment method for every Functions hosting plan.”

That is no longer correct.

For example:

Hosting plan	Deployment approach
Flex Consumption	One Deploy
Consumption	Zip deploy and other supported methods
Elastic Premium	Zip deploy and other supported methods
Dedicated	Zip deploy and other supported methods
Container Apps	Container-based deployment

4. Elastic Premium Plan

The Elastic Premium plan provides more control and capabilities than Consumption-based hosting.

It is useful when applications require features such as:

More predictable performance
Larger compute resources
VNet integration
Reduced cold-start impact
Longer-running workloads
More control over scaling

Premium plans also support deployment slots.

This can be useful when deploying AI applications where a new version needs to be tested before being exposed to production users.

5. Dedicated/App Service Plan

A Function App can also run on a dedicated App Service plan.

In this model, the application runs on dedicated App Service compute.

This can be appropriate when:

You already have App Service infrastructure.
Predictable compute capacity is required.
You want to run functions alongside other App Service workloads.
The workload does not fit the serverless consumption model.

The tradeoff is that you are paying for allocated compute capacity rather than relying exclusively on consumption-based serverless execution.

6. Azure Container Apps

Azure Functions can also be hosted in Azure Container Apps.

This approach is particularly useful when:

You want containerized Functions.
You need container-specific capabilities.
You want Azure Container Apps scaling and infrastructure.
Your application architecture already uses containers.

This is different from simply deploying function source code to a normal Function App.

7. Choosing the Hosting Plan

For the exam, think in terms of requirements.

Requirement	Likely consideration
Serverless execution	Consumption or Flex Consumption
Modern recommended serverless option	Flex Consumption
Private networking with serverless model	Flex Consumption
Reduce cold starts	Flex Consumption/Premium
Predictable dedicated compute	Dedicated
Advanced scaling/performance	Premium
Containerized Functions	Azure Container Apps
Deployment slots	Consumption, Premium, Dedicated
Zero-downtime Flex deployment	Rolling updates
Test deployment before production	Deployment slots where supported

The exam may give you a scenario and ask you to select the most appropriate hosting model.

8. Function App Configuration

After selecting the hosting environment, you need to configure the function app.

Important configuration areas include:

Runtime
Operating system
Application settings
Connection strings
Authentication
Networking
Storage
Monitoring
Deployment configuration

The configuration determines how the Functions runtime executes your code and accesses external services.

9. Application Settings

Application settings are environment variables made available to your function application.

They are commonly used for configuration such as:

			
FUNCTIONS_WORKER_RUNTIME
AzureWebJobsStorage
APPLICATIONINSIGHTS_CONNECTION_STRING
SERVICE_BUS_CONNECTION
DATABASE_CONNECTION
OPENAI_ENDPOINT

		

For example, an application might use:

SERVICE_BUS_CONNECTION

instead of embedding a Service Bus connection string directly in source code.

The application reads the setting at runtime.

This allows the same application code to be deployed into different environments:

			
Development
      |
      v
SERVICE_BUS_CONNECTION = Dev connection
Test
      |
      v
SERVICE_BUS_CONNECTION = Test connection
Production
      |
      v
SERVICE_BUS_CONNECTION = Production connection

		

This is a fundamental cloud-development practice.

10. Never Hard-Code Secrets

A common mistake is placing credentials directly into source code.

Avoid:

connectionString = "Endpoint=sb://...;SharedAccessKey=..."

Instead, use configuration and preferably a secure secret-management solution such as Azure Key Vault.

For example:

			
Function App
     |
     v
Managed Identity
     |
     v
Azure Key Vault
     |
     v
Secret

		

This allows the code to remain unchanged when credentials change.

11. Function App Settings and Restarts

Changes to function app settings can cause the application to restart.

This matters in production environments.

If an application setting is changed, developers should understand that the change isn’t necessarily a completely isolated configuration update with no runtime impact.

For production applications, configuration changes should therefore be managed carefully.

12. Runtime Configuration

A Function App must use a compatible Functions runtime and language stack.

Examples include:

.NET
Java
JavaScript/Node.js
Python
PowerShell

The runtime configuration must match the application being deployed.

For example, a Python function app should not be configured as a .NET runtime application.

13. The `host.json` File

The host.json file contains configuration settings that apply to the entire function app.

Examples of configuration areas include:

Logging
Extension behavior
Retry policies
Concurrency
Durable Functions behavior
HTTP configuration

A simplified example:

			
{
  "version": "2.0",
  "logging": {
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true
      }
    }
  }
}

		

The host.json file is different from application settings.

`host.json`

Controls Functions host behavior.

Application settings

Provide environment-specific configuration and values to the application.

Understanding this distinction is important.

14. Deployment Methods

Azure Functions supports multiple deployment technologies.

The appropriate method depends on:

Hosting plan
Operating system
Development workflow
CI/CD requirements
Application architecture

Current deployment technologies include:

One Deploy
Zip deploy
External package URL
Docker/container deployment
Source control
Local Git
FTPS
In-portal editing

Not every method is supported for every hosting plan.

15. Zip Deployment

Zip deployment packages the function app into a .zip file and deploys it to Azure.

For Consumption, Elastic Premium, and Dedicated plans, zip deployment is the default and recommended deployment technology.

For example:

			
Function Project
       |
       v
    Build
       |
       v
   function.zip
       |
       v
 Azure Function App

		

A ZIP package must contain the application files in the expected structure.

One important requirement is that host.json must be located at the root of the package.

Incorrect:

			
function.zip
   |
   +-- my-function-project
          |
          +-- host.json

		

Correct:

			
function.zip
   |
   +-- host.json
   +-- Function1
   +-- Function2
   +-- requirements.txt

		

If the parent project directory is accidentally included, Azure Functions may not find the expected files.

16. Deploying with Azure CLI

For supported hosting plans, Azure CLI can be used to perform ZIP deployment.

A typical command is:

			
az functionapp deployment source config-zip \
    -g <resource-group> \
    -n <function-app-name> \
    --src <zip-file>

This uploads the ZIP package to the Function App.

The important exam concept is not memorizing every CLI parameter.

Instead, recognize:

config-zip is associated with ZIP deployment for supported Function App hosting plans.

17. Run From Package

Azure Functions can also run directly from a deployment package instead of extracting the application files into the normal application directory.

For supported plans, this can be enabled with:

WEBSITE_RUN_FROM_PACKAGE=1

When enabled, the deployment package is mounted as a read-only filesystem.

Advantages include:

Reduced file-copy problems
More predictable deployments
Improved deployment performance
Verification of the exact package being executed
Reduced cold-start impact in some scenarios

18. Important Flex Consumption Deployment Difference

One of the most important current exam distinctions is:

Flex Consumption does not use traditional Zip Deploy.

Flex Consumption uses One Deploy.

With One Deploy, the application is packaged and uploaded to a deployment storage container. The Function App retrieves the package and runs the application from it.

Therefore:

Scenario:

You create a new Function App using the Flex Consumption plan. You want to deploy the application using the supported deployment mechanism.

The appropriate answer should point toward:

One Deploy, rather than traditional Zip Deploy.

19. Deployment Slots

Deployment slots allow supported Function Apps to have multiple environments associated with the same application.

For example:

			
Function App
     |
     +-- Production
     |
     +-- Staging

		

You can deploy a new version to the staging slot, test it, and then swap it with production.

The general process is:

			
Development
     |
     v
Staging Slot
     |
   Test
     |
     v
Swap
     |
     v
Production

		

This reduces the risk of deploying an untested version directly to production.

20. Deployment Slots and Hosting Plans

Deployment slots are not available on every hosting model.

Current slot support includes:

Hosting option	Deployment slots
Consumption	Production + 1 slot
Flex Consumption	Not currently supported
Premium	Production + multiple slots
Dedicated	Production + multiple slots
Container Apps	Uses revisions rather than Functions deployment slots

This is an excellent area for scenario-based exam questions.

Example

A developer wants to deploy a new version to staging and swap it into production. The Function App uses Flex Consumption.

The traditional deployment-slot solution is not available.

Flex Consumption instead supports zero-downtime deployment through its site update strategies, including rolling updates.

21. Continuous Deployment

For production applications, deployment is often automated through CI/CD.

A typical pipeline looks like:

			
Developer
    |
    v
Source Repository
    |
    v
Build
    |
    v
Automated Tests
    |
    v
Package
    |
    v
Azure Function App

		

Possible tools include:

GitHub Actions
Azure Pipelines
Azure CLI
Azure Functions Core Tools
Visual Studio Code
Infrastructure-as-code tools

The goal is to make deployments:

Repeatable
Automated
Testable
Auditable
Consistent

22. Development vs. Production Deployment

The deployment method should reflect the environment.

Development

A developer may deploy directly from:

Visual Studio Code
Azure Functions Core Tools
Azure CLI

This is convenient for rapid development.

Production

Production deployments should generally use an automated CI/CD process.

A production pipeline might:

Build the application.
Install dependencies.
Run unit tests.
Run security checks.
Package the application.
Deploy to a staging environment.
Run validation tests.
Promote the application to production.

23. Configuration by Environment

A common architecture is to keep application code identical across environments while changing configuration.

For example:

                Same Code
                    |
       +------------+------------+
       |            |            |
       v            v            v
 Development       Test      Production
       |            |            |
       v            v            v
 Dev settings    Test settings   Prod settings

This is preferable to maintaining three separate codebases.

Environment-specific values should be supplied through:

Application settings
Key Vault
Managed identity
App Configuration
CI/CD variables

24. Infrastructure as Code

Function Apps can also be deployed using infrastructure-as-code technologies such as:

Bicep
ARM templates
Terraform

This allows the application infrastructure to be described declaratively.

For example:

			
Infrastructure Definition
          |
          v
     Resource Group
          |
    +-----+-----+
    |           |
    v           v
Function App   Storage
    |
    v
Application Insights

		

Infrastructure as code is especially useful when deploying consistent development, test, and production environments.

25. Function App Storage

Azure Functions generally requires an associated storage account for runtime operations.

The storage account may be used for Functions platform requirements such as:

Host state
Trigger management
Function keys
Other runtime-related data

The exact storage requirements vary depending on the hosting model.

This is especially important when designing secure or network-restricted applications.

26. Monitoring Configuration

Production Function Apps should generally be integrated with Application Insights/Azure Monitor.

Monitoring can provide information about:

Requests
Exceptions
Dependencies
Performance
Traces
Availability
Failures

An application can then be diagnosed using telemetry rather than relying exclusively on application output.

For an AI application, this can be particularly valuable.

For example:

			
HTTP Request
     |
     v
Azure Function
     |
     +----> Azure OpenAI
     |
     +----> Cosmos DB
     |
     +----> Service Bus
     |
     v
Application Insights

		

Telemetry can help identify whether a slow request is caused by the function itself or by a downstream dependency.

27. Networking Considerations

Function Apps may need to communicate with resources that are not publicly accessible.

Examples include:

Azure SQL
Azure Database for PostgreSQL
Azure Storage
Azure Key Vault
Cosmos DB
Internal APIs

Depending on the hosting plan and architecture, networking features such as VNet integration and private endpoints can be used.

This is one reason hosting-plan selection matters.

A requirement such as:

“The serverless application must access resources through a private network.”

should cause you to carefully consider whether the selected hosting plan supports the required networking capabilities.

Flex Consumption specifically provides private networking capabilities.

28. Common Deployment Problems

Understanding deployment failures is useful for both real-world development and AI-200.

Problem 1: Incorrect ZIP structure

The package does not contain host.json at the root.

Result: Functions may not be discovered correctly.

Solution: Package the contents of the application directory rather than the parent directory.

Problem 2: Incorrect runtime

The Function App is configured for a different runtime than the deployed application.

Result: Functions may fail to start.

Solution: Verify the runtime and language stack.

Problem 3: Missing application setting

The function expects:

SERVICE_BUS_CONNECTION

but the setting isn’t configured.

Result: The function cannot connect to Service Bus.

Solution: Configure the required application setting or use a managed identity-based connection.

Problem 4: Deployment method incompatible with hosting plan

For example, attempting to use traditional Zip Deploy on Flex Consumption.

Result: The deployment approach isn’t supported.

Solution: Use the deployment technology appropriate for the hosting plan—One Deploy for Flex Consumption.

Problem 5: Expecting deployment slots on Flex Consumption

Flex Consumption currently does not support traditional deployment slots.

Solution: Use supported Flex Consumption site update strategies for zero-downtime deployment.

29. Key AI-200 Exam Distinctions

Memorize these concepts rather than isolated commands.

Function App vs. Function

Function

A unit of code triggered by an event.

Function App

The hosting and configuration environment for functions.

`host.json` vs. Application Settings

host.json

Controls Functions host behavior.

Application settings

Provide configuration and environment-specific values to the application.

Consumption vs. Flex Consumption

Consumption

Traditional serverless hosting option.

Flex Consumption

Modern serverless hosting option with additional configuration and networking capabilities.

Zip Deploy vs. One Deploy

Zip Deploy

Used with Consumption, Premium, and Dedicated plans.

One Deploy

The deployment technology for Flex Consumption.

Deployment Slots vs. Flex Rolling Updates

Deployment slots

Useful for supported hosting plans when you want to stage and swap deployments.

Flex Consumption

Doesn’t currently support deployment slots; use supported site update strategies such as rolling updates for zero-downtime deployments.

30. AI-200 Study Checklist

Before considering this topic mastered, make sure you can answer the following:

What is a Function App?
How does a Function differ from a Function App?
What are the major Azure Functions hosting plans?
What is the difference between Consumption and Flex Consumption?
Why would you choose Premium?
When would Dedicated hosting make sense?
What is host.json used for?
What are application settings?
Why shouldn’t secrets be hard-coded?
What is Zip Deploy?
What is One Deploy?
Which hosting plan requires One Deploy?
What does WEBSITE_RUN_FROM_PACKAGE do?
What are deployment slots?
Which plans support deployment slots?
What is the alternative to deployment slots in Flex Consumption?
How should production deployments be automated?
Why is CI/CD preferable for production?
How does Application Insights help troubleshoot Function Apps?
What are common deployment failures?

Practice Exam Questions

Question 1

A development team is creating a new Azure Function App using the Flex Consumption hosting plan. The team needs to deploy the application using the deployment technology supported by this hosting plan.

Which deployment technology should the team use?

A. Zip Deploy
B. FTP deployment
C. One Deploy
D. Local Git

Answer: C

Explanation:
Flex Consumption uses One Deploy as its deployment technology. Traditional Zip Deploy, FTP, and Local Git aren’t the deployment mechanism for Flex Consumption. One Deploy packages the application and stores the deployment package in the configured deployment storage.

Question 2

A Function App is configured with the following application setting:

SERVICEBUS_CONNECTION

The application uses this setting to obtain the connection information required to communicate with Azure Service Bus.

What is the primary purpose of an application setting in this scenario?

A. To define the Functions host version
B. To provide configuration values to the application at runtime
C. To define the HTTP trigger schema
D. To control the number of function instances

Answer: B

Explanation:
Application settings provide configuration values to the Function App and its code. They are commonly used for environment-specific configuration such as endpoints, connection information, and other runtime values. host.json, rather than an application setting, is used for many Functions host-level behaviors.

Question 3

A company deploys an Azure Function App to a supported hosting plan. Developers want to test a new version of the application before making it the production version. They want to deploy the new version separately and then swap it into production.

Which feature should they use?

A. Azure Event Grid
B. Function keys
C. Deployment slots
D. Application settings

Answer: C

Explanation:
Deployment slots allow supported Function Apps to run separate application instances such as staging and production. Developers can deploy and test the application in a staging slot and then swap the slot into production. Flex Consumption currently does not support traditional deployment slots.

Question 4

A developer creates a ZIP package for an Azure Function App. The ZIP file has this structure:

			
functionapp.zip
    |
    +-- MyFunctionProject
          |
          +-- host.json
          +-- Function1
          +-- Function2

		

The deployment succeeds, but Azure Functions cannot correctly locate the application files.

What is the most likely problem?

A. The ZIP package is too small
B. The Function App requires a deployment slot
C. host.json must be configured as an application setting
D. host.json isn’t located at the root of the deployment package

Answer: D

Explanation:
For ZIP deployment, host.json must be at the root of the extracted package. The common mistake is including the parent project directory inside the ZIP. The package should contain the application files directly at its root.

Question 5

A production Function App runs on a Consumption, Premium, or Dedicated plan. The development team wants to deploy the application as a ZIP package.

Which deployment technology should they generally use?

A. Zip Deploy
B. One Deploy
C. FTP only
D. Docker Compose

Answer: A

Explanation:
Zip Deploy is the default and recommended deployment technology for Function Apps running on Consumption, Elastic Premium, and Dedicated plans. Flex Consumption is the important exception because it uses One Deploy.

Question 6

An organization wants to run an Azure Functions application using a serverless hosting model. The application requires private networking capabilities and the organization wants to use a modern serverless Functions hosting option.

Which hosting plan is the best fit?

A. Dedicated App Service only
B. Flex Consumption
C. Classic Windows-only Consumption
D. Local development hosting

Answer: B

Explanation:
Flex Consumption is a Linux-based serverless hosting plan that provides additional capabilities such as private networking, configurable instance memory, and scaling options. It is currently Microsoft’s recommended serverless hosting plan for Azure Functions.

Question 7

A developer wants an Azure Function App to execute directly from a deployment package rather than copying the package contents into the normal application directory.

Which application setting is associated with running functions from a package for supported hosting plans?

A. FUNCTIONS_EXTENSION_VERSION
B. FUNCTIONS_WORKER_RUNTIME
C. WEBSITE_RUN_FROM_PACKAGE
D. SCM_DO_BUILD_DURING_DEPLOYMENT

Answer: C

Explanation:
WEBSITE_RUN_FROM_PACKAGE is used to configure supported Function Apps to run from a deployment package. When configured appropriately, the package is mounted as a read-only filesystem. Flex Consumption runs from a package by default and uses its own deployment model.

Question 8

A company has a Function App running on Flex Consumption. The development team wants to use the traditional deployment-slot model to deploy a staging version and then swap it into production.

What should the team do?

A. Create a second deployment slot
B. Enable FTP deployment
C. Convert the app to a Consumption plan automatically
D. Use a supported Flex Consumption site update strategy instead

Answer: D

Explanation:
Traditional deployment slots are not currently supported on Flex Consumption. Flex Consumption instead provides site update strategies, including rolling updates, for scenarios requiring zero-downtime deployments.

Question 9

A production Function App needs to access a database. The developer proposes putting the database password directly into the function’s source code.

Which approach is most appropriate?

A. Store the password in source control
B. Store the secret in Azure Key Vault and provide secure access through configuration or managed identity
C. Put the password in host.json
D. Store the password in the function name

Answer: B

Explanation:
Secrets should not be hard-coded into application source code or committed to source control. Azure Key Vault combined with managed identity is a strong approach for securely retrieving secrets. Application configuration can then provide non-secret configuration and references as appropriate.

Question 10

A development team is creating a production deployment pipeline for an Azure Function App. The team wants deployments to be repeatable and automatically tested before production deployment.

Which approach is most appropriate?

A. Manually upload files through the Azure portal for every release
B. Edit the production Function App directly in the portal
C. Use a CI/CD pipeline that builds, tests, packages, and deploys the Function App
D. Store production code only on the developer’s workstation

Answer: C

Explanation:
A CI/CD pipeline provides repeatable and automated deployment. A typical pipeline can build the application, run tests, package the application, deploy it to an appropriate environment, validate it, and promote it to production. This is much more reliable and auditable than manual production deployments.

Final Exam Takeaways

For AI-200 – Configure and deploy function apps, concentrate especially on the distinctions between hosting plans, configuration, and deployment technologies.

The highest-value concepts to remember are:

A Function App provides the hosting environment for one or more functions.
The hosting plan affects cost, scaling, networking, and deployment capabilities.
Flex Consumption is the modern serverless Functions hosting option and is currently the recommended serverless plan.
Flex Consumption uses One Deploy rather than traditional Zip Deploy.
Zip Deploy is the recommended deployment technology for Consumption, Elastic Premium, and Dedicated plans.
host.json controls Functions host behavior.
Application settings provide runtime/environment configuration.
Secrets should not be hard-coded into function code.
Deployment slots allow supported hosting plans to stage and swap releases.
Flex Consumption doesn’t currently support deployment slots.
Flex Consumption can use rolling updates for zero-downtime deployments.
WEBSITE_RUN_FROM_PACKAGE allows supported Function Apps to execute from a deployment package.
ZIP packages must have host.json at the package root.
CI/CD is the preferred approach for repeatable production deployments.
Application Insights/Azure Monitor should be part of a production observability strategy.

These distinctions are particularly important because AI-200 scenario questions are likely to test which Azure Functions configuration or deployment approach best satisfies a set of requirements, rather than simply asking you to recall definitions.

Go to the AI-200 Exam Prep Hub main page

azure, Databases, DP-800, Microsoft Certification, SQL August 1, 2026August 1, 2026

Handle changes by using change event streaming (CES), change data capture (CDC), Change Tracking, Azure Functions with SQL trigger binding, or Azure Logic Apps (DP-800 Exam Prep)

This post is a part of the DP-800: Developing AI-Enabled Database Solutions Exam Prep Hub.
This topic falls under these sections:
Secure, optimize, and deploy database solutions (35–40%)
   --> Integrate SQL solutions with Azure services
      --> Handle changes by using change event streaming (CES), change data capture (CDC), Change Tracking, Azure Functions with SQL trigger binding, or Azure Logic Apps

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.

Introduction

Modern applications rarely operate in isolation. A single database update often needs to trigger downstream actions such as updating search indexes, synchronizing data warehouses, refreshing caches, sending notifications, invoking APIs, or triggering AI pipelines.

Microsoft SQL Server and Azure SQL provide several mechanisms to detect and react to data changes. The DP-800 exam expects candidates to understand the capabilities, strengths, limitations, and appropriate use cases for each technology.

The primary technologies include:

Change Data Capture (CDC)
Change Tracking
Change Event Streaming (CES)
Azure Functions with SQL Trigger Binding
Azure Logic Apps

Understanding when and why to use each technology is more important than memorizing implementation details.

Why Change Detection Matters

Applications often need to know when data changes occur without continuously querying every table.

Examples include:

Synchronizing CRM and ERP systems
Triggering AI workflows after new customer data arrives
Updating recommendation engines
Refreshing search indexes
Sending order confirmation emails
Replicating data into Microsoft Fabric
Populating analytical data lakes
Updating Power BI semantic models

Without an efficient change detection mechanism, applications would have to repeatedly scan entire tables, resulting in:

Poor performance
Increased costs
Higher latency
Unnecessary resource utilization

Overview of Available Technologies

Technology	Detects Inserts	Updates	Deletes	Provides Changed Values	Typical Use
Change Tracking	Yes	Yes	Yes	No	Lightweight synchronization
Change Data Capture	Yes	Yes	Yes	Yes	ETL and replication
Change Event Streaming	Yes	Yes	Yes	Event stream	Event-driven architectures
Azure Functions SQL Trigger	Yes	Yes	Yes	Current row	Serverless processing
Azure Logic Apps	Yes	Yes	Yes	Depends on connector	Workflow automation

Change Data Capture (CDC)

What is CDC?

Change Data Capture records every data modification that occurs within selected database tables.

Unlike Change Tracking, CDC stores:

The type of operation
Before and after values (where applicable)
Transaction information
Log Sequence Numbers (LSNs)
Timestamps

CDC reads changes directly from the SQL Server transaction log instead of requiring application modifications.

How CDC Works

User modifies data.
SQL writes changes to the transaction log.
CDC captures the changes.
Changes are written into CDC system tables.
Applications or ETL tools read the captured changes.

			
Application
      │
      ▼
SQL Table
      │
Transaction Log
      │
      ▼
CDC Capture Process
      │
      ▼
CDC Change Tables
      │
      ▼
ETL / Azure Data Factory / Fabric

		

Information Stored by CDC

For every change, CDC stores:

Insert
Update
Delete
Transaction sequence
Changed columns
Original values
New values
Commit time
Log sequence number

This provides a complete history of modifications.

Advantages of CDC

Minimal application changes

Applications continue performing normal INSERT, UPDATE, and DELETE operations.

Incremental processing

Instead of processing millions of rows:

			
Yesterday:
10 million rows
Today:
Only 1,250 rows changed
CDC processes only 1,250 rows.

		

This dramatically improves ETL performance.

Supports Historical Analysis

CDC retains detailed change history.

Example:

Customer Name

Original:

John Smith

Updated:

John A. Smith

CDC preserves both versions.

Common CDC Use Cases

Azure Data Factory incremental loads
Microsoft Fabric ingestion
Data warehouse updates
Database replication
AI training pipelines
Audit solutions
Event publishing
Synchronizing microservices

Limitations

CDC:

Uses additional storage
Requires SQL Agent jobs (SQL Server)
Introduces some overhead
Retention must be managed
Generates additional transaction log activity

Change Tracking

What is Change Tracking?

Change Tracking is a lightweight feature that records which rows have changed, but does not store the actual changed values.

Instead, it stores metadata indicating:

Row changed
Row deleted
Version number

Applications retrieve the latest row directly from the table.

How Change Tracking Works

Instead of saving old values:

CustomerID 101 changed.

The application retrieves:

			
SELECT *
FROM Customers
WHERE CustomerID = 101

Only the current version is available.

Advantages

Very lightweight.

Minimal storage.

Minimal performance impact.

Simple synchronization.

Fast processing.

Limitations

Cannot determine:

Old value

↓

New value

Only knows:

Row changed

No historical audit.

No before-and-after comparison.

Best Use Cases

Mobile synchronization

Offline applications

Client synchronization

Web applications

Caching

Incremental refresh

Applications only needing current data

CDC vs Change Tracking

Feature	CDC	Change Tracking
Detect Inserts	Yes	Yes
Detect Updates	Yes	Yes
Detect Deletes	Yes	Yes
Stores Old Values	Yes	No
Stores New Values	Yes	No
Historical Data	Yes	No
Storage Usage	Higher	Lower
ETL Friendly	Excellent	Limited
Synchronization	Good	Excellent
Auditing	Excellent	Poor

Choosing Between CDC and Change Tracking

Choose CDC when:

Building ETL pipelines
Loading data warehouses
Creating audit systems
Tracking complete history
AI model retraining
Replication

Choose Change Tracking when:

Synchronizing mobile devices
Synchronizing applications
Detecting row changes only
Performance is critical
History is unnecessary

Change Event Streaming (CES)

What is Change Event Streaming?

Change Event Streaming is an event-driven approach that publishes database changes as events immediately after they occur.

Instead of applications polling for changes:

			
Did anything change?
Did anything change?
Did anything change?

The database immediately emits an event.

Event-Driven Architecture

			
INSERT Order
      │
      ▼
Database
      │
      ▼
Event Published
      │
 ┌────┼────┐
 ▼    ▼    ▼
Function
Logic App
Service Bus

		

One database change can notify many downstream services simultaneously.

Advantages

Near real-time processing

Low latency

Highly scalable

Excellent for cloud-native applications

Supports asynchronous processing

Works well with event hubs and messaging systems

Common Scenarios

Order processing

Inventory updates

Recommendation engines

AI pipelines

Search indexing

Notifications

Microservices

IoT

Streaming analytics

Benefits over Polling

Polling example:

Check database every minute

Potential issues:

Delayed processing
Unnecessary database queries
Higher compute costs

Event streaming:

			
Change occurs
↓
Immediate notification

Much more efficient.

Azure Functions with SQL Trigger Binding

Overview

Azure Functions provide a serverless compute platform capable of automatically executing code when database changes occur.

SQL Trigger Binding enables Azure Functions to react to SQL data modifications without requiring custom polling logic.

Typical workflow:

			
Database Change
↓
SQL Trigger
↓
Azure Function
↓
Business Logic

		

Common Scenarios

Automatically:

Send emails
Generate invoices
Update search indexes
Invoke AI models
Call REST APIs
Update Cosmos DB
Write to Azure Storage
Publish Service Bus messages

Benefits

Serverless

Automatic scaling

Pay only for executions

Minimal infrastructure management

Easy integration with Azure services

Supports event-driven architectures

Example Scenario

A customer places an order.

INSERT Orders

The SQL trigger starts an Azure Function.

The function:

Validates inventory
Sends confirmation email
Updates recommendation engine
Notifies shipping
Publishes event

No manual polling required.

Azure Logic Apps

What Are Logic Apps?

Azure Logic Apps are low-code workflow automation services that integrate SQL databases with hundreds of Microsoft and third-party services.

Rather than writing custom code, workflows are built visually.

Example:

			
SQL Row Updated
↓
Logic App
↓
Teams Notification
↓
Outlook Email
↓
SharePoint Update
↓
CRM Update

		

Common SQL Integrations

SQL Server

Azure SQL Database

Microsoft Dataverse

Dynamics 365

Salesforce

Microsoft Teams

SharePoint

Azure Storage

Azure Service Bus

Azure Event Grid

Power Automate

Typical Workflow

			
Customer Created
↓
Logic App
↓
Create CRM Record
↓
Send Welcome Email
↓
Create Help Desk Ticket
↓
Notify Sales Team

		

Advantages

Low-code

Rapid development

Hundreds of connectors

Visual designer

Built-in retry policies

Error handling

Scheduling

Monitoring

Enterprise integration

Limitations

Logic Apps are ideal for orchestration and workflow automation but are not intended for high-throughput transactional processing where custom code or event streaming solutions may provide better scalability and lower latency.

Choosing the Right Technology

Requirement	Recommended Solution
Incremental ETL	CDC
Data Warehouse Loading	CDC
Audit History	CDC
Mobile Sync	Change Tracking
Cache Refresh	Change Tracking
Event-Driven Processing	Change Event Streaming
Serverless Business Logic	Azure Functions SQL Trigger
Workflow Automation	Azure Logic Apps
AI Pipeline Trigger	Azure Functions or CES
Multi-System Integration	Logic Apps

Best Practices

Enable Only What You Need

Enable CDC or Change Tracking only on tables that require change detection.

Monitor Storage

CDC tables can grow quickly.

Implement retention policies and cleanup jobs.

Prefer Event-Driven Architectures

Avoid continuous polling whenever possible.

Use:

CES
Azure Functions
Event Grid
Service Bus

for scalable cloud-native applications.

Separate Operational and Analytical Workloads

Use CDC to move transactional data into analytical platforms instead of querying production systems directly.

Secure Integration Endpoints

Protect Azure Functions and Logic Apps using:

Microsoft Entra ID
Managed identities
Azure Key Vault
Least privilege access
Network restrictions where appropriate

Monitor Reliability

Track:

Failed executions
Retry attempts
Dead-letter queues
Function failures
Logic App run history
Event delivery failures

DP-800 Exam Tips

Remember these common exam distinctions:

CDC records complete data changes, including inserted, updated, and deleted values, making it ideal for ETL, auditing, and replication.
Change Tracking records only that a row changed, making it a lightweight solution for synchronization scenarios.
Change Event Streaming supports near real-time, event-driven architectures by publishing change events to downstream consumers.
Azure Functions with SQL Trigger Binding are best when database changes should execute custom serverless code automatically.
Azure Logic Apps are the preferred choice for orchestrating business workflows and integrating SQL databases with Azure and third-party services through low-code connectors.
When selecting a technology, evaluate latency requirements, scalability, historical tracking needs, operational overhead, and integration requirements rather than choosing a single solution for every scenario.

Summary

Modern SQL applications extend well beyond traditional databases, serving as event sources for cloud-native architectures, AI pipelines, analytics platforms, and business workflows. Microsoft provides several complementary technologies to detect and process database changes, each optimized for different scenarios.

For the DP-800 exam, you should understand not only how these technologies work, but also when to choose one over another. CDC excels at incremental ETL and auditing, Change Tracking offers lightweight synchronization, Change Event Streaming enables real-time event-driven systems, Azure Functions execute custom business logic in response to changes, and Azure Logic Apps simplify workflow automation across enterprise services.

A solid understanding of these tools will help you design scalable, maintainable, and performant AI-enabled database solutions in Azure.

Practice Exam Questions

Question 1

A company loads data from an Azure SQL Database into a Microsoft Fabric warehouse every hour. The ETL process should retrieve only rows that have changed since the previous load, including the previous and new values of updated rows.

Which technology should you recommend?

A. Change Tracking

B. Change Data Capture (CDC)

C. Azure Logic Apps

D. Azure Functions with SQL Trigger Binding

Correct Answer: B

Explanation

CDC is specifically designed for incremental data movement scenarios. It captures inserts, updates, and deletes directly from the transaction log and stores detailed information about each change, including before and after values where applicable.

Why the other options are incorrect:

A: Change Tracking identifies changed rows but does not store previous values.
C: Logic Apps orchestrate workflows but do not capture database changes.
D: Azure Functions respond to events but are not intended to maintain historical change data for ETL.

Question 2

A mobile application periodically synchronizes customer records with an Azure SQL Database. The application only needs to know which rows have changed since the last synchronization and does not require historical values.

Which feature is most appropriate?

A. Change Event Streaming

B. Azure Functions SQL Trigger

C. Change Tracking

D. CDC

Correct Answer: C

Explanation

Change Tracking is optimized for synchronization scenarios. It records that rows have changed while minimizing storage and processing overhead.

Why the other options are incorrect:

A: CES is designed for event-driven architectures.
B: Azure Functions execute custom code rather than maintaining synchronization metadata.
D: CDC stores detailed change history, which is unnecessary here.

Question 3

An online retailer wants every new order inserted into the Orders table to immediately trigger inventory updates, shipping notifications, and fraud detection.

Which solution best supports this requirement?

A. Scheduled polling queries

B. Change Tracking

C. Change Event Streaming (CES)

D. Nightly ETL jobs

Correct Answer: C

Explanation

CES enables near real-time event publishing whenever database changes occur. Multiple downstream systems can subscribe to the same event without repeatedly querying the database.

Why the other options are incorrect:

A: Polling introduces unnecessary latency and database load.
B: Change Tracking is intended for synchronization rather than event processing.
D: Nightly ETL introduces unacceptable delays.

Question 4

A database update should automatically execute custom C# code that calls several REST APIs and writes audit information to Azure Storage.

Which Azure service should you recommend?

A. Azure Functions with SQL Trigger Binding

B. CDC

C. Change Tracking

D. SQL Agent Job

Correct Answer: A

Explanation

Azure Functions with SQL Trigger Binding automatically execute custom code when qualifying database changes occur, making them ideal for serverless business logic.

Why the other options are incorrect:

B: CDC records changes but does not execute code.
C: Change Tracking simply records row modifications.
D: SQL Agent jobs rely on scheduled execution rather than event-driven processing.

Question 5

Which statement correctly compares Change Tracking and Change Data Capture?

A. CDC captures complete change history while Change Tracking records only that rows changed.

B. Change Tracking captures previous values while CDC does not.

C. Both features store identical information.

D. CDC only tracks INSERT operations.

Correct Answer: A

Explanation

CDC stores detailed information about every change, including inserts, updates, deletes, timestamps, and transaction metadata. Change Tracking only identifies which rows have changed.

The remaining options are incorrect because they reverse the capabilities or incorrectly describe CDC.

Question 6

A business analyst wants to automate the following workflow without writing custom code:

Detect a new customer record.
Send an Outlook email.
Post a Microsoft Teams notification.
Update a SharePoint list.

Which solution is the best choice?

A. CDC

B. Azure Logic Apps

C. Change Tracking

D. SQL CLR

Correct Answer: B

Explanation

Azure Logic Apps provide low-code workflow automation with hundreds of built-in connectors, making them ideal for orchestrating business processes across Microsoft services.

Why the other options are incorrect:

A: CDC captures changes but does not automate workflows.
C: Change Tracking only records modified rows.
D: SQL CLR requires custom coding and is not intended for cloud workflow automation.

Question 7

A development team currently polls the database every minute to determine whether new records have been inserted.

What is the primary disadvantage of this design?

A. It reduces database normalization.

B. It prevents indexing.

C. It increases transaction isolation.

D. It generates unnecessary database workload and introduces latency.

Correct Answer: D

Explanation

Polling repeatedly queries the database even when no changes exist, increasing resource consumption while delaying event processing.

Event-driven solutions such as CES or Azure Functions eliminate this inefficiency.

Question 8

Which technology is most appropriate when an organization must maintain a complete historical record of all row changes for regulatory auditing?

A. Azure Logic Apps

B. Change Tracking

C. Change Data Capture

D. Azure Functions

Correct Answer: C

Explanation

CDC preserves detailed information about inserts, updates, deletes, transaction sequence numbers, and timestamps, making it ideal for compliance and auditing.

The other technologies either automate workflows or identify changes without preserving historical values.

Question 9

Which feature is specifically intended to minimize synchronization overhead by storing only metadata about changed rows?

A. Azure Functions SQL Trigger

B. Change Tracking

C. Change Event Streaming

D. Azure Event Grid

Correct Answer: B

Explanation

Change Tracking records lightweight metadata that indicates which rows have changed, allowing applications to retrieve only the latest row versions.

The other options serve different purposes:

Azure Functions execute code.
CES publishes events.
Event Grid distributes events but does not track database modifications.

Question 10

A solution architect is selecting a technology for an event-driven microservices architecture. Multiple independent services must react immediately whenever product inventory changes.

Which solution best satisfies this requirement?

A. Nightly ETL processing

B. Change Tracking

C. Database polling every five minutes

D. Change Event Streaming (CES)

Correct Answer: D

Explanation

CES is designed for event-driven systems where multiple subscribers consume database change events in near real time. It minimizes latency and reduces unnecessary database queries.

Why the other options are incorrect:

A: Nightly processing is far too slow.
B: Change Tracking is intended for synchronization rather than event broadcasting.
C: Polling introduces unnecessary workload and delays.

Exam Tips

For the DP-800 exam, remember these key distinctions:

Change Data Capture (CDC) is best for incremental ETL, auditing, replication, and historical change tracking.
Change Tracking is designed for lightweight synchronization when only the fact that a row changed is needed.
Change Event Streaming (CES) enables near real-time event-driven architectures by publishing database changes to downstream consumers.
Azure Functions with SQL Trigger Binding are ideal for executing custom serverless code in response to database changes.
Azure Logic Apps provide low-code workflow automation for integrating Azure SQL with Microsoft and third-party services.
On the exam, Microsoft often presents multiple technologies that could work. Choose the one that best aligns with the business requirement, considering factors such as latency, historical tracking, automation, scalability, and operational overhead, rather than selecting the most feature-rich option.

Go to the DP-800 Exam Prep Hub main page