Courseiva
Implement Azure securitymediumMultiple ChoiceObjective-mapped

AZ-204 Implement Azure security Practice Question

You are developing a serverless API using Azure Functions. The API should only be accessible from a specific virtual network. You need to configure network security. What should you do?

⚠ Common exam trap

The trap here is that candidates might consider VNet integration (which primarily enables outbound connectivity from the Function App to the VNet) or IP restrictions on the public endpoint. However, for truly restricting inbound access *only* from a VNet and disabling public internet access, a Private Endpoint is the most robust and secure solution.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

Configure a private endpoint for the Function App and disable public access.

To ensure the Azure Function API is *only* accessible from a specific virtual network, the most secure and direct approach is to configure a private endpoint for the Function App within that VNet. A private endpoint assigns a private IP address from your VNet to the Function App, making it accessible privately within the VNet. Crucially, you must then disable public access to the Function App. This combination ensures that all traffic must flow through the private endpoint from within the VNet, thereby meeting the requirement for network-level isolation and restricting access exclusively to the specified VNet. Option C's explanation is misleading as VNet integration primarily enables outbound connectivity, and an NSG on the VNet-integrated subnet does not directly block public internet access to the Function App's public endpoint.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Place the Functions in Azure API Management and configure IP restrictions.

    Why it's wrong here

    Placing functions behind Azure API Management and configuring IP restrictions primarily secures access to the API Management gateway itself, not directly integrating the Function App into a Virtual Network (VNet) for internal communication or restricting its traffic within the VNet. While API Management can act as a facade, it does not provide the underlying VNet integration capabilities necessary for the Function App to access VNet resources privately or for traffic to be restricted at the network level within the VNet.

  • Configure IP address restrictions on the Function App to allow only the VNet's public IP range.

    Why it's wrong here

    Configuring IP address restrictions on the Function App to allow only the VNet's public IP range is an insecure and less dynamic approach. Public IP ranges can be broad, shared, or subject to change, offering weak network isolation compared to true VNet integration. This method only filters traffic based on source public IP, failing to embed the Function App within the VNet's private network space or leverage VNet-specific security controls like Network Security Groups for granular traffic management.

  • Deploy the Function App in a Premium plan and configure VNet integration, then use a Network Security Group to restrict traffic.

    Why it's wrong here

    Deploying the Function App in a Premium plan is a prerequisite for enabling VNet integration, which allows the function app to send outbound traffic into the VNet and receive inbound traffic from resources within the VNet via a delegated subnet. Subsequently, configuring a Network Security Group (NSG) on that delegated subnet provides granular control over both inbound and outbound network traffic, ensuring secure communication and robust isolation for the Function App within the VNet.

  • Configure a private endpoint for the Function App and disable public access.

    Why this is correct

    Configuring a private endpoint for the Function App primarily provides secure *inbound* access to the Function App from within a Virtual Network (VNet), making the service appear as if it's part of the VNet and disabling public access. However, a private endpoint does not inherently enable the Function App to establish *outbound* connections to other resources located *within* that VNet. VNet integration is the specific feature designed for a Function App to access resources inside a VNet.

Visual reference

192.168.1.0 /24 256 addresses (254 usable) 192.168.1.0 /25 Subnet A 128 addr (126 usable) 192.168.1.128 /25 Subnet B 128 addr (126 usable) Borrowing 1 bit from host portion creates 2 subnets (/25)

Quick reference

Cloud Service Model Comparison

ModelYou ManageProvider ManagesExamples
IaaSOS, runtime, apps, dataHardware, hypervisor, networkingEC2, Azure VMs, GCP Compute Engine
PaaSApps and dataOS, runtime, middleware, hardwareElastic Beanstalk, Azure App Service
SaaSData and settings onlyEverything elseMicrosoft 365, Salesforce, Workday
FaaS / ServerlessFunction code onlyInfra, scaling, runtimeLambda, Azure Functions, Cloud Run
CaaSContainers and appsKubernetes, OS, hardwareEKS, AKS, GKE

Go deeper

Related to this question

About these practice questions

Courseiva writes every AZ-204 question from scratch — 881 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This AZ-204 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-204 exam.