Microsoft Azure Developer Associate Practice Test (AZ-204)

The Diagnose and solve problems blade in the Azure portal includes the Collect Memory Dump tool. This feature captures a full memory and thread dump of the running worker process while the site continues to serve traffic, so no application restart is required. Kudu's WebSSH console can browse the file system and run commands but cannot create process dumps. Log Stream only streams existing logs and error messages; it does not take memory snapshots. Application Insights Profiler records CPU and execution traces, not complete memory dumps needed to inspect thread states.

The built-in lifecycle management policy supports the tierToArchive action for base blobs. Setting the property daysAfterModificationGreaterThan to 90 directs Azure Storage to move any matching blob to the Archive tier 90 days after its last modification. The daysAfterLastAccessGreaterThan property targets last access, not modification. The snapshot scope and the tierToCool action do not satisfy the requirement to archive base blobs.

The authorization code flow with Proof Key for Code Exchange (PKCE) is the recommended OAuth 2.0 flow for SPAs using the Microsoft identity platform. It does not require a client secret, includes the user's delegated claims in the issued access token, complies with Conditional Access policies, and replaces the older implicit grant. The client-credentials grant is intended for app-only tokens and therefore lacks user claims. Resource-owner-password-credentials transmits user credentials directly and is incompatible with Conditional Access. The implicit grant is deprecated for new solutions because it exposes tokens in the browser address bar and cannot meet modern security requirements.

The OnFailure restart policy instructs Azure Container Instances to monitor the main process running inside the container. If the process exits successfully (exit code 0), the container stops and remains stopped, so billing for CPU and memory ceases. If the process exits with a non-zero code, ACI interprets this as a failure and restarts the container automatically. The Always policy keeps restarting the container even after successful completion, incurring unnecessary cost. The Never policy prevents any automatic restart, so a failure would leave the container stopped. UnlessStopped is not a valid ACI restart policy.

The az acr build command sends the current directory context to the Azure Container Registry build service, which performs the docker build operation in Azure and automatically pushes the resulting image to the specified registry. Using --registry identifies the target ACR, and --image supplies the desired repository name and tag. The trailing period (.) indicates the local context to upload. az acr task create sets up a persistent task but does not immediately build the image; docker build runs locally and therefore requires Docker Engine; az container create provisions a container instance and does not build or push images.

Connection strings or app settings that are marked as slot settings stay with the slot during a swap. By marking the DefaultConnection connection string as a slot setting, the value that points to the test database remains in the staging slot after the swap, while the production slot retains the production database connection string. Enabling auto-swap or traffic routing does not affect configuration persistence, and marking the APPINSIGHTS_INSTRUMENTATIONKEY setting does not address the database requirement.

Autoscale for Azure App Service is configured at the App Service plan level, not on the individual web app. Scaling operations are performed by Azure Monitor against the plan resource itself, so they continue to add or remove worker instances even when a particular web app in that plan is stopped. Configuring autoscale on Application Insights, the resource group, or the web app would not meet the requirement, because none of those resources are responsible for the underlying worker pool that actually scales.

Live Metrics Stream (formerly QuickPulse) displays near-real-time telemetry that is pushed directly from the SDK every second. It shows request rate, response time, failure count, CPU and memory usage, and lets you inspect individual failed requests immediately, whereas the Logs blade (Kusto queries) relies on data that is ingested and can be delayed by several minutes. Alert rules, Workbooks, and the Failures pane depend on that ingested data and therefore cannot fulfil the "within a few seconds" requirement.

When you enable Continuous Deployment for an ACR-based image in the App Service Deployment Center, the portal creates a webhook in the registry that targets the web app. Every time the specified tag is pushed, ACR sends the webhook, which triggers App Service to pull and start the new image automatically. Changing WEBSITES_CONTAINER_START_TIME_LIMIT only affects the startup timeout and does not trigger image refreshes. Run-From-Package deploys code, not containers. Autoswap between deployment slots orchestrates slot traffic changes but does not cause the app to detect a new image in the registry.

Azure Container Apps supports traffic-splitting across revisions only when revision management is set to multiple. The default setting for a newly created container app is single, which keeps only the latest revision active and routes all traffic to it. Changing the container app's revisionMode property to multiple (for example by running "az containerapp update --revision-mode multiple" or by redeploying with a YAML template that sets revisionMode: multiple) enables multiple active revisions and allows you to assign traffic weights such as 80/20. Enabling Dapr, configuring autoscale rules, or adding an external Azure Traffic Manager profile do not activate the built-in revision traffic-splitting capability, and creating a second container app would require DNS or gateway changes rather than the built-in percentage-based routing inside a single container app.

