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:

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:

1. Managed identity
2. Microsoft Entra authentication
3. Azure Key Vault
4. 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:

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

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:

1. Private Endpoint limits network exposure.
2. Microsoft Entra ID authenticates callers.
3. Authorization controls what authenticated callers can do.
4. Managed Identity authenticates the Function to Azure services.
5. Key Vault protects secrets.
6. Azure SQL private endpoint minimizes database exposure.
7. Azure RBAC controls management access.
8. 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