Connect to and consume Azure services and third-party services →mediumMultiple ChoiceObjective-mapped

AZ-204 Practice Question: Connect to and consume Azure services and third-party services

Exhibit

{
  "type": "Microsoft.CognitiveServices/accounts",
  "apiVersion": "2023-05-01",
  "name": "myopenai",
  "location": "eastus",
  "kind": "OpenAI",
  "sku": {
    "name": "S0"
  },
  "properties": {
    "customSubDomainName": "myopenai",
    "networkAcls": {
      "defaultAction": "Deny",
      "ipRules": [
        {
          "value": "203.0.113.0/24"
        }
      ]
    }
  }
}

Refer to the exhibit. An Azure OpenAI Service account is deployed with this ARM template. After deployment, a developer tries to call the OpenAI endpoint from an Azure App Service that has no public IP. The request is blocked. What change should be made to allow access?

⚠ Common exam trap

It's easy for candidates to assume IP-based firewall rules (like adding outbound IPs) are sufficient, but they overlook that an App Service without a public IP cannot be reached via IP rules, and that private endpoints are the correct solution for private, secure access to PaaS services.

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 OpenAI account.

The ARM template sets `networkAcls.defaultAction` to `Deny`, which blocks all traffic by default. Since the App Service has no public IP, it cannot be reached via IP-based rules. Configuring a private endpoint for the OpenAI account creates a private network connection over Azure's backbone, bypassing the public endpoint and allowing the App Service to access the OpenAI service securely without requiring a public IP.

Answer analysis

Option-by-option breakdown

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

✗
Add a service tag for App Service in the ipRules.
Why it's wrong here
Azure OpenAI service network security rules, specifically IP rules, are designed to accept individual IP addresses or CIDR ranges, not Azure Service Tags. Service Tags represent a group of IP address prefixes for a given Azure service, like `AppService`, but their primary use is in Network Security Groups (NSGs) or Azure Firewall rules to simplify network configuration. Attempting to use a service tag directly within an OpenAI service's `ipRules` configuration will result in an invalid configuration, as this feature is not supported for direct resource-level IP filtering.
✓
Configure a private endpoint for the OpenAI account.
Why this is correct
Configuring a private endpoint for the Azure OpenAI account establishes a secure, private connection from your Azure Virtual Network to the OpenAI service. This solution ensures that traffic between your App Service, residing within a VNet, and the OpenAI service traverses the Microsoft backbone network privately, bypassing the public internet entirely. The private endpoint assigns a private IP address from your VNet to the OpenAI resource, allowing secure access and eliminating the need to expose the OpenAI service to public IP ranges or manage outbound IP addresses.
✗
Change the defaultAction to Allow.
Why it's wrong here
Changing the `defaultAction` for the Azure OpenAI service's network rules to `Allow` would permit all network traffic, regardless of its source IP address, to access the service by default. While this would resolve connectivity issues, it severely compromises the security posture of the OpenAI resource by exposing it to the public internet without any IP-based restrictions. This approach violates the principle of least privilege and is highly discouraged for production environments due to the significant risk of unauthorized access and potential data exfiltration.
✗
Add the App Service's outbound IP address to the ipRules.
Why it's wrong here
Adding the App Service's outbound IP address to the Azure OpenAI service's `ipRules` is an unreliable and potentially insecure solution. Azure App Services, especially those on multi-tenant plans, can have dynamic outbound IP addresses that change over time or when scaled, requiring constant updates to the firewall rules. Furthermore, these outbound IPs are shared among multiple tenants, meaning that allowing access based solely on these IPs could inadvertently grant access to other services sharing the same outbound IP, posing a security risk.

Go deeper

AZ-204 Practice Question: Connect to and consume Azure services and third-party services

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question