Azure App Service supports continuous deployment for custom container images. Enabling this feature causes the platform to create a webhook in Azure Container Registry and to restart the web app whenever a new image with the same tag is pushed. This capability is enabled by adding the application setting "DOCKER_ENABLE_CI" and setting its value to "true" (the portal adds this automatically when you switch on Continuous Deployment). The other settings do not trigger image pulls when the tag is updated: WEBSITE_PULL_IMAGE_ON_STARTUP is not a recognized key, WEBSITES_PORT only defines the container's listening port, and Always On merely prevents the app from unloading during idle periods.

The Azure.Extensions.AspNetCore.Configuration.Secrets package provides the AddAzureKeyVault extension, which loads secrets directly into IConfiguration. Passing the vault URI and a DefaultAzureCredential instance allows the SDK to obtain a token through the app's system-assigned managed identity when running in Azure, so no credentials are embedded in code. User secrets, environment variables, and JSON files all require storing the connection string elsewhere and do not pull it from Key Vault automatically.

ACI can authenticate to a private Azure Container Registry with a managed identity. By assigning a user-assigned managed identity to the container group and granting that identity the built-in AcrPull role on the registry, ACI can obtain an access token at runtime without any credentials being stored in templates or scripts. Enabling the admin user or anonymous access exposes credentials or the registry, and moving the image to a public repository violates the requirement to keep the image in the private ACR.

Because the function runs as a background (daemon) process, it must use the client-credentials flow to obtain an app-only access token-no delegated (user) context is available. The least-privileged Microsoft Graph scope that grants read access to the full set of user objects is the application permission User.Read.All. Directory.Read.All would also work but exposes additional directory data, so it is not the least-privileged choice. Delegated permissions or on-behalf-of flows require a signed-in user and are therefore unsuitable for this scenario.

The az acr build command builds container images in Azure Container Registry Tasks and automatically pushes the resulting image to the specified registry. The --registry parameter targets the registry, while multiple --image parameters add the desired tags. Providing the GitHub repository URL as the final argument sets the build context. Other options are incorrect because they either use invalid syntax for az acr build, rely on a local docker build that would not push both tags in one step, or use az acr import, which pulls an already-built image rather than building from source.

A Web App cannot exist unless it is associated with an App Service plan that specifies the region, operating system, and pricing tier that will supply the underlying compute resources. Creating a Linux App Service plan in East US2 on the B1 tier fulfills these prerequisites. The other resources can be useful but are not mandatory for creating the Web App. An Azure Container Registry is only required if you need a private registry; the app can also pull from public registries. A virtual network with a delegated subnet is necessary only for an App Service Environment, which is not required in this scenario. An AKS cluster is unrelated to Azure App Service and would not host an App Service Web App.

Dependency telemetry is automatically captured by the ASP.NET Core Application Insights SDK and records each call made by the application to external components such as SQL databases, REST services, and queues. The telemetry includes the dependency name, target, success or failure, and the duration of the call, allowing you to analyze average or percentile latency. Request telemetry measures incoming HTTP requests to your API, not outbound calls. Page view telemetry is produced by JavaScript on client pages, and performance counter telemetry surfaces server resource metrics such as CPU or memory-neither provides the timing of outbound dependencies.

Azure Container Apps offers event-driven KEDA-based scaling that can react to Azure Service Bus queue length and can scale down to zero when there is no load. It also supplies built-in HTTP ingress with the ability to generate and renew managed TLS certificates. Because it is a fully managed serverless platform, you do not provision or operate any underlying VMs or Kubernetes control plane.

Azure Container Instances runs single or manually scaled groups of containers and has no native event-driven auto-scaling. Azure Kubernetes Service with the KEDA add-on can satisfy the scaling requirement, but you would still have to create and administer the Kubernetes cluster. App Service Web App for Containers supports HTTP ingress and autoscale, yet it cannot scale to zero and does not natively scale on queue length events.

The az acr build command submits the build context to the Azure Container Registry task service, which performs the Docker build and pushes the resulting image back to the registry. Because the build happens in Azure, Docker does not need to be installed in the local environment. The command must reference the target registry and provide the desired image name and tag. az acr import copies an existing image from another registry, not a local build context. Combining docker build and docker push requires the Docker engine to be available, which contradicts the requirements. az container create deploys a running container instance and does not build or publish an image.

The Standard test is the only built-in Application Insights availability test that lets you configure advanced options such as SSL certificate validation and custom request headers while still being codeless. A URL ping test is limited to a simple GET operation with no header customization or certificate checks. A custom TrackAvailability test does support any logic you write, but it requires adding code to the application and therefore does not meet the "without writing code" requirement. A multi-step web test is deprecated for new resources and is no longer the recommended choice.