Develop Azure compute solutions →mediumMultiple ChoiceObjective-mapped

AZ-204 Develop Azure compute solutions Practice Question

Exhibit

{
  "resources": [
    {
      "type": "Microsoft.Web/sites",
      "apiVersion": "2022-03-01",
      "name": "[parameters('siteName')]",
      "location": "[resourceGroup().location]",
      "properties": {
        "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', parameters('hostingPlanName'))]",
        "siteConfig": {
          "alwaysOn": true,
          "linuxFxVersion": "DOTNETCORE|6.0",
          "appSettings": [
            {
              "name": "WEBSITE_RUN_FROM_PACKAGE",
              "value": "1"
            }
          ]
        }
      }
    }
  ]
}

Refer to the exhibit. You deploy this ARM template to create an Azure App Service. After deployment, the application stops responding after a few minutes. The application is a .NET 6 web API that runs in a Linux container. What is the most likely cause?

⚠ Common exam trap

Many candidates assume 'alwaysOn' is a harmless performance setting, but Azure enforces it only on paid tiers, and enabling it on an unsupported tier silently breaks the app after idle timeouts.

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 'alwaysOn' setting is enabled but the App Service plan is on a tier that does not support Always On.

The 'alwaysOn' setting keeps the app loaded even after periods of inactivity, but it is only supported on Basic, Standard, Premium, and Isolated tiers. If the App Service plan is on a Free or Shared tier, enabling 'alwaysOn' causes the app to stop responding after a few minutes because the platform forcibly unloads idle apps, leading to timeouts or crashes.

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 ARM template is missing the 'dependsOn' element.
Why it's wrong here
The 'dependsOn' element is not universally required for Azure Resource Manager (ARM) template deployments. ARM intelligently infers dependencies between resources when one resource explicitly references another's ID or properties, such as an App Service referencing its App Service Plan's resource ID. If the App Service Plan is defined earlier in the template or its ID is directly used by the App Service, ARM can establish the correct deployment order without an explicit 'dependsOn' declaration, allowing the template to deploy successfully without this element.
✗
The 'linuxFxVersion' is set incorrectly for .NET 6.
Why it's wrong here
The 'linuxFxVersion' setting 'DOTNETCORE|6.0' is indeed the correct and standard configuration string for deploying a .NET 6 application to an Azure App Service running on a Linux operating system. This specific format instructs the App Service platform to provision the necessary runtime environment, including the .NET 6 SDK and associated dependencies, ensuring the application can execute properly within the Linux container. Therefore, this setting is correctly specified for a .NET 6 application.
✓
The 'alwaysOn' setting is enabled but the App Service plan is on a tier that does not support Always On.
Why this is correct
This is the correct answer because the 'alwaysOn' setting, when enabled, is designed to keep an application loaded in memory to prevent cold starts and ensure continuous availability. However, this feature is only supported on specific App Service plan tiers, typically Basic, Standard, Premium, or Isolated, which guarantee dedicated resources. On Free or Shared tiers, the 'alwaysOn' setting is silently ignored by the Azure platform, meaning the application can still be unloaded due to inactivity, leading to performance issues and unexpected delays for users. While the deployment won't fail, the desired functionality won't be achieved.
✗
The 'WEBSITE_RUN_FROM_PACKAGE' app setting is incorrectly set to '1'.
Why it's wrong here
The 'WEBSITE_RUN_FROM_PACKAGE' app setting, when set to '1', is a valid and recommended configuration for Azure App Services. This setting instructs the App Service to mount the deployment package (typically a ZIP file) as a read-only file system, rather than extracting its contents to the `wwwroot` directory. This approach offers benefits such as reduced file lock issues during deployment, improved startup times, and atomic deployments, making '1' a perfectly correct and functional value for this setting.

Go deeper

AZ-204 Develop Azure compute solutions Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question