Design and implement build and release pipelines →hardMultiple ChoiceObjective-mapped

AZ-400 Practice Question: Design and implement build and release pipelines

Exhibit

Refer to the exhibit.

```bicep
param location string = resourceGroup().location
param appName string
param containerImage string

resource appService 'Microsoft.Web/sites@2022-09-01' = {
  name: appName
  location: location
  kind: 'app,linux'
  properties: {
    siteConfig: {
      linuxFxVersion: 'DOCKER|${containerImage}'
      appSettings: [
        {
          name: 'WEBSITES_ENABLE_APP_SERVICE_STORAGE'
          value: 'false'
        }
      ]
    }
  }
}
```

Refer to the exhibit. You deploy this Bicep template to create an Azure App Service with a custom container. The deployment succeeds, but the container fails to start with an error 'Container didn't respond to HTTP pings'. What is the most likely missing configuration?

⚠ Common exam trap

Watch out — candidates often confuse the health check path with the container port setting (WEBSITES_PORT), assuming the ping failure is due to a port mismatch rather than the HTTP endpoint not being reachable on the default path.

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

✓

The template is missing the 'healthCheckPath' property in siteConfig.

The error 'Container didn't respond to HTTP pings' indicates that Azure App Service's built-in health check mechanism is failing to reach the container. By default, App Service pings the root path ('/') on the container's exposed port. If the container's application does not respond on that path, the health check fails. Adding the 'healthCheckPath' property in siteConfig allows you to specify a custom endpoint (e.g., '/health') that the container can respond to, resolving the issue.

Answer analysis

Option-by-option breakdown

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

✓
The template is missing the 'healthCheckPath' property in siteConfig.
Why this is correct
The template omits the healthCheckPath property in siteConfig, which is required for App Service to route /health requests to the container's endpoint and remove unhealthy instances from the load balancer. Without this property, the container's custom health endpoint is never probed, so the deployment fails validation if the container requires a specific path.
✗
The container image is not publicly accessible.
Why it's wrong here
The container image's accessibility is not the primary issue; while a private registry would need credentials in template (e.g., registryCredentials in siteConfig), the health check failure occurs because App Service cannot verify liveness when healthCheckPath is absent. Even if the image is publicly accessible, the deployment still fails due to missing health probe configuration.
✗
The WEBSITES_ENABLE_APP_SERVICE_STORAGE should be set to 'true'.
Why it's wrong here
Setting WEBSITES_ENABLE_APP_SERVICE_STORAGE to true enables persistent storage mapping (e.g., D:/home) for the container, but it does not affect health check behavior. Health checks rely on the healthCheckPath property and the container's endpoint response, not storage settings, so this option does not address the template's omission.
✗
The template is missing the app setting 'WEBSITES_PORT'.
Why it's wrong here
The WEBSITES_PORT app setting customizes the port the container listens on, but the default is 80; if the container uses a non-default port, it must be specified. However, the question explicitly indicates the health check path is missing, and without healthCheckPath, even a correct port does not enable the required health probe that the deployment expects.

Visual reference

Go deeper

AZ-400 Practice Question: Design and implement build and release pipelines

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question