Microsoft Azure Developer Associate AZ-204 AZ-204 Questions 301–375 | Page 5/12

301

MCQhard

Refer to the exhibit. You deployed an Azure Storage account with this ARM template. Users outside the allowed IP range receive '403 Forbidden' errors. What is the MOST likely cause?

A.The access tier is Cool

B.The minimum TLS version is set to TLS1_2

C.The IP rule allows only 203.0.113.0/24

D.The network ACL default action is Deny

AnswerD

When the network ACL default action for an Azure Storage account is set to 'Deny', it explicitly blocks all network traffic to the storage account by default. This means that only requests originating from IP addresses or Virtual Network subnets that are explicitly added to the allowed list will be permitted. Any client attempting to access the storage account from an unlisted network source will receive a 403 Forbidden error, as their request is understood but explicitly unauthorized by the network security configuration.

Why this answer

The default action for network ACLs in Azure Storage is 'Deny' when no explicit rules match. Since the ARM template only allows traffic from the IP range 203.0.113.0/24, all other IP addresses are implicitly denied, resulting in 403 Forbidden errors for users outside that range.

Exam trap

The trap here is that candidates often focus on the IP rule (option C) as the direct cause, but the real issue is the default action being set to 'Deny', which makes the rule an exclusive allow list rather than a permissive one.

How to eliminate wrong answers

Option A is wrong because the access tier (Cool vs. Hot) affects storage costs and retrieval latency, not network access control; it cannot cause 403 errors. Option B is wrong because the minimum TLS version (TLS1_2) enforces encryption protocol requirements for client connections, but it does not block IP addresses; a client using TLS 1.2 would still be allowed if its IP is permitted.

Option C is wrong because the IP rule allowing only 203.0.113.0/24 is the explicit allow rule, but it is not the cause of the 403 error—the error occurs because the default action (Deny) blocks all other IPs, not because the rule itself is restrictive.

Full explanation →

302

MCQmedium

You are using Application Insights to monitor an ASP.NET Core web API. Users report that a specific endpoint is slow, but you cannot reproduce the issue in development. You need to identify which line of code is causing the delay in production. Which Application Insights feature should you use?

A.Use the Application Insights Map to visualize dependencies.

B.Enable Application Insights Profiler.

C.Use the Snapshot Debugger to capture debug snapshots on exceptions.

D.Create a custom telemetry event in the slow endpoint to log timing data.

AnswerB

Application Insights Profiler is the correct tool because it automatically collects detailed execution traces for requests, capturing the call stack and timing for each method invocation. This allows developers to precisely identify the 'hot path' within their code, revealing exactly where CPU time is being spent and pinpointing the specific lines of code responsible for performance bottlenecks without manual instrumentation. It provides deep, method-level insights into application performance.

Why this answer

Application Insights Profiler is designed specifically to trace code-level performance issues in production without requiring code changes or reproducing the problem. It captures detailed call stacks and timing for each request, allowing you to identify exactly which line of code is causing the delay. This makes it the correct choice for diagnosing a slow endpoint that cannot be reproduced in development.

Exam trap

The trap here is that candidates often confuse the Snapshot Debugger (for exceptions) with the Profiler (for performance), or assume custom telemetry is the only way to get timing data, missing that the Profiler provides automatic, line-level diagnostics without code changes.

How to eliminate wrong answers

Option A is wrong because the Application Insights Map visualizes dependencies between services (e.g., databases, external APIs) but does not provide line-by-line code execution timing. Option C is wrong because the Snapshot Debugger captures debug snapshots only when exceptions are thrown, not for slow performance without exceptions. Option D is wrong because creating a custom telemetry event requires modifying the application code and redeploying, which is not a built-in feature for diagnosing existing production slowness without prior instrumentation.

Full explanation →

303

MCQmedium

You deploy a containerized background job to Azure Container Instances (ACI). The job should automatically restart only if it exits with a non-zero exit code (i.e., crashes). You want to minimize costs. Which restart policy should you configure?

A.Always

B.OnFailure

C.Never

D.Retry

AnswerB

The "OnFailure" restart policy is specifically designed for task-based or batch jobs that require retries only when they terminate unexpectedly. It instructs Azure Container Instances to restart the container exclusively when its exit code is non-zero, which signifies an error or abnormal termination. This precisely matches the requirement to restart on failure, preventing unnecessary re-execution of successfully completed jobs and optimizing resource utilization and cost efficiency for idempotent background tasks.

Why this answer

The OnFailure restart policy is correct because it restarts the container only when it exits with a non-zero exit code, indicating a crash or error. This matches the requirement to automatically restart only on failure while minimizing costs, as it avoids unnecessary restarts on successful completions.

Exam trap

The trap here is that candidates may confuse the OnFailure policy with the Always policy, thinking that Always is needed for automatic restarts, but they overlook the cost implication and the specific requirement to restart only on failure.

How to eliminate wrong answers

Option A is wrong because the Always restart policy restarts the container regardless of the exit code, even on successful completions, which would incur unnecessary costs and is not aligned with the requirement to restart only on failure. Option C is wrong because the Never restart policy does not restart the container under any circumstances, so it would not automatically restart on a crash. Option D is wrong because Retry is not a valid restart policy for Azure Container Instances; the valid policies are Always, OnFailure, and Never.

Full explanation →

304

Multi-Selectmedium

You need to secure access to an Azure Storage account that contains sensitive data. Which TWO of the following are recommended best practices?

Select 2 answers

A.Rotate storage account keys every 24 hours

B.Use managed identities to access storage from Azure services

C.Configure firewall rules to restrict access to specific IP addresses or VNets

D.Use SAS tokens with long expiry dates

E.Enable anonymous public access for all containers

AnswersB, C

Using managed identities is a highly recommended security practice for Azure services accessing storage, as it eliminates the need to store or manage credentials within application code. Managed identities provide an automatically managed identity in Azure Active Directory, enabling secure authentication and authorization to storage accounts via Azure Role-Based Access Control (RBAC). This approach significantly reduces the risk of credential leakage and simplifies security management.

Why this answer

Option B is correct because managed identities let Azure services (such as VMs, App Service, or Functions) authenticate to Storage using Azure AD tokens, eliminating the need to store and manage storage account keys or connection strings in code or configuration. Option C is correct because configuring firewall rules on the storage account to allow only specific public IP addresses or Azure virtual networks (via service endpoints or private endpoints) restricts network-level access to trusted sources, which is a core defense-in-depth practice for sensitive data. Option A is not recommended because rotating keys every 24 hours is operationally impractical and unnecessary; Microsoft recommends periodic rotation (for example, every 90 days) or, better, avoiding keys entirely by using Azure AD/managed identities.

Option D is wrong because long-lived SAS tokens increase the exposure window if leaked; SAS tokens should be short-lived and scoped with least privilege. Option E is wrong because enabling anonymous public access to all containers exposes data to anyone on the internet and directly violates the goal of securing sensitive data.

Exam trap

The trap here is that candidates often think rotating keys frequently (Option A) is always better, but Azure's best practices emphasize reducing key usage entirely via managed identities, not just rotating keys more often.

Full explanation →

305

MCQmedium

Twenty Azure Functions across different teams all need read access to the same Azure Cosmos DB account. The security team wants to revoke or modify this access for all twenty functions at once without visiting each Function App individually. What managed identity design satisfies this requirement?

A.Create one user-assigned managed identity, attach it to all twenty Function Apps, and grant it the Cosmos DB Built-in Data Reader role

B.Enable a system-assigned managed identity on each Function App and grant each identity the Cosmos DB Built-in Data Reader role

C.Create a service principal, store its client secret in Key Vault, and reference the secret from all twenty Function Apps via Key Vault references

D.Store the Cosmos DB connection string in Azure App Configuration and reference it from all twenty Function Apps

AnswerA

The role assignment on the user-assigned identity propagates instantly to all twenty Function Apps that reference it. Revoking the role assignment revokes access everywhere simultaneously. Adding a new Function App just requires attaching the existing identity — no new role grants are needed.

Why this answer

A single user-assigned managed identity can be created once and then attached to all twenty Function Apps. Granting that identity the Cosmos DB Built-in Data Reader role at the Cosmos DB account scope means that revoking or modifying the role assignment centrally affects all functions simultaneously, without needing to visit each app individually.

Exam trap

The trap here is that candidates often confuse system-assigned managed identities (which are tied to a single resource) with user-assigned managed identities (which can be shared across resources), leading them to choose Option B because they think 'managed identity' automatically means system-assigned, missing the central management requirement.

How to eliminate wrong answers

Option B is wrong because each system-assigned managed identity is unique per Function App, so you would have to grant the Cosmos DB role to each identity individually, and revoking or modifying access would require updating each role assignment separately. Option C is wrong because using a service principal with a client secret stored in Key Vault introduces secret management overhead and does not leverage managed identities; revoking access would require rotating the secret or modifying the service principal, not a single role assignment. Option D is wrong because storing the Cosmos DB connection string in App Configuration and referencing it from each Function App does not provide a central point to revoke or modify access—each app still uses the same static connection string, and revoking access would require changing the connection string and redeploying or updating each app's configuration reference.

Full explanation →

306

MCQmedium

Tailwind Traders uses Azure Logic Apps to orchestrate a multi-step business process. The workflow must call an external REST API that requires OAuth 2.0 authentication. The API is registered in Microsoft Entra ID. The Logic App must authenticate using a system-assigned managed identity. The API's app registration has been configured to accept tokens from the managed identity. Which connector should the team use in the Logic App to call the API, and how should they configure authentication?

A.Use the HTTP connector. In the connector's authentication settings, choose 'Managed Identity' and select the system-assigned identity. Set the audience to the API's Application ID URI.

B.Use the HTTP connector with 'Active Directory OAuth' authentication. Provide the client ID and client secret of a service principal.

C.Use the custom connector. In the custom connector's authentication, choose 'Managed Identity' and provide the managed identity's principal ID.

D.Use the Azure API Management connector. Configure it to use OAuth 2.0 with the managed identity.

AnswerA

The HTTP connector in Azure Logic Apps is the appropriate choice for invoking external HTTP endpoints. By selecting 'Managed Identity' authentication and choosing the system-assigned identity, the Logic App securely obtains an Azure AD access token without requiring any stored credentials. The 'Audience' parameter, set to the API's Application ID URI, is crucial as it specifies the intended recipient of the token, ensuring the token is valid for authenticating against that specific API. This method aligns with Azure's security best practices for service-to-service authentication.

Why this answer

The HTTP connector with 'Managed Identity' authentication is the correct choice because the Logic App needs to call an external REST API that accepts tokens from a system-assigned managed identity. By selecting 'Managed Identity' and setting the audience to the API's Application ID URI, the Logic App automatically acquires an access token from Microsoft Entra ID using the system-assigned identity, without needing to manage credentials. This aligns with the requirement for OAuth 2.0 authentication using a managed identity.

Exam trap

The trap here is that candidates may confuse 'Active Directory OAuth' with managed identity authentication, or assume a custom connector is necessary for custom APIs, when the HTTP connector with 'Managed Identity' is the simplest and most secure option for this scenario.

How to eliminate wrong answers

Option B is wrong because 'Active Directory OAuth' authentication requires a client ID and client secret of a service principal, which contradicts the requirement to use a system-assigned managed identity (no secrets to manage). Option C is wrong because custom connectors do not natively support 'Managed Identity' authentication; they require manual token acquisition or other OAuth flows, and providing the managed identity's principal ID is not a valid authentication configuration. Option D is wrong because the Azure API Management connector is designed for APIs exposed through Azure API Management, not for directly calling an external REST API, and it does not support managed identity authentication in this context.

Full explanation →

307

MCQhard

You host a web application on Azure App Service using multiple deployment slots (production and staging). After swapping staging into production, users report errors. You need to ensure that the staging slot is warmed up before swapping and that any errors during swap cause an automatic rollback. What should you configure?

A.Configure deployment slot settings to be sticky.

B.Enable auto swap and configure a custom warm-up path.

C.Use swap with preview and complete the swap after verification.

D.Configure manual swap and run a warm-up script before swapping.

AnswerB

Enabling auto swap combined with a custom warm-up path is the correct solution because it automates the entire deployment and verification process. Auto swap automatically initiates the swap after a successful deployment to the staging slot. The custom warm-up path ensures the application fully initializes and becomes responsive before the swap is finalized, and crucially, if the warm-up path returns an HTTP error, Azure App Service automatically rolls back the swap, preventing a broken application from reaching production.

Why this answer

Enabling auto swap with a custom warm-up path ensures the staging slot is fully warmed up before the swap occurs, and if the warm-up fails or the application returns errors during the swap, Azure App Service automatically rolls back to the previous slot. This directly addresses the requirement for both pre-swap warm-up and automatic rollback on errors.

Exam trap

The trap here is that candidates often confuse 'swap with preview' (which requires manual completion) with automatic rollback, or think that sticky settings alone can handle warm-up and error recovery, when in fact auto swap with a custom warm-up path is the only built-in mechanism that combines both warm-up and automatic rollback.

How to eliminate wrong answers

Option A is wrong because making deployment slot settings sticky (slot-specific) only ensures that configuration and connection strings remain with the slot after a swap; it does not provide any warm-up or automatic rollback functionality. Option C is wrong because swap with preview allows you to validate the staging slot before completing the swap, but it does not automatically roll back on errors; you must manually complete or cancel the swap, which does not meet the 'automatic rollback' requirement. Option D is wrong because manual swap with a warm-up script requires custom scripting and does not provide built-in automatic rollback on swap errors; the rollback would need to be manually orchestrated.

Full explanation →

308

MCQhard

Refer to the exhibit. You run this Azure CLI command to configure an Azure Web App for Containers. The web app fails to start, and the logs show 'unauthorized: authentication required'. What is the most likely cause?

A.The command did not include admin credentials or managed identity configuration

B.The image tag 'latest' does not exist

C.The web app is configured to use a deployment slot, but the slot is not specified

D.The --docker-registry-server-url is incorrect

AnswerA

The error likely indicates an unauthorized or access denied issue when the Azure Web App attempts to pull the Docker image from the Azure Container Registry (ACR). To successfully pull images from a private registry like ACR, the web app requires explicit authentication. This can be achieved by providing ACR admin credentials (username and password) via application settings or by configuring a system-assigned or user-assigned managed identity with AcrPull role permissions on the ACR. Without either method, the pull operation will fail due to lack of authorization.

Why this answer

The Azure CLI command `az webapp config container set` without specifying `--docker-registry-server-user` and `--docker-registry-server-password` (or a managed identity configuration) means the web app cannot authenticate with a private container registry. The 'unauthorized: authentication required' error indicates the registry requires credentials, and the web app has none configured, so it fails to pull the image.

Exam trap

The trap here is that candidates assume the 'latest' tag always exists or that the registry URL is the only configuration needed, overlooking that private registries require explicit authentication credentials or managed identity setup.

How to eliminate wrong answers

Option B is wrong because if the 'latest' tag did not exist, the error would be 'manifest not found' or 'image not found', not 'unauthorized: authentication required'. Option C is wrong because deployment slots are unrelated to registry authentication; the error is about pulling the image, not routing traffic to a slot. Option D is wrong because an incorrect `--docker-registry-server-url` would cause a 'connection refused' or 'name resolution failure' error, not an authentication error.

Full explanation →

309

MCQeasy

You are developing an Azure Functions app that must run a cleanup task every night at 2:00 AM UTC. The function does not need to process any external events and should not be triggered by HTTP requests. Which trigger type should you use for this function?

A.HTTP trigger

B.Blob trigger

C.Queue trigger

D.Timer trigger

AnswerD

A timer trigger schedules function execution based on a CRON expression. It is designed exactly for time-based, recurring tasks like a nightly cleanup at 2:00 AM UTC. No external event or HTTP call is needed, and the schedule is defined declaratively in the function configuration, making it the correct choice.

Why this answer

A timer trigger is purpose-built for scheduled execution using a CRON expression. It runs the function automatically at the specified times without needing an external event or caller. For a cleanup task that must run nightly at 2:00 AM UTC and has no event source, the timer trigger is the appropriate and straightforward binding to use.

Exam trap

The trap here is confusing event-driven triggers with scheduled execution; only a timer trigger provides built-in CRON scheduling without an external event source.

Full explanation →

310

MCQeasy

You need to secure access to an Azure Storage account that hosts sensitive data. The requirement is to restrict access to only requests originating from a specific virtual network. Which feature should you configure?

A.Customer-managed keys (CMK)

B.Azure AD authentication

C.Shared access signatures (SAS)

D.Storage firewall and virtual network rules

AnswerD

Storage firewall and virtual network rules are the primary mechanism for securing network access to an Azure Storage account by defining which networks are permitted to connect. By configuring these rules, you can explicitly allow traffic only from specified Azure Virtual Networks, subnets, or public IP address ranges, effectively creating a network perimeter. This ensures that only trusted private networks or specific external endpoints can establish a connection, directly addressing the requirement for VNet-based access control.

Why this answer

D is correct because Azure Storage firewall and virtual network rules allow you to restrict access to your storage account to only requests originating from a specific virtual network. This is achieved by configuring a service endpoint or a private endpoint for the storage account, which ensures that traffic from the designated VNet is permitted while all other public internet traffic is blocked. This directly meets the requirement of restricting access to a specific virtual network.

Exam trap

The trap here is that candidates often confuse network-level access control (firewall and VNet rules) with authentication or encryption mechanisms, leading them to pick options like Azure AD authentication or CMK, which do not restrict traffic to a specific virtual network.

How to eliminate wrong answers

Option A is wrong because Customer-managed keys (CMK) are used for encrypting data at rest with a key managed by the customer, not for network-level access control. Option B is wrong because Azure AD authentication controls identity-based access to the storage account (e.g., for blobs or queues) but does not restrict traffic to a specific virtual network. Option C is wrong because Shared access signatures (SAS) provide delegated, time-limited access to specific storage resources via a token, but they do not limit the source network to a specific virtual network.

Full explanation →

311

MCQmedium

You are reviewing an Azure Policy definition that applies to storage accounts. The policy has an effect of 'deny' and specifies network ACLs. What is the intended behavior of this policy?

A.Allow all storage accounts to be created regardless of network rules

B.Deny all traffic to storage accounts

C.Deny creation of storage accounts that do not have a virtual network rule allowing vnet1 and default action set to Deny

D.Allow only traffic from the specified virtual network

AnswerC

This option is correct because the policy's 'Deny' effect, combined with its conditions, prevents the deployment of any new storage account that does not meet the specified network access requirements. Specifically, it ensures that a storage account must have a virtual network rule allowing access from 'vnet1' and that its default network action is set to 'Deny', thereby blocking all other traffic by default. This enforces a secure network posture at the time of resource provisioning.

Why this answer

The Azure Policy definition with effect 'deny' and network ACL conditions will block the creation of any storage account that does not include a virtual network rule allowing 'vnet1' and does not have the default action set to 'Deny'. This ensures that only storage accounts with the specified network restrictions are permitted, enforcing a security baseline that denies all traffic except from the allowed virtual network.

Exam trap

The trap here is that candidates may confuse the 'deny' effect on resource creation with network-level traffic denial, not realizing that Azure Policy controls resource configuration compliance, not runtime traffic flow.

How to eliminate wrong answers

Option A is wrong because a 'deny' effect policy does not allow all storage accounts; it explicitly blocks those that violate the defined network ACL rules. Option B is wrong because the policy does not deny all traffic to storage accounts; it only denies the creation of storage accounts that lack the required virtual network rule and default action, not traffic itself. Option D is wrong because the policy's effect is to deny creation of non-compliant storage accounts, not to allow traffic from the specified virtual network; traffic control is handled by the network ACL rules after the account is created.

Full explanation →

312

MCQeasy

You are building a web application that allows users to upload profile pictures. The images are up to 5 MB in size and must be stored durably. The images are accessed infrequently after upload (a few times per month). You want to minimize storage costs while ensuring the data is available within seconds when requested. Which Azure Blob Storage access tier should you use for the blob container?

A.Hot

B.Cool

C.Archive

D.Premium

AnswerB

The Cool tier is ideal for data that is accessed infrequently, perhaps a few times per month, but still requires immediate availability with low latency. Profile pictures fit this description perfectly, as they are not constantly accessed but must load instantly when requested. This tier offers a cost-effective balance with lower storage costs than Hot and no retrieval delays, making it suitable for user-uploaded content.

Why this answer

The Cool tier is the optimal choice because the images are accessed infrequently (a few times per month) and are up to 5 MB in size. Cool tier offers lower storage cost than Hot tier while still providing sub-second latency for data retrieval, meeting the requirement of availability within seconds. Archive tier would have the lowest storage cost but incurs a multi-hour rehydration delay, violating the seconds-level availability requirement.

Exam trap

The trap here is that candidates often choose Archive tier thinking it is the cheapest option, overlooking the critical requirement that data must be available within seconds, which Archive cannot provide due to its mandatory rehydration latency.

How to eliminate wrong answers

Option A is wrong because the Hot tier is designed for frequently accessed data and has higher storage costs than Cool, making it cost-inefficient for data accessed only a few times per month. Option C is wrong because the Archive tier requires a rehydration process (taking up to 15 hours) before data can be read, which fails the requirement that data must be available within seconds when requested. Option D is wrong because the Premium tier is optimized for low-latency access (sub-millisecond) and high transaction rates, but it incurs significantly higher costs than Cool and is over-provisioned for infrequently accessed profile pictures.

Full explanation →

313

MCQeasy

You are developing an API that will be hosted on Azure API Management (APIM). The API must be accessible only to clients that present a valid JSON Web Token (JWT) issued by Microsoft Entra ID. Which APIM policy should you use to validate the JWT?

A.<cors allow-credentials="true" />

B.<authenticate-basic />

C.<validate-jwt header-name="Authorization" failed-validation-httpcode="401" />

D.<check-header name="Authorization" failed-check-httpcode="401" />

AnswerC

The <validate-jwt header-name="Authorization" failed-validation-httpcode="401" /> policy is specifically engineered within Azure API Management to perform comprehensive validation of JSON Web Tokens. It verifies the token's cryptographic signature using a specified key, checks the issuer (iss) and audience (aud) claims, and ensures the token has not expired (exp claim). This policy is the correct mechanism for robustly authenticating requests secured with JWTs by ensuring their integrity and authenticity.

Why this answer

The <validate-jwt> policy in Azure API Management is specifically designed to enforce the presence and validity of a JSON Web Token (JWT) in incoming requests. By setting the header-name attribute to 'Authorization' and failed-validation-httpcode to '401', the policy checks that the JWT in the Authorization header is cryptographically signed by Microsoft Entra ID and has not expired, rejecting invalid or missing tokens with a 401 Unauthorized response.

Exam trap

The trap here is that candidates often confuse <check-header> with <validate-jwt>, assuming that simply checking for the presence of the Authorization header is sufficient for JWT validation, but <check-header> performs no cryptographic verification or claim validation, leaving the API vulnerable to forged or expired tokens.

How to eliminate wrong answers

Option A is wrong because <cors allow-credentials='true' /> is used to enable cross-origin resource sharing (CORS) for browser-based clients, not to validate JWT tokens. Option B is wrong because <authenticate-basic /> validates HTTP Basic Authentication credentials (username/password), not JSON Web Tokens, and is incompatible with Entra ID JWT-based authentication. Option D is wrong because <check-header name='Authorization' failed-check-httpcode='401' /> only verifies that the Authorization header is present, but does not decode, validate the signature, or check the expiration of a JWT, making it insufficient for token validation.

Full explanation →

314

MCQhard

You have a Durable Functions orchestration that calls an activity function which may throw an exception due to a transient network issue. You want to retry the activity up to 3 times with a 2-second delay between attempts and exponential backoff. Which method should you use in the orchestrator function?

A.await context.CallActivityAsync("MyActivity", input);

B.await context.CallActivityWithRetryAsync("MyActivity", new RetryOptions(TimeSpan.FromSeconds(2), 3), input);

C.await context.CallSubOrchestratorAsync("MyActivity", input);

D.await context.CallHttpAsync(HttpMethod.Get, new Uri("..."), input);

AnswerB

CallActivityWithRetryAsync accepts a RetryOptions object whose constructor takes the first-retry interval and maximum attempt count, and it applies exponential backoff automatically between attempts. This satisfies the stem's three retries, two-second initial delay, and exponential backoff requirement in a single orchestrator call.

Why this answer

The `CallActivityWithRetryAsync` method is specifically designed for retrying activity functions in Durable Functions. It accepts a `RetryOptions` object where you can configure the delay (`TimeSpan.FromSeconds(2)`) and the maximum number of retry attempts (3), and it automatically applies exponential backoff between retries. This directly satisfies the requirement to retry the activity up to 3 times with a 2-second initial delay and exponential backoff.

Exam trap

The trap here is that candidates may confuse `CallActivityWithRetryAsync` with `CallActivityAsync` or `CallSubOrchestratorAsync`, not realizing that only `CallActivityWithRetryAsync` provides the built-in retry mechanism with configurable delay and exponential backoff for activity functions.

How to eliminate wrong answers

Option A is wrong because `CallActivityAsync` does not support any retry logic; if the activity throws an exception, the orchestration will fail immediately without retrying. Option C is wrong because `CallSubOrchestratorAsync` is used to call another orchestrator function, not an activity function, and it does not provide built-in retry configuration for transient failures. Option D is wrong because `CallHttpAsync` is used for making HTTP calls from orchestrator functions, not for calling activity functions, and it does not support the retry policy described in the question.

Full explanation →

315

MCQmedium

You are developing an ASP.NET Core web API hosted on Azure App Service. The API must call a downstream REST service that requires a Microsoft Entra ID access token. Your team wants to avoid storing any credentials in code or configuration, and the App Service instance must be able to obtain the token without a signed-in user. You configure a user-assigned managed identity on the App Service. Which code should you use to acquire the token?

A.Use the Microsoft.Identity.Client (MSAL) library with ClientSecretCredential and a client secret stored in App Service application settings.

B.Use the Azure App Configuration client library to retrieve a pre-generated bearer token stored as a key-value pair.

C.Use DefaultAzureCredential from the Azure.Identity library and call GetTokenAsync with the downstream service scope.

D.Use the Azure App Service Authentication (Easy Auth) feature and read the X-MS-TOKEN-AAD-ACCESS-TOKEN header from the incoming request.

AnswerC

DefaultAzureCredential automatically discovers the managed identity when running in Azure App Service. It uses the token endpoint exposed by the App Service platform, so no secret is stored. Calling GetTokenAsync with the downstream API scope returns a valid access token that can be attached as a Bearer header, satisfying the requirement without credentials in configuration.

Why this answer

DefaultAzureCredential is the recommended way to obtain tokens in Azure-hosted code because it chains credential types and automatically uses the managed identity when deployed to App Service. This satisfies the requirement to avoid stored credentials and works without a signed-in user, since the managed identity is the principal that requests the token.

Exam trap

The trap here is assuming that Easy Auth or App Configuration can supply an outbound token, when only a credential like managed identity can mint a token for a downstream service.

Full explanation →

316

MCQhard

Your company develops a REST API for a global e-commerce platform that stores product images in Azure Blob Storage. The API uses shared access signatures (SAS) to grant temporary read access to the images. The security team requires that SAS tokens be generated using a user delegation key derived from the application's Microsoft Entra ID credentials, not from the storage account key. Additionally, the SAS must be scoped to a specific container and have a maximum validity of 1 hour. You need to implement the SAS generation in the API using the Azure Storage SDK for .NET. The application authenticates with Microsoft Entra ID using a managed identity assigned to the Azure App Service hosting the API. Which approach should you use?

A.Use the managed identity credentials to create a BlobServiceClient, then call GetUserDelegationKeyAsync to get a key, and then call BlobSasBuilder.GenerateSas using the key.

B.Use the StorageSharedKeyCredential with the storage account key to create a BlobSasBuilder and generate a SAS token.

C.Use DefaultAzureCredential to authenticate, then call GenerateUserDelegationSas on the BlobContainerClient.

D.Use the managed identity credentials to create a BlobServiceClient, then call GetUserDelegationKeyAsync, then create a BlobSasBuilder with the key and call ToSasQueryParameters.

AnswerD

This option correctly identifies the initial steps of using managed identity and `GetUserDelegationKeyAsync` to retrieve the user delegation key. However, `ToSasQueryParameters` on `BlobSasBuilder` only converts the builder's configured parameters into an unsigned query string fragment. It does not perform the crucial step of signing the SAS with the user delegation key to generate a complete, cryptographically secure SAS token; that function is performed by `GenerateSas`.

Why this answer

It follows the required pattern for generating a user delegation SAS: authenticate with managed identity via a BlobServiceClient, call GetUserDelegationKeyAsync to obtain a key derived from Microsoft Entra ID (not the storage account key), then use BlobSasBuilder with that key to call ToSasQueryParameters, which produces a SAS token query string scoped to a specific container with a 1-hour validity. This meets the security team's requirement of using Entra ID credentials and avoids exposing the storage account key.

Exam trap

The trap here is that candidates confuse the user delegation SAS workflow with the simpler account-key-based SAS, or mistakenly think that a direct 'GenerateUserDelegationSas' method exists on a container client. Additionally, candidates might confuse the conceptual 'generate SAS' with the specific SDK method `ToSasQueryParameters` on `BlobSasBuilder`, which is used after obtaining the user delegation key from the service client.

How to eliminate wrong answers

Option B is wrong because it uses StorageSharedKeyCredential with the storage account key, which violates the requirement to use Microsoft Entra ID credentials and exposes the account key. Option C is wrong because GenerateUserDelegationSas is not a method on BlobContainerClient; the correct approach requires explicitly calling GetUserDelegationKeyAsync on the BlobServiceClient and then building the SAS with BlobSasBuilder. Option D is wrong because ToSasQueryParameters returns a Uri query string, not a SAS token string; the correct method to generate the token string is GenerateSas on BlobSasBuilder.

Full explanation →

317

MCQeasy

You are deploying a microservices application on Azure Kubernetes Service (AKS). You need to monitor the resource consumption of each pod and set up alerts when CPU usage exceeds 80% for 5 minutes. What should you use?

A.Azure Monitor VM Insights

B.Application Insights

C.Azure Service Health

D.Azure Monitor Container Insights

AnswerD

Azure Monitor Container Insights is the dedicated monitoring solution for Azure Kubernetes Service (AKS) clusters, providing comprehensive performance visibility by collecting metrics from controllers, nodes, and containers. It automatically collects CPU, memory, disk, and network usage data, along with inventory data, from Kubernetes components and workloads. This enables detailed analysis of pod health, resource utilization, and the ability to configure metric alerts directly on container-level performance thresholds, making it ideal for microservices deployed on AKS.

Why this answer

Azure Monitor Container Insights is the correct choice because it is specifically designed to monitor the performance of container workloads running on Azure Kubernetes Service (AKS). It collects memory and processor metrics from controllers, nodes, and containers, and supports setting metric alerts based on CPU usage thresholds, such as 80% for 5 minutes.

Exam trap

The trap here is that candidates often confuse Application Insights (which monitors application code) with Container Insights (which monitors container infrastructure), leading them to select Application Insights for resource consumption alerts.

How to eliminate wrong answers

Option A is wrong because Azure Monitor VM Insights is designed for monitoring virtual machines, not containerized pods in AKS; it cannot collect per-pod CPU metrics. Option B is wrong because Application Insights is an application performance management (APM) service focused on tracing, logging, and application-level telemetry, not infrastructure-level pod resource consumption. Option C is wrong because Azure Service Health provides information about Azure service outages and planned maintenance, not real-time resource monitoring of your deployed pods.

Full explanation →

318

MCQmedium

An Azure Container Instance running a claims processing function requires a password at startup. The password must not be visible in the portal or container logs. What should be used?

A.Plain environment variable

B.Secure environment variable

C.Public blob containing the password

D.Container command-line argument

AnswerB

Secure environment variables in Azure Container Instances (ACI) are designed to protect sensitive values by encrypting them at rest and masking them from standard display in the Azure portal, logs, and `az container show` output. When defined with the `secureValue` property, ACI ensures that the secret is injected into the container at runtime without being persistently exposed in plain text within the container's configuration. This mechanism significantly reduces the risk of accidental or malicious disclosure, making it the recommended approach for handling secrets directly within ACI.

Why this answer

Secure environment variables in Azure Container Instances are encrypted at rest and in transit, and are never exposed in the Azure portal, container logs, or to other users. This ensures the password remains confidential while being available to the container at startup, meeting the requirement of not being visible in the portal or logs.

Exam trap

The trap here is that candidates often confuse 'secure environment variables' with 'plain environment variables' or assume that command-line arguments are not logged, when in fact they are captured in container logs and visible in the portal.

How to eliminate wrong answers

Option A is wrong because plain environment variables are stored in plaintext and are visible in the Azure portal and container logs, violating the security requirement. Option C is wrong because a public blob containing the password would be accessible to anyone with the URL, completely compromising the password's confidentiality. Option D is wrong because container command-line arguments are logged in the container's startup logs and can be viewed in the portal, making them visible and insecure.

Full explanation →

319

MCQmedium

You deploy a containerized application to Azure Container Instances (ACI). The application writes logs that must persist across container restarts and be accessible from a file system. The solution must minimize cost and complexity. Which configuration should you use?

A.Mount an Azure Files share as a volume

B.Store logs in Azure Container Registry

C.Use a Docker volume in the container

D.Pass log path via an environment variable

AnswerA

Mounting an Azure Files share as a volume is the correct approach for persistent storage in Azure Container Instances (ACI). Azure Files provides fully managed SMB file shares that can be easily mounted into an ACI container group, allowing the containerized application to write logs or other persistent data to a network-attached file system. This ensures that data persists beyond the lifecycle of the individual container instance, even if the container restarts or is redeployed, offering a robust and cost-effective solution for stateful applications.

Why this answer

Mounting an Azure Files share as a volume in Azure Container Instances provides persistent, shared file storage that survives container restarts and is accessible via the container's file system. This approach minimizes cost by using standard Azure Files storage (pay only for consumed capacity) and complexity by leveraging ACI's native volume mount support without requiring additional orchestration or stateful infrastructure.

Exam trap

The trap here is that candidates confuse ephemeral Docker volumes (which are lost on restart) with persistent Azure Files shares, or mistakenly think Azure Container Registry can store runtime data like logs.

How to eliminate wrong answers

Option B is wrong because Azure Container Registry is a private registry for storing and managing container images, not a runtime storage location for application logs; logs written to ACR would not be accessible from the container's file system and would not persist across restarts. Option C is wrong because Docker volumes in ACI are ephemeral and tied to the container's lifecycle — they are lost when the container is restarted or recreated, failing the persistence requirement. Option D is wrong because an environment variable only passes configuration data (like a log path string) into the container; it does not provide any actual storage mechanism for log data to persist or be accessed from the file system.

Full explanation →

320

MCQmedium

You need to store large binary files (up to 2 GB) that are frequently overwritten in place (entire file replaced). You want to minimize storage cost and write latency. Which Azure Blob Storage type should you use?

A.Block Blob

B.Page Blob

C.Append Blob

D.Archive Blob

AnswerA

Block blobs are highly optimized for storing large binary files, including those up to 2 GB, by allowing data to be uploaded in manageable blocks. This architecture enables efficient replacement of the entire blob by committing a new block list, which is crucial for scenarios requiring frequent overwrites. Their low latency and cost-effectiveness for whole-file updates make them the ideal choice.

Why this answer

Block blobs are optimized for storing large binary files (up to ~4.75 TB) and support high-throughput uploads via PutBlock and PutBlockList operations. They allow overwriting an entire blob by uploading a new set of blocks, which minimizes write latency compared to page blobs that require sector-aligned writes. Block blobs also offer lower storage cost than page blobs, making them the best choice for frequently overwritten large files.

Exam trap

The trap here is that candidates often confuse 'frequently overwritten' with 'random access' and choose Page Blob, forgetting that page blobs are optimized for small, random writes (like VHDs) and are more expensive, while block blobs are the correct choice for large file replacement with low latency and cost.

How to eliminate wrong answers

Option B (Page Blob) is wrong because page blobs are designed for random read/write access in 512-byte pages (e.g., VHDs for Azure VMs) and have higher storage costs and write latency due to sector alignment requirements, making them suboptimal for large file overwrites. Option C (Append Blob) is wrong because append blobs only support appending data to the end of the blob and do not allow overwriting existing content in place. Option D (Archive Blob) is wrong because archive blobs are for cold data with infrequent access, have high read latency (hours to rehydrate), and are not designed for frequent overwrites.

Full explanation →

321

MCQeasy

You are monitoring an Azure web application with Application Insights. You want to create a custom dashboard that shows the number of requests over time and the average server response time. Which Application Insights feature should you use to create this dashboard?

A.Metrics Explorer

B.Log Analytics

C.Application Map

D.Smart Detection

AnswerA

Azure Monitor's Metrics Explorer is the dedicated tool for visualizing time-series metric data collected by Application Insights. It allows users to create customizable charts by selecting specific metrics, applying aggregations like average or sum, and splitting data by dimensions. These interactive charts can then be pinned directly to Azure dashboards, providing a consolidated view of application performance trends.

Why this answer

Metrics Explorer in Application Insights is designed for visualizing pre-aggregated metrics like request count and server response time over time. It allows you to create custom charts and pin them to an Azure dashboard, making it the correct choice for this monitoring requirement.

Exam trap

The trap here is that candidates often confuse Log Analytics (which can also create charts from log queries) with Metrics Explorer, but Metrics Explorer is the correct tool for pre-aggregated, real-time metric visualization without writing KQL queries.

How to eliminate wrong answers

Option B is wrong because Log Analytics is used for querying raw log data with Kusto Query Language (KQL), not for directly creating real-time metric dashboards from pre-aggregated metrics. Option C is wrong because Application Map provides a visual topology of service dependencies and transaction flow, not time-series charts of request counts or response times. Option D is wrong because Smart Detection uses machine learning to automatically detect anomalies and performance issues, but it does not allow you to build custom metric dashboards.

Full explanation →

322

MCQmedium

You are developing an application that writes logs to Azure Blob Storage. Each log entry is small (less than 1 KB) and you need to store millions of entries per day. You want to minimize storage costs and maximize write throughput. Which blob type should you use?

A.Block blobs with a high block size.

B.Append blobs.

C.Page blobs.

D.Block blobs with a low block size.

AnswerB

Append blobs are specifically designed and optimized for append operations, making them ideal for logging scenarios where data is continuously added to the end of a file. Each append operation is atomic, ensuring data integrity even with concurrent writes. This sequential write pattern, without requiring knowledge of the total size or complex block management, provides high throughput and efficiency for log files that grow over time.

Why this answer

Append blobs are optimized for append operations, making them ideal for logging scenarios where each log entry is appended to the blob. They provide high throughput for write-heavy, sequential append workloads and are cost-effective because they use the same block blob pricing but avoid the overhead of managing individual blocks for each small entry.

Exam trap

The trap here is that candidates often choose block blobs with a low block size (Option D) thinking it minimizes waste, but they overlook that append blobs are specifically designed for append-heavy workloads and eliminate the need for manual block management, offering better throughput and simplicity.

How to eliminate wrong answers

Option A is wrong because using a high block size (e.g., 100 MB) for small log entries (<1 KB) wastes storage and reduces write throughput due to the overhead of committing large blocks for tiny data. Option C is wrong because page blobs are designed for random read/write access (e.g., Azure VM disks) and are not optimized for append-only logging; they also incur higher costs due to premium storage pricing. Option D is wrong because while low block size reduces wasted space, block blobs still require each append to be staged as a separate block and then committed, adding latency and complexity compared to the native append operation of append blobs.

Full explanation →

323

MCQmedium

A image resize worker runs in Azure App Service and must call a private API hosted inside a virtual network. Which feature allows outbound access from the app to the VNet?

A.Regional VNet integration

B.Azure CDN custom domain

C.Application Gateway path routing

D.Private Endpoint for the web app only

AnswerA

Regional VNet integration is the correct solution as it enables an Azure App Service to establish outbound connectivity to resources located within a specified Azure Virtual Network. By injecting the App Service's outbound traffic into a delegated subnet within the VNet, it can securely access private endpoints, virtual machines, or other services that are not publicly exposed. This allows the image resize worker to call internal services or storage accounts privately.

Why this answer

Regional VNet integration enables an Azure App Service app to make outbound calls to resources in a virtual network (VNet) over the Microsoft backbone network. It uses a delegated subnet in the VNet to assign the app a network interface in the VNet, allowing it to reach private APIs without exposing them to the public internet.

Exam trap

The trap here is confusing inbound connectivity (Private Endpoint) with outbound connectivity (VNet integration), leading candidates to select Private Endpoint when the question asks for outbound access from the app to the VNet.

How to eliminate wrong answers

Option B is wrong because Azure CDN custom domain is a content delivery feature that caches and serves public endpoints, not a mechanism for outbound VNet access from an app. Option C is wrong because Application Gateway path routing is an inbound load-balancing and routing feature for HTTP traffic, not an outbound connectivity feature from App Service to a VNet. Option D is wrong because a Private Endpoint for the web app only provides inbound access from the VNet to the app, not outbound access from the app to resources in the VNet.

Full explanation →

324

MCQmedium

You are developing a .NET Core application that needs to authenticate users via Microsoft Entra ID and call Microsoft Graph API. You register an app in the Microsoft Entra admin center and configure the necessary permissions. However, when the app tries to acquire a token, it receives an 'interaction_required' error. What is the most likely cause?

A.The client secret is expired or invalid.

B.The scope parameter is incorrectly formatted.

C.The application is requesting admin-restricted permissions without admin consent.

D.The redirect URI does not match the registered redirect URI.

AnswerC

When an application requests permissions that are designated as admin-restricted (e.g., certain high-privilege Microsoft Graph API permissions) and an administrator has not yet granted tenant-wide consent for these permissions, Azure AD will return an `interaction_required` error. This error explicitly signals that an administrator must intervene to review and approve the elevated permissions before the application can successfully acquire a token. User interaction is necessary to resolve the outstanding administrative consent.

Why this answer

The 'interaction_required' error occurs when the application requests permissions that require admin consent, but the user is not an admin or admin consent has not been granted. In Microsoft Entra ID, certain Graph API permissions (e.g., User.Read.All, Mail.Read) are marked as admin-restricted and require an admin to consent via the admin consent endpoint. Without this consent, the token acquisition fails with this specific error.

Exam trap

The trap here is that candidates often confuse 'interaction_required' with authentication failures like invalid credentials or misconfigured URIs, but the error specifically indicates a consent or policy-driven interaction need, not a configuration mismatch.

How to eliminate wrong answers

Option A is wrong because an expired or invalid client secret would result in an 'invalid_client' or 'unauthorized_client' error, not 'interaction_required'. Option B is wrong because an incorrectly formatted scope parameter would cause a 'invalid_scope' error, not 'interaction_required'. Option D is wrong because a mismatched redirect URI would cause a 'invalid_redirect_uri' error during the authorization code flow, not during token acquisition with an existing authorization code.

Full explanation →

325

MCQmedium

A report export service hosted on App Service returns intermittent 502 errors during deployment. The team wants zero-downtime release with validation before traffic moves. What should be implemented?

A.Deploy to a staging slot, validate health, then swap

B.Deploy directly to production during business hours

C.Restart the App Service plan before each deployment

D.Disable health checks

AnswerA

A staging slot runs the new build on separate instances while production keeps serving. Health checks validate the warmed-up slot, then a swap redirects traffic atomically, eliminating the 502s caused by recycling instances during in-place deployment.

Why this answer

Deploying to a staging slot and then swapping with production ensures zero-downtime because the swap operation warms up the target slot (staging) before routing traffic to it. The health check validation before swap confirms the new release is stable, preventing 502 errors from reaching users. This approach leverages Azure App Service deployment slots, which support traffic routing and warm-up during swap.

Exam trap

The trap here is that candidates may think restarting the plan or disabling health checks is a valid fix, but these actions cause downtime or remove safety nets, whereas deployment slots with health checks provide the required zero-downtime release and validation.

How to eliminate wrong answers

Option B is wrong because deploying directly to production during business hours risks exposing users to a faulty release, causing 502 errors and downtime without any validation or rollback safety. Option C is wrong because restarting the App Service plan before each deployment does not prevent 502 errors; it causes all instances to restart simultaneously, leading to downtime and potential request failures. Option D is wrong because disabling health checks removes the mechanism that detects unhealthy instances, allowing faulty deployments to serve traffic and worsen 502 errors.

Full explanation →

326

MCQhard

You are deploying a microservice to Azure Container Apps. The service requires a custom domain and SSL/TLS certificate. Which resource should you configure to meet these requirements?

A.Azure Front Door with a custom domain

B.Azure Container Apps environment with a custom domain and certificate attached

C.Azure API Management in front of the Container App

D.Azure Application Gateway with SSL termination

AnswerB

Azure Container Apps natively supports binding custom domains directly to a container app's ingress, providing a streamlined and cost-effective solution. This feature includes integrated certificate management, allowing users to either upload their own TLS/SSL certificates or leverage free, automatically renewed managed certificates provided by Azure. This direct approach simplifies the configuration of secure HTTPS endpoints without requiring additional, external services, making it the most appropriate choice.

Why this answer

Azure Container Apps allows you to attach a custom domain and upload an SSL/TLS certificate directly at the environment level, which is the correct approach for securing a microservice with a custom domain. This configuration ensures that the Container App responds to HTTPS requests on your domain without needing an additional front-end service.

Exam trap

The trap here is that candidates often assume a separate front-end service like Azure Front Door or Application Gateway is required for custom domains and SSL, when in fact Azure Container Apps environments natively support this at the ingress level, making those additional services redundant for this specific requirement.

How to eliminate wrong answers

Option A is wrong because Azure Front Door is a global load balancer and CDN, not a required component for attaching a custom domain and certificate directly to a Container App; it adds unnecessary complexity and cost. Option C is wrong because Azure API Management is an API gateway for managing APIs, not a service for attaching custom domains and certificates to the underlying Container App; it would only proxy requests, not satisfy the requirement at the app level. Option D is wrong because Azure Application Gateway is a regional web traffic load balancer with SSL termination, but it is not the native way to attach a custom domain and certificate to a Container App; the Container App environment itself supports this directly.

Full explanation →

327

MCQeasy

You have an Azure Cosmos DB container with a high number of physical partitions. You observe that some partitions are hitting the request unit (RU) limit while others are underutilized. What should you do to better distribute the workload?

A.Add more composite indexes

B.Increase the total provisioned throughput

C.Choose a different partition key that evenly distributes workload

D.Change the default consistency level to eventual

AnswerC

Selecting a different partition key that ensures an even distribution of data and request volume across logical partitions is the most effective solution for addressing uneven workload. A good partition key choice, such as one with high cardinality and even access patterns, prevents "hot partitions" where a disproportionate amount of requests or data are directed to a single logical partition. This allows Cosmos DB to scale throughput horizontally and efficiently, ensuring that the provisioned RUs are utilized effectively across all physical partitions.

Why this answer

The root cause of uneven RU consumption is a poorly chosen partition key that creates a hot partition. By selecting a partition key with high cardinality and even distribution, you ensure that requests and storage are spread uniformly across all physical partitions, preventing any single partition from throttling while others remain idle.

Exam trap

The trap here is that candidates often confuse throughput scaling (increasing RU/s) with workload distribution, mistakenly believing that adding more RU/s will fix a hot partition, when in fact the partition's individual RU ceiling remains unchanged.

How to eliminate wrong answers

Option A is wrong because composite indexes improve query performance and reduce RU cost per query, but they do not redistribute workload across partitions. Option B is wrong because increasing total provisioned throughput raises the RU limit for all partitions equally, which does not solve the imbalance—the hot partition will still hit its individual RU ceiling while others remain underutilized. Option D is wrong because changing the default consistency level to eventual reduces RU consumption for read operations but does not affect how data or requests are distributed across partitions.

Full explanation →

328

Multi-Selecthard

Your Azure Container Apps solution uses Dapr for microservices communication. Which THREE Dapr building blocks are essential for service-to-service invocation and state management?

Select 3 answers

A.Service Invocation

B.Bindings

C.Pub/Sub

D.Actors

E.State Management

AnswersA, C, E

Dapr's Service Invocation building block provides a consistent and secure way for microservices to communicate with each other directly. It abstracts away complexities like service discovery, mTLS encryption, and retries, enabling reliable synchronous calls between services regardless of their underlying protocol or location. This makes it a fundamental component for direct, internal service-to-service communication within a distributed application.

Why this answer

Service Invocation (A) is correct because Dapr's service invocation building block enables direct, secure service-to-service communication using gRPC or HTTP, with built-in mTLS, retries, and observability. State Management (E) is correct because it provides a key-value store abstraction for managing state across microservices, supporting pluggable state stores like Redis, Cosmos DB, or SQL Server. Pub/Sub (C) is correct because it enables asynchronous event-driven communication between services, decoupling producers and consumers via message brokers like Kafka, RabbitMQ, or Azure Service Bus.

Exam trap

The trap here is that candidates often confuse Bindings with service invocation (both involve external communication) or assume Actors are required for state management, but Dapr separates these concerns into distinct building blocks with specific use cases.

Full explanation →

329

MCQhard

You have a web application that writes user-uploaded images to Azure Blob Storage. The application uses a shared access signature (SAS) token with read and write permissions. Users report that sometimes they receive 'AuthorizationFailure' errors when uploading images, but the issue is intermittent. What is the most likely cause?

A.The blob container has a soft-delete policy that is preventing uploads

B.The storage account firewall is blocking requests from the web application's IP

C.The SAS token has expired and the application is not regenerating it before it expires

D.The SAS token was generated with an incorrect IP range restriction

AnswerC

Shared Access Signatures (SAS) are time-limited credentials that grant delegated access to Azure Storage resources. When a SAS token expires, any subsequent requests attempting to use that token will be unauthorized and fail. If the application does not proactively regenerate a new SAS token before the current one's expiration, operations will intermittently succeed until expiration, then consistently fail until a valid token is obtained, perfectly aligning with intermittent failure symptoms.

Why this answer

SAS tokens have a defined expiration time. If the application does not regenerate the token before it expires, uploads will intermittently fail with 'AuthorizationFailure' errors. The intermittent nature is explained by the token being valid for some requests and expired for others, depending on when the token was last refreshed.

Exam trap

The trap here is that candidates may confuse intermittent failures with network or firewall issues, but the key clue is 'intermittent' — which points to a time-based expiry rather than a static configuration problem like IP restrictions or soft-delete policies.

How to eliminate wrong answers

Option A is wrong because soft-delete policies do not prevent uploads; they only mark blobs as deleted after a delete operation, and uploads are unaffected. Option B is wrong because a storage account firewall blocking the web application's IP would cause persistent, not intermittent, failures for all requests from that IP. Option D is wrong because an incorrect IP range restriction would cause consistent authorization failures for all requests from outside the allowed range, not intermittent ones.

Full explanation →

330

MCQhard

A company uses Azure API Management (APIM) to expose APIs to external partners. They want to validate JSON Web Tokens (JWTs) from partners' Microsoft Entra ID tenants before requests reach the backend. The solution must support multiple partner tenants and minimize latency. What should you implement?

A.Use Azure AD B2C as a token broker between partners and the API.

B.Configure OAuth 2.0 authorization server in APIM for each partner tenant.

C.Use client certificate authentication in APIM to map certificates to partner tenants.

D.Use APIM inbound policy with validate-jwt and specify openid-config URL for each partner tenant.

AnswerD

The `validate-jwt` inbound policy in Azure API Management is specifically designed to verify JSON Web Tokens (JWTs) by checking their signature, claims, and expiration. By specifying the `openid-config` URL (also known as the OpenID Connect discovery endpoint) for each partner tenant, APIM can dynamically retrieve the necessary public keys and issuer metadata to validate tokens issued by those respective external identity providers. This method efficiently supports multiple distinct JWT issuers, ensuring robust and scalable authentication for partner integrations.

Why this answer

The `validate-jwt` policy in APIM can be configured with an `openid-config` URL for each partner tenant, allowing APIM to fetch the tenant-specific signing keys and validate JWTs issued by any Microsoft Entra ID tenant. This approach supports multiple tenants without adding a broker or per-tenant authorization servers, and it minimizes latency by performing validation at the APIM gateway before requests reach the backend.

Exam trap

The trap here is that candidates often confuse the `validate-jwt` policy with the need to configure an OAuth 2.0 authorization server in APIM, but APIM's authorization server is for the API's own token issuance, not for validating tokens from external tenants.

How to eliminate wrong answers

Option A is wrong because Azure AD B2C is designed for customer identity and access management, not as a token broker between partner tenants and an API; it would introduce unnecessary complexity and latency. Option B is wrong because configuring an OAuth 2.0 authorization server in APIM for each partner tenant is not supported—APIM's built-in authorization server is for a single identity provider, not for dynamically handling multiple external tenant configurations. Option C is wrong because client certificate authentication validates the client's identity via a certificate, not the JWT token itself; it cannot validate claims or signatures from Microsoft Entra ID tokens, and mapping certificates to tenants adds management overhead without addressing JWT validation.

Full explanation →

331

MCQmedium

Your company develops a microservices-based application deployed on Azure Kubernetes Service (AKS). One of the microservices is a web API that processes user uploads and stores them in Azure Blob Storage. The API is stateless and scales horizontally. You need to implement authentication and authorization for the API using Microsoft Entra ID. The API should validate tokens issued by Entra ID and allow only users with the 'Files.Upload' scope. You need to configure the API's code and AKS deployment accordingly. Which approach should you use?

A.Use Azure AD pod identity in AKS to assign a managed identity to the pod, and implement token validation in the API code using the Microsoft.Identity.Web library.

B.Store the storage account access keys in the API configuration and validate requests using shared access signatures.

C.Configure the API to use client certificate authentication instead of tokens.

D.Expose the API through Azure API Management (APIM) and configure APIM to validate tokens and check scope.

AnswerA

Azure AD pod identity in AKS securely assigns a managed identity to a Kubernetes pod, eliminating the need for hardcoded credentials when the microservice needs to access other Azure resources. For incoming API requests, the Microsoft.Identity.Web library provides a robust framework within the API code to validate JSON Web Tokens (JWTs), ensuring their authenticity, integrity, and crucially, checking the 'scope' claims to enforce fine-grained authorization based on the caller's permissions. This approach aligns with modern secure development practices by leveraging managed identities and explicit token-based authorization.

Why this answer

Azure AD pod identity allows you to assign a managed identity to the pod, which the API can use to authenticate with Microsoft Entra ID. The Microsoft.Identity.Web library simplifies token validation and scope checking in ASP.NET Core applications, enabling the API to validate tokens issued by Entra ID and enforce the 'Files.Upload' scope. This approach aligns with the stateless, horizontally scalable nature of the microservice and avoids managing secrets.

Exam trap

The trap here is that candidates may think Azure API Management (APIM) is required for token validation in AKS, but the question explicitly asks for configuring the API's code and AKS deployment, making the pod identity and library approach the correct in-code solution without an extra gateway.

How to eliminate wrong answers

Option B is wrong because storage account access keys are shared secrets that do not provide user-level authentication or authorization; they grant full access to the storage account, not per-user scope validation. Option C is wrong because client certificate authentication does not involve tokens issued by Microsoft Entra ID and cannot validate the 'Files.Upload' scope; it is a different authentication mechanism. Option D is wrong because while APIM can validate tokens and check scopes, the question specifies configuring the API's code and AKS deployment, not introducing an additional APIM layer; APIM would add latency and complexity not required by the scenario.

Full explanation →

332

MCQeasy

You need to authenticate an Azure Function to an Azure SQL Database using a managed identity. The function has a system-assigned managed identity enabled. Which connection string setting should you use in the function's application settings?

A.Server=tcp:myserver.database.windows.net;Database=mydb;Authentication=Active Directory Password;

B.Server=tcp:myserver.database.windows.net;Database=mydb;Authentication=Active Directory Managed Identity;

C.Server=tcp:myserver.database.windows.net;Database=mydb;User Id=myuser;Password=mypassword;

D.Server=tcp:myserver.database.windows.net;Database=mydb;Authentication=Active Directory Managed Identity;User Id=<client-id>;

AnswerB

This is the correct and recommended connection string for an Azure Function to authenticate to Azure SQL Database using a Managed Identity. By setting `Authentication=Active Directory Managed Identity`, the Azure Function leverages its assigned identity (system-assigned or user-assigned) to securely obtain an Azure AD access token. This token is then used to establish a trusted connection to the SQL database without embedding any sensitive credentials directly in the connection string.

Why this answer

The connection string `Authentication=Active Directory Managed Identity` tells the SQL client to use the system-assigned managed identity of the Azure Function to acquire an access token from Azure AD, without needing any explicit credentials. This is the standard way to authenticate an Azure resource with a managed identity to Azure SQL Database.

Exam trap

The trap here is that candidates often think they need to specify a User Id (like the managed identity's client ID) even for system-assigned identities, but the correct connection string for a system-assigned identity omits the User Id parameter entirely.

How to eliminate wrong answers

Option A is wrong because `Authentication=Active Directory Password` requires a username and password to be provided, which defeats the purpose of using a managed identity and introduces credential management overhead. Option C is wrong because it uses SQL authentication with a hardcoded username and password, which is insecure and not compatible with managed identity. Option D is wrong because while it specifies `Active Directory Managed Identity`, it also includes `User Id=<client-id>`, which is unnecessary for a system-assigned managed identity (the identity is automatically determined) and can cause confusion or errors; the correct syntax omits the User Id parameter.

Full explanation →

333

MCQmedium

A table stores session records in Azure Table Storage. Queries frequently retrieve all records for one customer in a time range. What key design is best?

A.RowKey as a constant value

B.PartitionKey as a random GUID for every record

C.PartitionKey as customer ID and RowKey based on sortable timestamp

D.PartitionKey as the full JSON payload

AnswerC

Setting the PartitionKey as the customer ID and the RowKey based on a sortable timestamp is the optimal design for session records in Azure Table Storage. This structure ensures that all session data for a particular customer is co-located within a single partition, enabling highly efficient point queries or range queries for that customer. The sortable timestamp as the RowKey further allows for rapid retrieval of sessions within a specific time range or in chronological order, leveraging Azure Table Storage's inherent indexing capabilities for fast and cost-effective data access.

Why this answer

Azure Table Storage queries are most efficient when they target a single partition key. Using the customer ID as the PartitionKey ensures all records for a customer are in the same partition, and using a sortable timestamp (e.g., inverted ticks) as the RowKey allows efficient range queries within that partition, leveraging the table's natural index order.

Exam trap

The trap here is that candidates may think randomizing the PartitionKey improves load balancing, but for query-heavy workloads targeting a single entity group, a fixed PartitionKey is essential for performance, and Azure Table Storage handles hot partitions through other mechanisms like entity-level throttling.

How to eliminate wrong answers

Option A is wrong because using a constant RowKey value would cause all records to share the same RowKey, violating the uniqueness requirement and preventing efficient range queries. Option B is wrong because using a random GUID as the PartitionKey scatters each record across different partitions, forcing full table scans for customer-specific queries and eliminating the benefit of partition-level querying. Option D is wrong because storing the full JSON payload as the PartitionKey is not a valid key design; PartitionKey must be a string that identifies the partition, and a large payload would be inefficient and break the key's purpose of grouping related entities.

Full explanation →

334

MCQeasy

You need to deploy an Azure App Service web app that uses a custom domain (www.contoso.com) and SSL/TLS certificate. The certificate is stored in Azure Key Vault. What should you use to bind the certificate to the App Service?

A.Configure Azure Front Door to terminate SSL and forward traffic to App Service.

B.Use an App Service Managed Certificate for the custom domain.

C.Import the certificate from Key Vault into App Service using the 'Key Vault Certificate' option.

D.Export the certificate from Key Vault as a PFX file and upload it to App Service.

AnswerC

Azure App Service offers a direct and secure integration feature to import certificates from Azure Key Vault. This 'Key Vault Certificate' option securely retrieves the certificate, including its private key, from Key Vault, allowing it to be bound to a custom domain within the App Service without manual export or upload. This method also supports automatic renewal if the certificate is renewed in Key Vault.

Why this answer

Azure App Service supports direct integration with Azure Key Vault to import a certificate using the 'Key Vault Certificate' option. This allows you to bind an SSL/TLS certificate stored in Key Vault to your custom domain without manually exporting or managing the PFX file, ensuring secure and seamless certificate lifecycle management.

Exam trap

The trap here is that candidates may confuse the manual PFX export and upload method (Option D) as the only way to use a Key Vault certificate, missing the native 'Key Vault Certificate' integration that is more secure and automated.

How to eliminate wrong answers

Option A is wrong because Azure Front Door terminates SSL at the edge and forwards traffic to App Service over HTTP or HTTPS, but it does not bind the certificate directly to the App Service custom domain; the certificate must still be bound to the App Service for end-to-end SSL. Option B is wrong because an App Service Managed Certificate is a free, built-in certificate for custom domains, but it cannot be imported from Key Vault; it is automatically provisioned and managed by App Service, not sourced from an external Key Vault. Option D is wrong because while you can export a certificate from Key Vault as a PFX file and upload it to App Service, this is a manual, less secure approach that bypasses the native Key Vault integration; the recommended and more secure method is to use the 'Key Vault Certificate' option to directly reference the certificate without exporting.

Full explanation →

335

MCQhard

You have an Azure Function that processes messages from an Event Hubs event stream. The function is failing with 'Message lock lost' errors. The processing time per event is about 10 minutes. What should you do to resolve the errors?

A.Increase the function's timeout duration

B.Configure the EventProcessorOptions with a longer lease duration

C.Increase the number of partitions in the Event Hub

D.Decrease the batch size to process events faster

AnswerB

The Event Processor Host (EPH) or Event Hubs client library acquires a time-bound lease on an Event Hub partition to process events. If the processing of events from that partition takes longer than the configured lease duration, the lease can expire, allowing another consumer instance in the same consumer group to potentially claim ownership of the partition. By configuring `EventProcessorOptions` with a longer `LeaseDuration`, you extend the period the current processor has exclusive access, preventing the lock from being lost prematurely during extended processing operations.

Why this answer

The 'Message lock lost' error occurs because the default Event Hubs lease duration (30 seconds) is too short for processing that takes 10 minutes per event. By configuring the EventProcessorOptions with a longer lease duration, you ensure the partition lease is not expired while the function is still processing the event, preventing the lease from being stolen by another instance.

Exam trap

The trap here is that candidates often confuse function timeout with Event Hubs lease duration, assuming that extending the function's timeout will fix the lock loss, but the lease is managed independently by the EventProcessorHost and must be configured separately.

How to eliminate wrong answers

Option A is wrong because increasing the function's timeout duration only affects the maximum execution time allowed by the Azure Functions host, but does not address the underlying Event Hubs lease renewal mechanism; the lease still expires after the default 30 seconds. Option C is wrong because increasing the number of partitions does not change the lease duration or processing time per event; it only increases parallelism and throughput, which does not resolve the lock loss for long-running processing. Option D is wrong because decreasing the batch size reduces the number of events processed per batch but does not change the per-event processing time of 10 minutes; the lease will still expire while processing a single event.

Full explanation →

336

Multi-Selecteasy

Your company wants to implement a zero-trust security model for its Azure resources. Which THREE practices should you adopt? (Choose three.)

Select 3 answers

A.Implement just-in-time (JIT) access for administrative roles

B.Require multi-factor authentication (MFA) for all users

C.Place all resources behind a firewall

D.Enable micro-segmentation between application tiers

E.Use a VPN to connect to the corporate network

AnswersA, B, D

Implementing Just-in-Time (JIT) access for administrative roles is a cornerstone of Zero Trust. It ensures that elevated permissions are granted only when explicitly requested, for a strictly limited duration, and for a specific task. This significantly reduces the window of opportunity for attackers to exploit standing administrative privileges, aligning with the principle of least privilege and minimizing the attack surface.

Why this answer

Just-in-time (JIT) access for administrative roles reduces the attack surface by granting elevated permissions only when needed and for a limited time. In Azure, JIT is implemented via Azure AD Privileged Identity Management (PIM), which enforces activation requests, approval workflows, and automatic deactivation. This aligns with the zero-trust principle of 'never trust, always verify' by minimizing standing privileges.

Exam trap

The trap here is that candidates often confuse traditional network security controls (like firewalls and VPNs) with zero-trust principles, mistakenly thinking perimeter defenses are sufficient, while zero-trust requires identity-based, least-privilege access and micro-segmentation regardless of network location.

Full explanation →

337

MCQhard

You are developing a solution that processes large files uploaded to Azure Blob Storage. Each file must be processed by a long-running operation that may take up to 30 minutes. You need to use Azure Functions with a consumption plan. How should you handle the processing?

A.Use a Blob trigger function with a retry policy

B.Increase the function timeout to 30 minutes

C.Use an Event Grid trigger function to process the blob

D.Use Durable Functions with a blob-triggered client function

AnswerD

Durable Functions are purpose-built for orchestrating long-running, stateful workflows that can inherently exceed the standard Azure Functions timeout limits. A blob-triggered client function can initiate a Durable Orchestration, which then manages the execution of multiple activity functions, persisting its state between asynchronous operations. This allows the overall workflow to run for hours or even days by breaking down the large file processing into smaller, manageable, and independently executable steps.

Why this answer

D is correct because Azure Functions on a Consumption Plan have a default timeout of 5 minutes and a maximum of 10 minutes. A blob-triggered client function can start a Durable Functions orchestration, which can run for up to 30 minutes (or longer) by using the orchestration's timeout and retry capabilities, avoiding the Consumption Plan's timeout limit.

Exam trap

The trap here is that candidates assume increasing the function timeout or using a retry policy can solve long-running operations, but they overlook the hard 10-minute limit on Consumption Plan and the need for a stateful orchestration pattern like Durable Functions.

How to eliminate wrong answers

Option A is wrong because a retry policy does not extend the function's execution timeout; it only retries the function on failure, but the function still cannot run longer than the Consumption Plan's maximum timeout (10 minutes). Option B is wrong because the maximum timeout for Azure Functions on a Consumption Plan is 10 minutes (configurable up to 10 minutes), not 30 minutes; increasing the timeout beyond 10 minutes is not supported on Consumption Plan. Option C is wrong because an Event Grid trigger function still runs under the same Consumption Plan timeout constraints (max 10 minutes) and does not inherently support long-running operations beyond that limit.

Full explanation →

338

MCQmedium

You are developing a web application that will be deployed to Azure App Service. The application allows users to upload files, which are stored in Azure Blob Storage. You need to ensure that only authenticated users can upload files and that each user can only see their own files. You plan to use shared access signatures (SAS) for secure access. The application uses Microsoft Entra ID for authentication. You want to generate SAS tokens on the server after the user authenticates. Which approach should you use?

A.After user authentication, have the client generate a SAS token using the storage account key retrieved from a secure endpoint.

B.After user authentication, use the server-side code to generate a user delegation SAS for a specific blob container path that includes the user's identifier. Store the SAS in the user's session and return it to the client. The client then uses the SAS to upload the file directly to Blob Storage.

C.After user authentication, use the server-side code to generate a service SAS for the entire blob container. Return the SAS to the client. The client uploads the file, and the server later moves the file to a user-specific folder.

D.After user authentication, use the server to upload the file to Blob Storage using the storage account key. Then return the URL of the uploaded blob to the client.

AnswerB

This approach is correct because it leverages a User Delegation SAS, which is generated server-side using an Azure AD identity (not the storage account key) and provides fine-grained, time-limited permissions. By scoping the SAS to a specific blob container path incorporating the user's identifier, it ensures each user can only access their designated storage area, upholding data isolation and the principle of least privilege. The client receives only the SAS token, enabling direct and secure uploads to Blob Storage without the server acting as an intermediary or exposing sensitive credentials.

Why this answer

It uses a user delegation SAS, which is signed with the storage account's user delegation key derived from Microsoft Entra ID credentials. This ensures that the SAS token is scoped to the authenticated user's identity and can be restricted to a specific container path (e.g., a folder named after the user's identifier). The server generates the SAS after authentication, stores it in the session, and returns it to the client, allowing direct uploads to Blob Storage without exposing the storage account key.

Exam trap

The trap here is that candidates often confuse a service SAS (which uses the account key and can scope to a container or blob) with a user delegation SAS (which uses Entra ID and supports finer-grained identity-based scoping), leading them to choose Option C because it seems simpler, but they miss the security and isolation requirements.

How to eliminate wrong answers

Option A is wrong because having the client generate a SAS token using the storage account key retrieved from a secure endpoint still exposes the storage account key to the client-side code, which violates security best practices and could lead to key compromise. Option C is wrong because a service SAS for the entire container does not restrict access to a user-specific path; the server would need to move files after upload, which introduces unnecessary complexity and a race condition where users could access each other's files before the move. Option D is wrong because uploading via the server using the storage account key bypasses the need for a SAS token entirely, but it forces all traffic through the server, which defeats the purpose of using SAS for direct client-to-storage uploads and increases server load and latency.

Full explanation →

339

MCQhard

You are designing an ASP.NET Core web API that authenticates users via Microsoft Entra ID. The application needs to authorize access to resources based on custom roles (e.g., 'Admin', 'Editor') that are not defined in Microsoft Entra ID app roles or groups. The role mappings are dynamic and stored in an application database. How should you implement authorization in the API?

A.Define the roles as Microsoft Entra ID app roles and assign them to users. This is the standard way to handle roles.

B.Use the OnTokenValidated event in OpenID Connect middleware to query the database and add custom role claims to the identity.

C.Store the roles in the Microsoft Entra ID token by customizing the token issuance in Microsoft Entra ID.

D.Use the [Authorize] attribute with a custom authorization filter that checks the database on every request without modifying the claims.

AnswerB

The OnTokenValidated event in the OpenID Connect middleware is the correct extension point for this scenario. This event fires after the identity token has been successfully validated but before the ClaimsPrincipal is fully constructed and attached to the HttpContext. Within this event, the application can query its internal database using the authenticated user's identifier, retrieve their dynamic roles, and then add these roles as custom claims to the user's ClaimsIdentity. This approach seamlessly integrates dynamic roles into the standard claims-based authorization model.

Why this answer

It uses the OnTokenValidated event in OpenID Connect middleware to enrich the user's identity with custom role claims from the application database after token validation. This approach allows dynamic role mappings stored externally to be injected into the ClaimsPrincipal, which can then be evaluated by the standard [Authorize] attribute with role policies. It avoids modifying Entra ID configuration and keeps role management flexible within the application.

Exam trap

The trap here is that candidates often assume Entra ID app roles or groups are the only way to implement role-based authorization, overlooking the flexibility of the OnTokenValidated event to inject custom claims from external sources.

How to eliminate wrong answers

Option A is wrong because defining roles as Entra ID app roles requires static assignment in the directory, which contradicts the requirement for dynamic role mappings stored in an application database. Option C is wrong because customizing token issuance in Entra ID is not feasible for dynamic, database-driven roles; Entra ID tokens are issued based on directory configuration, not external databases. Option D is wrong because using a custom authorization filter that checks the database on every request without modifying claims is inefficient and bypasses the standard claims-based authorization pipeline, leading to poor performance and complexity.

Full explanation →

340

MCQmedium

You are developing a microservices application on Azure Kubernetes Service (AKS). One of the services needs to securely access Azure SQL Database without storing connection strings in the application code. You need to use managed identities. What should you do?

A.Store the connection string in Azure Key Vault and use the Key Vault FlexVolume driver.

B.Use the AKS cluster's managed identity to access Azure SQL.

C.Create a service principal and use its credentials in the pod.

D.Enable Azure AD Pod Identity and assign a managed identity to the pod.

AnswerD

Enabling Azure AD Pod Identity (or its successor, Azure AD Workload Identity) allows individual pods within an AKS cluster to acquire and use an Azure Active Directory managed identity. By assigning a specific managed identity to a pod, that pod can then authenticate directly with Azure SQL Database using its identity, completely eliminating the need for connection strings, usernames, or passwords in the application code or configuration files. This method provides secure, credential-less authentication, aligning with best practices for microservices security.

Why this answer

Azure AD Pod Identity allows you to assign an Azure Active Directory (Azure AD) managed identity directly to a pod in AKS. The pod can then use that identity to authenticate to Azure SQL Database without storing any connection strings or secrets in the code. This is the recommended approach for pod-level managed identity access to Azure resources.

Exam trap

The trap here is that candidates often confuse the AKS cluster's managed identity (which is for cluster-level operations like load balancers) with pod-level managed identities, leading them to incorrectly select Option B.

How to eliminate wrong answers

Option A is wrong because storing the connection string in Key Vault and using the FlexVolume driver still requires the pod to retrieve a secret, which does not eliminate the need for a connection string; it only moves it to a vault. Option B is wrong because the AKS cluster's managed identity is a system-assigned identity for the cluster itself, not for individual pods, and it cannot be used directly by a pod to access Azure SQL. Option C is wrong because creating a service principal and using its credentials in the pod would require storing the service principal's secret (password or certificate) in the pod, which defeats the purpose of avoiding stored credentials.

Full explanation →

341

MCQmedium

You are developing a web app that authenticates users via Microsoft Entra ID. The app needs to read the user's profile and send emails on their behalf. You want to minimize user consent prompts. Which OAuth 2.0 grant type should you use?

A.Authorization code flow with PKCE

B.Client credentials flow

C.Resource owner password credentials

D.Implicit flow

AnswerA

This is the recommended and most secure OAuth 2.0 flow for web applications authenticating users. It involves redirecting the user's browser to the identity provider for authentication, then receiving an authorization code back at a registered redirect URI. This code is then securely exchanged for access and refresh tokens from the backend, preventing tokens from being exposed in the browser's URL. PKCE (Proof Key for Code Exchange) further enhances security by mitigating authorization code interception attacks, particularly important for public clients but also a strong best practice for confidential web apps.

Why this answer

The authorization code flow with PKCE (Proof Key for Code Exchange) is the recommended OAuth 2.0 grant type for public clients (like a web app) that need delegated user authentication and consent. It allows the app to obtain an access token to read the user's profile and a refresh token to send emails on their behalf, while minimizing consent prompts by using a single consent request for both permissions. PKCE adds a cryptographic challenge to prevent authorization code interception attacks, making it secure for web apps without a client secret.

Exam trap

The trap here is that candidates often choose the client credentials flow (B) thinking it minimizes prompts because it doesn't involve user interaction, but they overlook that the app needs to act on behalf of a specific user, which requires delegated permissions and user consent, not application permissions.

How to eliminate wrong answers

Option B is wrong because the client credentials flow is designed for server-to-server (daemon) scenarios where no user is present; it cannot act on behalf of a specific user to read their profile or send emails as them. Option C is wrong because the resource owner password credentials flow requires the user to provide their username and password directly to the app, which is insecure and not recommended for modern apps; it also does not minimize consent prompts as it bypasses the consent UI entirely. Option D is wrong because the implicit flow is deprecated in OAuth 2.0 Security Best Current Practice (BCP) due to security risks like access token leakage in the browser; it also cannot issue refresh tokens, so the app would need repeated consent prompts for long-lived access.

Full explanation →

342

MCQmedium

You are deploying a container group to Azure Container Instances that runs a stateful application. The application writes data to the /data directory. You need to ensure that the data is preserved if the container restarts. Which volume mount type should you use?

A.EmptyDir

B.Azure Files share

C.Secret

D.ConfigMap

AnswerB

An Azure Files share provides a fully managed, cloud-based file share that can be mounted as a volume into an Azure Container Instance. This solution offers durable and persistent storage, meaning data written to the share remains intact even if the container instance stops, restarts, or is deleted. Its independence from the container's lifecycle makes it the ideal choice for stateful applications requiring reliable data persistence in ACI.

Why this answer

Azure Files shares provide persistent, shared storage that can be mounted into Azure Container Instances (ACI) using the SMB 3.0 protocol. This ensures that data written to the /data directory survives container restarts because the share exists independently of the container lifecycle. EmptyDir volumes are ephemeral and tied to the pod's lifetime, making them unsuitable for stateful applications that require data persistence across restarts.

Exam trap

The trap here is that candidates often confuse EmptyDir with persistent storage, assuming it survives restarts because it is used in Kubernetes pods, but in ACI, EmptyDir is ephemeral and tied to the container group's lifecycle, not the container's restart policy.

How to eliminate wrong answers

Option A is wrong because EmptyDir volumes are created empty when a container starts and are deleted when the container is removed or restarted, so they do not preserve data across restarts. Option C is wrong because Secret volumes are used to inject sensitive data (e.g., passwords, certificates) as read-only files, not for persistent application data storage. Option D is wrong because ConfigMap volumes are designed to inject non-sensitive configuration data (e.g., key-value pairs) as read-only files, and they do not support write operations or persistence across restarts.

Full explanation →

343

MCQmedium

A web app for a webhook processor needs separate staging and production environments. The team must warm up the new version before swapping traffic. Which App Service feature should be used?

A.Deployment slots

B.Backup and restore

C.App Service access restrictions

D.Always On only

AnswerA

Deployment slots provide separate staging and production environments with distinct hostnames, and slot swap warms up the new version on the staging slot before routing production traffic to it, satisfying the warm-up requirement without downtime.

Why this answer

Deployment slots are the correct feature because they enable separate staging and production environments within the same App Service plan, allowing you to warm up the new version in a staging slot before performing a zero-downtime swap with the production slot. This directly supports the requirement for traffic swapping after warm-up, which is a core capability of slot-swapping in Azure App Service.

Exam trap

The trap here is that candidates may confuse Always On with a warm-up mechanism, but Always On only prevents idle unload and does not provide environment separation or traffic swapping capabilities.

How to eliminate wrong answers

Option B is wrong because Backup and restore is a disaster recovery feature that creates snapshots of app content and configuration, not a mechanism for staging or traffic swapping. Option C is wrong because App Service access restrictions control inbound network access via IP rules or service endpoints, not environment separation or traffic routing. Option D is wrong because Always On only prevents the app from being unloaded after idle time, ensuring it stays warm but does not provide separate environments or the ability to swap traffic between versions.

Full explanation →

344

MCQhard

Refer to the exhibit. An Azure Function is configured with an Event Hub trigger to process telemetry data. The function uses the EventProcessorHost to read events. The developer notices that the function is not processing all events; some events are skipped. What is the most likely cause?

A.The event hub name is misspelled

B.The cardinality is set to 'many' causing batch processing issues

C.The consumer group is set to $Default

D.The connection string is stored as a securestring parameter

AnswerB

When an Event Hub trigger's 'cardinality' is set to 'many', the Azure Function expects to receive a batch of events, typically as 'EventData[]' or 'List<EventData>'. If the function's code is designed to process individual events (i.e., expecting a single 'EventData' parameter) or if the batch processing logic is inefficient, it can lead to significant issues. Large batches might cause the function to exceed its execution timeout, or checkpointing might not occur correctly, resulting in events being reprocessed or, worse, skipped entirely if the lease is lost before successful processing.

Why this answer

Setting the cardinality to 'many' in an Event Hub-triggered Azure Function causes the function to process events in batches. If the batch size is not properly configured or if the function fails to checkpoint after processing a batch, some events may be skipped when the host rebalances or restarts. The EventProcessorHost relies on checkpointing to track progress, and batch processing without proper checkpoint handling can lead to event loss.

Exam trap

The trap here is that candidates often assume 'many' cardinality improves throughput without realizing it introduces batch processing complexities that can lead to skipped events if checkpointing is not handled correctly.

How to eliminate wrong answers

Option A is wrong because a misspelled event hub name would cause the function to fail to connect entirely, not skip events intermittently. Option C is wrong because the $Default consumer group is the standard group used by Event Hubs and does not cause event skipping; using a different consumer group is only necessary for multiple readers. Option D is wrong because storing the connection string as a securestring parameter is a security best practice and does not affect event processing or cause events to be skipped.

Full explanation →

345

MCQhard

A Kubernetes-based IoT command API on AKS must pull images from Azure Container Registry without storing registry passwords in Kubernetes secrets. What should be used?

A.Use an App Service deployment slot

B.Store the ACR admin password in every deployment manifest

C.Attach the ACR to AKS or grant the kubelet managed identity AcrPull

D.Make the container registry public

AnswerC

Attaching the Azure Container Registry (ACR) to an Azure Kubernetes Service (AKS) cluster, or explicitly granting the kubelet's managed identity the AcrPull role, is the recommended and most secure method for image authentication. This approach leverages Azure's native identity and access management, allowing the AKS cluster's nodes (via their managed identity) to securely pull images from the private ACR without requiring explicit credentials in Kubernetes manifests. It adheres to the principle of least privilege, providing only the necessary read access.

Why this answer

Attaching an ACR to an AKS cluster or granting the kubelet managed identity the AcrPull role enables Azure AD-based authentication without storing credentials in Kubernetes secrets. The kubelet on each node uses its managed identity to obtain an ACR access token via Azure AD, allowing secure image pulls. This approach eliminates the need for manual password management and follows security best practices for Azure-integrated workloads.

Exam trap

The trap here is that candidates may confuse AKS authentication with App Service features or assume that making the registry public is acceptable for development, when in fact Azure AD managed identity with AcrPull is the secure, recommended approach for production workloads.

How to eliminate wrong answers

Option A is wrong because App Service deployment slots are a feature for staging and swapping web app versions, not for authenticating Kubernetes to a container registry. Option B is wrong because storing the ACR admin password in every deployment manifest violates security best practices by exposing static credentials in plaintext, and the admin account is intended for emergency use only, not routine automation. Option D is wrong because making the container registry public exposes all images to the internet, creating a severe security risk and violating the principle of least privilege.

Full explanation →

346

MCQhard

You are developing a .NET Core application that uses Azure Service Bus queues. You need to implement a dead-lettering mechanism for messages that cannot be processed after 5 delivery attempts. Which property should you set on the queue to automate this?

A.defaultMessageTimeToLive

B.maxDeliveryCount

C.lockDuration

D.requiresDuplicateDetection

AnswerB

maxDeliveryCount is the crucial property that determines the maximum number of times a message can be delivered to a consumer before it is automatically moved to the dead-letter queue. Each time a message is received and then abandoned, or its lock expires without completion, the delivery count increments. Once this count exceeds maxDeliveryCount, the message is considered a "poison message" and is transferred to the dead-letter queue for manual inspection or alternative processing.

Why this answer

The maxDeliveryCount property on an Azure Service Bus queue defines the maximum number of attempts to deliver a message before it is automatically moved to the dead-letter queue. Setting this property to 5 ensures that after five failed delivery attempts, the message is dead-lettered, meeting the requirement without custom code.

Exam trap

The trap here is that candidates often confuse maxDeliveryCount with lockDuration, thinking that extending the lock gives more retries, but lockDuration only affects the time a single receive holds the message, not the total number of delivery attempts.

How to eliminate wrong answers

Option A is wrong because defaultMessageTimeToLive sets the time span after which a message expires and is discarded or dead-lettered, not the number of delivery attempts. Option C is wrong because lockDuration controls how long a message is locked for a single receiver during peek-lock mode, not the retry count. Option D is wrong because requiresDuplicateDetection enables duplicate detection based on the MessageId, unrelated to delivery retries or dead-lettering.

Full explanation →

347

MCQeasy

You need to deploy a microservice that runs a long-running background job (up to 30 minutes). The job should not be affected by App Service recycling. Which Azure technology should you use?

A.Azure Automation Runbook

B.Azure WebJobs with Always On enabled

C.Azure Functions (Consumption plan)

D.Azure Kubernetes Service (AKS)

AnswerB

Azure WebJobs are an integral feature of Azure App Service, allowing you to run scripts or executables as background processes within your web app instance. By enabling "Always On" for the App Service plan, the underlying host process for the WebJob is kept alive indefinitely, preventing the App Service from being unloaded due to inactivity and ensuring the continuous execution of the long-running microservice without interruption. This makes them ideal for persistent background tasks tightly coupled with an App Service.

Why this answer

Azure WebJobs with Always On enabled ensures the WebJob runs continuously on a dedicated App Service instance, preventing it from being unloaded during idle periods or App Service recycling. This allows the long-running background job (up to 30 minutes) to complete without interruption, as the WebJob runs in the same process as the web app and is not subject to the 5-minute timeout of the Consumption plan.

Exam trap

The trap here is that candidates often choose Azure Functions (Consumption plan) because of its simplicity, forgetting that the Consumption plan has a hard 5-minute execution timeout, making it unsuitable for long-running jobs, while WebJobs with Always On is the correct choice for persistent background processing within App Service.

How to eliminate wrong answers

Option A is wrong because Azure Automation Runbooks are designed for short-lived, automated tasks (up to 3 hours) but are not optimized for continuous background jobs within an App Service context; they run in a sandbox that can be recycled and lack the tight integration with App Service recycling behavior. Option C is wrong because Azure Functions on the Consumption plan have a maximum execution timeout of 5 minutes (10 minutes for the Premium plan), which is insufficient for a job that runs up to 30 minutes; the function host can also be recycled during idle periods. Option D is wrong because Azure Kubernetes Service (AKS) is a container orchestration platform that adds unnecessary complexity and cost for a single long-running background job; while it can handle long-running tasks, it is overkill compared to the simpler WebJobs solution, and the question specifically asks for a technology that is not affected by App Service recycling, which AKS does not directly address.

Full explanation →

348

MCQeasy

Your web app hosted on Azure App Service is experiencing high memory usage. You need to capture a memory dump for analysis without restarting the app. Which diagnostic feature should you use?

A.Application Insights Profiler

B.Snapshot Debugger

C.Diagnostic settings

D.Azure App Service Diagnostics (Diagnose and solve problems)

AnswerD

The "Diagnose and solve problems" blade within Azure App Service Diagnostics provides a powerful suite of tools for troubleshooting various application issues, including memory-related problems. It offers proactive diagnostics, intelligent recommendations, and specific tools like "Collect Memory Dump" which allows you to capture a full memory dump of your application process. This capability is specifically designed for deep analysis of memory leaks, high memory consumption, and other memory-related performance issues without requiring an application restart.

Why this answer

Azure App Service Diagnostics (Diagnose and solve problems) provides a built-in 'Memory Dump' tool that allows you to capture a full or mini memory dump of your app's process without requiring a restart. This is accessed through the Azure portal under the 'Diagnose and solve problems' blade, specifically via the 'Collect Memory Dump' diagnostic tool, which uses the Windows Debugging Tools to snapshot the w3wp.exe process while the app continues running.

Exam trap

The trap here is that candidates often confuse the 'Diagnose and solve problems' blade with 'Diagnostic settings' or assume that only Application Insights tools (Profiler or Snapshot Debugger) can capture runtime diagnostic data, but the memory dump feature is a distinct, restart-free tool available directly under the App Service's diagnostic portal.

How to eliminate wrong answers

Option A is wrong because Application Insights Profiler is designed to trace and analyze performance bottlenecks by capturing CPU and request execution timelines, not to capture memory dumps for analyzing memory leaks or high memory usage. Option B is wrong because Snapshot Debugger captures snapshots of application state when exceptions occur, focusing on debugging code logic errors, not on collecting full memory dumps for memory analysis. Option C is wrong because Diagnostic settings are used to stream platform logs and metrics to destinations like Storage Accounts, Event Hubs, or Log Analytics, but they do not provide a mechanism to capture on-demand memory dumps of the running process.

Full explanation →

349

MCQmedium

You are running an Azure App Service web app on the Basic tier. Users report slow initial responses due to cold starts. You need to keep the app warm without upgrading the hosting plan. Which feature should you enable?

A.Enable 'Always On' in the App Service configuration.

B.Upgrade to a Premium plan to get pre-warmed instances.

C.Implement an auto-scaling rule to maintain a minimum instance count.

D.Reduce the web app's idle timeout via application code.

AnswerA

Enabling 'Always On' in the App Service configuration ensures that the web application's worker process is continuously loaded and running, even during periods of inactivity. This prevents the application from being unloaded from memory, thereby eliminating "cold starts" where the first request after an idle period incurs significant latency for the application to initialize. This crucial setting is available starting from the Basic App Service plan tier, directly addressing the problem of initial request delays.

Why this answer

The 'Always On' feature prevents the App Service from being unloaded after periods of inactivity, eliminating cold starts by keeping the application loaded in memory. This is available on the Basic tier and above, so it solves the problem without requiring a plan upgrade.

Exam trap

The trap here is that candidates often confuse auto-scaling (which handles load distribution) with keeping a single instance warm, or incorrectly assume that 'Always On' requires a Premium plan when it is actually available from the Basic tier upward.

How to eliminate wrong answers

Option B is wrong because upgrading to a Premium plan is unnecessary and violates the constraint of not upgrading the hosting plan; 'Always On' is already available on the Basic tier. Option C is wrong because auto-scaling rules maintain a minimum instance count but do not prevent individual instances from being unloaded due to idle timeouts; cold starts still occur on each instance after idle. Option D is wrong because reducing idle timeout via application code does not affect the App Service platform's idle unloading behavior, which is controlled by the 'Always On' setting.

Full explanation →

350

MCQhard

You are designing a solution to send email notifications from an Azure App Service web app. The app must use a third-party email service that requires an API key. You need to minimize management overhead and ensure the key is rotated automatically. What should you do?

A.Use a system-assigned managed identity to authenticate to the email service

B.Store the API key in the App Service application settings

C.Create an Azure Logic App to send emails and call it from the web app

D.Store the API key in Azure Key Vault and use a managed identity to retrieve it

AnswerD

Storing the API key in Azure Key Vault and using a managed identity to retrieve it is the most secure and recommended approach. Azure Key Vault is designed for secure storage of secrets, offering encryption at rest, auditing, and fine-grained access policies. A system-assigned managed identity for the web app can be granted specific permissions to access the secret in Key Vault, eliminating the need to hardcode credentials and enabling secure, automatic rotation of the API key within Key Vault, adhering to the principle of least privilege.

Why this answer

It uses Azure Key Vault to securely store the third-party API key, and a system-assigned managed identity to authenticate the App Service to Key Vault without managing credentials. This minimizes management overhead by eliminating manual key rotation (Key Vault can rotate secrets automatically) and removes the need to store secrets in code or configuration.

Exam trap

The trap here is that candidates confuse managed identity as a universal authentication mechanism for any service, when in fact it only works with Azure AD-integrated services, not third-party APIs that require static API keys.

How to eliminate wrong answers

Option A is wrong because managed identities authenticate to Azure AD-backed services (e.g., Azure Storage, SQL Database), not to third-party email services that require an API key; managed identities cannot directly authenticate to external APIs that don't support Azure AD tokens. Option B is wrong because storing the API key in App Service application settings exposes it in plaintext in the portal and configuration, requires manual rotation, and increases management overhead and security risk. Option C is wrong because creating a Logic App adds unnecessary complexity and management overhead (another resource to maintain, monitor, and secure) without solving the key rotation or secure storage problem; the API key would still need to be stored somewhere securely.

Full explanation →

351

MCQeasy

You are migrating an on-premises application to Azure. The application uses a network file share (NFS) to store files. You need to minimize code changes. Which Azure storage service should you use?

A.Azure Files

B.Azure Disk Storage

C.Azure Blob Storage

D.Azure Queue Storage

AnswerA

Azure Files provides fully managed file shares in the cloud, accessible via industry-standard Server Message Block (SMB) and Network File System (NFS) protocols. This makes it an ideal solution for lift-and-shift migrations of on-premises applications that rely on shared file systems, as it allows existing applications to access files without requiring significant code changes. It supports both Windows and Linux clients, offering a seamless transition for file-dependent workloads to Azure.

Why this answer

Azure Files provides fully managed file shares in the cloud that support the Server Message Block (SMB) protocol and the Network File System (NFS) protocol. Since your on-premises application already uses an NFS share, migrating to Azure Files with NFS support allows you to mount the share directly with minimal code changes, as the application can continue to use the same file system semantics and NFS client calls.

Exam trap

The trap here is that candidates often confuse Azure Files with Azure Blob Storage, assuming both are 'file storage' in the cloud, but Blob Storage is object storage with a flat namespace and REST-based access, not a network file share that supports NFS or SMB protocols without significant code changes.

How to eliminate wrong answers

Option B (Azure Disk Storage) is wrong because it provides block-level storage volumes attached to a single virtual machine, not a network-accessible file share; migrating to disks would require refactoring the application to use a different storage interface and managing the file system yourself. Option C (Azure Blob Storage) is wrong because it is an object storage service accessed via REST APIs or SDKs, not a POSIX-compliant file system; using it would require rewriting the application to use blob APIs instead of NFS file operations. Option D (Azure Queue Storage) is wrong because it is a messaging service for asynchronous communication between application components, not a file storage solution; it cannot store or serve files over NFS.

Full explanation →

352

MCQmedium

Wide World Importers has an Azure API Management (APIM) instance that exposes several APIs. One API is a custom REST API hosted on an Azure App Service. The API requires authentication via a subscription key. APIM is configured to require subscription keys for all APIs. The team wants to offload authentication to APIM so that backend services do not need to validate keys. However, the backend API also needs to know the identity of the calling application for logging. The team decides to use APIM's OAuth 2.0 authorization with Microsoft Entra ID. The backend API should receive the JWT token from APIM. How should the team configure APIM to pass the token to the backend?

A.In the inbound processing policy, add a 'validate-jwt' policy to validate the token. Then add a 'set-header' policy to copy the token from the Authorization header (or from the context) and forward it to the backend.

B.Use the 'ip-filter' policy to restrict access to known IPs. The backend trusts requests from APIM's IP.

C.Remove the subscription key requirement for that API. APIM will not pass any authentication information to the backend.

D.Configure APIM to use client certificate authentication for the backend. The certificate is presented to the backend, which extracts the identity from the certificate.

AnswerA

The 'validate-jwt' policy in APIM's inbound processing is essential for verifying the authenticity and integrity of the incoming JSON Web Token, ensuring its signature, issuer, audience, and expiration are valid. Following successful validation, a 'set-header' policy must be used to explicitly copy the validated token from the Authorization header or context variables and forward it to the backend service. This ensures the backend receives the user's identity and can perform granular authorization based on the token's claims.

Why this answer

APIM can use the 'validate-jwt' policy to verify the OAuth 2.0 token from Microsoft Entra ID, and then a 'set-header' policy to forward the original JWT token (e.g., from the Authorization header or context variable) to the backend. This offloads authentication from the backend while preserving the caller's identity for logging, as the backend receives the token without needing to validate it again.

Exam trap

The trap here is that candidates may think removing the subscription key or using IP filtering is sufficient for authentication offloading, but they miss that the backend specifically needs the JWT token for identity logging, which only the 'validate-jwt' and 'set-header' combination provides.

How to eliminate wrong answers

Option B is wrong because the 'ip-filter' policy only restricts access based on source IP addresses; it does not authenticate the caller or pass any identity token to the backend, so the backend cannot log the calling application's identity. Option C is wrong because removing the subscription key requirement does not enable OAuth 2.0 token forwarding; the backend would receive no authentication information, failing the requirement to know the calling application's identity. Option D is wrong because client certificate authentication uses a certificate for mutual TLS, not OAuth 2.0 JWT tokens; the backend would receive a certificate, not the JWT token containing the application identity, and this does not align with the team's decision to use OAuth 2.0 with Microsoft Entra ID.

Full explanation →

353

Matchingmedium

Match each Azure monitoring tool to its purpose.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Collect, analyze, and act on telemetry data

Application performance monitoring (APM)

Query and analyze log data

Personalized recommendations for best practices

Why these pairings

Azure Monitor is the main service for telemetry collection and analysis. Application Insights focuses on application performance. Log Analytics is the query workspace for logs.

Azure Advisor provides optimization recommendations. The distractors swap these definitions.

Full explanation →

354

MCQhard

You are implementing a Durable Functions orchestration that calls an activity function which may fail transiently. You want to retry the activity up to 3 times with a 5-second delay and exponential backoff. Which code snippet should you use?

A.await context.CallActivityAsync("Activity", input);

B.await context.CallActivityWithRetryAsync("Activity", new RetryOptions(TimeSpan.FromSeconds(5), 3), input);

C.await context.CallActivityAsync("Activity", input, new RetryOptions(TimeSpan.FromSeconds(5), 3));

D.Use a durable timer and a loop to retry manually.

AnswerB

This is the correct and idiomatic approach for implementing built-in retry logic in Durable Functions orchestrations. The `context.CallActivityWithRetryAsync` method automatically handles transient failures by retrying the specified activity function based on the provided `RetryOptions`, which define the `FirstRetryInterval` (5 seconds) and `MaxNumberOfAttempts` (3), ensuring robustness without manual retry loops.

Why this answer

The Durable Functions SDK provides the `CallActivityWithRetryAsync` method, which accepts a `RetryOptions` object to configure retry count and delay. The `RetryOptions` constructor takes `TimeSpan.FromSeconds(5)` as the first retry interval and `3` as the maximum number of attempts, including the initial call. This built-in method handles exponential backoff automatically, eliminating the need for manual retry logic.

Exam trap

The trap here is that candidates may confuse `CallActivityAsync` with `CallActivityWithRetryAsync`, assuming that retry options can be passed as an additional parameter to the former, or they may underestimate the value of the built-in retry mechanism and opt for a manual loop, which is less robust and not idiomatic in Durable Functions.

How to eliminate wrong answers

Option A is wrong because `CallActivityAsync` does not accept retry parameters and will only execute the activity once, failing immediately on transient errors. Option C is wrong because `CallActivityAsync` does not have an overload that accepts `RetryOptions`; the retry mechanism is only available via `CallActivityWithRetryAsync`. Option D is wrong because while a manual loop with a durable timer could technically work, it is not the recommended or idiomatic approach in Durable Functions, and it would require additional code to implement exponential backoff correctly, making it less reliable and more error-prone than the built-in method.

Full explanation →

355

MCQmedium

Refer to the exhibit. You have an Azure Policy definition as shown. Your team creates a storage account with network rules set to 'Deny' by default, and then adds an IP rule to allow traffic from a specific IP range. What compliance state will this storage account be reported as?

A.Error

B.Compliant

C.Exempt

D.Non-compliant

AnswerB

This policy definition utilizes the DenyAction effect, which specifically targets 'write' operations on storage accounts. It does not contain any conditions that evaluate the network rule configurations, such as public network access settings. Therefore, if a storage account already exists or is created without violating the 'write' operation conditions (which are not specified in the prompt but implied to be met), its compliance state will be Compliant because the policy's scope does not encompass network access restrictions. The policy only restricts actions, not the inherent configuration of existing resources outside its defined conditions.

Why this answer

The Azure Policy definition in the exhibit uses the 'DenyAction' effect, which only denies or audits specific actions (such as 'Microsoft.Storage/storageAccounts/write'). It does not evaluate the configuration of network rules on the storage account. Therefore, the storage account's network rule settings (defaultAction 'Deny' and IP rule) have no bearing on compliance with this policy.

The resource is compliant because the policy's condition does not apply to network rules, and the write action was not blocked since the account was created successfully.

Exam trap

The trap here is that candidates assume any policy with 'Deny' in the name will evaluate network rules or resource configuration, but 'DenyAction' only blocks specific operations and does not assess the resource's properties for compliance.

How to eliminate wrong answers

Option A is wrong because 'Error' is not a valid compliance state in Azure Policy; valid states include Compliant, Non-compliant, Exempt, and Conflicting. Option C is wrong because 'Exempt' requires an explicit exemption assignment on the resource or policy, which was not mentioned in the scenario. Option D is wrong because the storage account is not non-compliant; the policy's 'DenyAction' effect only blocks the write operation if attempted, but the account was created successfully, and the policy does not evaluate the network rule configuration.

Full explanation →

356

MCQeasy

You are developing a solution that processes messages from an Azure Storage Queue. Each message triggers a long-running operation that may take up to 30 minutes. You need to ensure that if the processing fails, the message is not lost and can be retried later. The current implementation uses a console application that polls the queue and deletes messages after processing. What should you change?

A.Move the message to a poison queue after the first failure.

B.After processing fails, update the message's visibility timeout to a later time so it becomes visible again for retry.

C.Increase the polling interval to reduce the chance of missing messages.

D.Delete the message only if processing succeeds; otherwise, leave it in the queue.

AnswerB

When message processing fails due to a transient issue, updating the message's visibility timeout using the `UpdateMessage` operation is the recommended pattern. This action makes the message invisible for a specified duration, preventing other consumers from attempting to process it immediately. After the timeout expires, the message becomes visible again, allowing for a delayed retry attempt, which is crucial for resolving transient errors without losing the message.

Why this answer

The correct approach is to update the message's visibility timeout to a later time when processing fails. This makes the message reappear in the queue after the specified timeout, allowing another consumer to retry processing. Azure Storage Queue messages have a default visibility timeout of 30 seconds, but you can extend it to up to 7 days.

This ensures the message is not lost and can be retried without being deleted or moved prematurely.

Exam trap

The trap here is that candidates often think leaving the message in the queue (Option D) is sufficient, but they forget that the message remains invisible after being dequeued unless its visibility timeout is explicitly updated to make it visible again for retries.

How to eliminate wrong answers

Option A is wrong because moving a message to a poison queue after the first failure would prevent retries; poison queues are typically used after a maximum number of retries (e.g., 5) have been exhausted, not after a single failure. Option C is wrong because increasing the polling interval does not address the need to retry failed messages; it only reduces how often the queue is checked, which could delay processing but does not handle failure recovery. Option D is wrong because simply leaving the message in the queue without updating its visibility timeout means it will remain invisible (due to the default visibility timeout) and never be reprocessed; the message must be made visible again for retries.

Full explanation →

357

MCQeasy

You need to monitor the real-time CPU utilization of an Azure virtual machine. Which Azure Monitor feature is designed for this purpose?

A.Metrics

B.Logs

C.Alerts

D.Workbooks

AnswerA

Metrics capture numeric time-series data at near-real-time granularity, making them the Azure Monitor feature for tracking CPU percentage continuously. Logs and alerts operate on different axes: logs need ingestion and query latency, while alerts react to thresholds rather than stream the utilisation values themselves.

Why this answer

Azure Monitor Metrics is the correct feature because it collects and stores numeric time-series data from Azure resources, including CPU utilization, at near-real-time intervals (typically every 1 minute for Azure VMs). Metrics are lightweight, low-latency, and designed for real-time monitoring and alerting, making them ideal for tracking CPU usage without the overhead of log ingestion.

Exam trap

The trap here is that candidates often confuse 'real-time monitoring' with 'log-based analysis' and select Logs (Option B), not realizing that Metrics are specifically designed for low-latency, numeric performance data like CPU utilization, while Logs are for text-based events with higher latency.

How to eliminate wrong answers

Option B (Logs) is wrong because Azure Monitor Logs collects and stores textual, event-based data (e.g., system logs, application traces) with higher latency and is not optimized for real-time numeric performance counters like CPU utilization; it requires Log Analytics queries and is better suited for troubleshooting and historical analysis. Option C (Alerts) is wrong because Alerts are a notification mechanism that can be triggered by metric thresholds or log queries, but they are not a data collection or visualization feature themselves—they depend on Metrics or Logs as data sources. Option D (Workbooks) is wrong because Workbooks are interactive dashboards that combine data from multiple sources (Metrics, Logs, etc.) for visualization and reporting, but they do not natively collect or provide real-time CPU utilization data on their own.

Full explanation →

358

MCQeasy

You need to deploy a containerized application to Azure that must be restarted automatically if it crashes. The solution should minimize management overhead. Which compute service should you use?

A.Azure Container Instances

B.Azure Functions

C.Azure Kubernetes Service (AKS)

D.Azure Virtual Machines

AnswerA

Azure Container Instances (ACI) offers the fastest and simplest way to run a single container or a small group of containers in Azure without managing any underlying infrastructure. It is a serverless solution that allows for immediate deployment and billing by the second, making it ideal for scenarios requiring quick starts, burst workloads, or simple containerized applications that don't need full orchestration capabilities. Its restart policy ensures the container can be configured to run once, always, or on failure, perfectly suiting a straightforward container deployment need.

Why this answer

Azure Container Instances (ACI) is the correct choice because it provides a serverless container platform that automatically restarts containers if they crash when configured with a restart policy of 'Always' or 'OnFailure'. This minimizes management overhead by eliminating the need to manage underlying infrastructure, orchestration, or virtual machines, making it ideal for simple, stateless containerized applications that require automatic recovery.

Exam trap

The trap here is that candidates often choose AKS because of its robust orchestration and self-healing capabilities, but they overlook the explicit requirement to minimize management overhead, which AKS does not satisfy due to the need to manage clusters, node pools, and networking.

How to eliminate wrong answers

Option B (Azure Functions) is wrong because it is a serverless compute service designed for event-driven, short-lived code execution, not for hosting long-running containerized applications; it does not natively support running arbitrary containers with automatic restart on crash. Option C (Azure Kubernetes Service) is wrong because while it can restart crashed containers via pod health probes and replica sets, it introduces significant management overhead for cluster configuration, node pools, and orchestration, which contradicts the requirement to minimize management overhead. Option D (Azure Virtual Machines) is wrong because it requires manual configuration of container runtime, restart policies, and VM health monitoring, resulting in high management overhead and no built-in automatic container restart without additional tooling like Azure Monitor or custom scripts.

Full explanation →

359

MCQhard

You are building an Azure Function that processes messages from an Azure Service Bus queue. The function must read a secret from Azure Key Vault at startup. The Key Vault has public network access disabled and is reachable only through a private endpoint in the same virtual network as the function's virtual network integration. The function's managed identity has been granted the Key Vault Secrets User role. The function fails to retrieve the secret at runtime. What should you do?

A.Grant the function's managed identity the Key Vault Contributor role instead of Secrets User.

B.Add the function's outbound IP addresses to the Key Vault firewall allow list.

C.Ensure the function app has virtual network integration enabled and that its DNS resolution uses the private endpoint's private DNS zone.

D.Enable the Key Vault soft-delete and purge protection features to allow secret retrieval.

AnswerC

With public network access disabled, the function must reach Key Vault through the private endpoint. That requires virtual network integration for outbound traffic and correct DNS resolution to the private IP via the privatelink.vaultcore.azure.net private DNS zone. Without these, the function resolves the public endpoint, which is blocked, causing the failure.

Why this answer

When Key Vault public network access is disabled, clients must connect through the private endpoint, which requires virtual network integration for outbound traffic and DNS resolution to the private IP. The managed identity and role assignment are already correct, so the missing pieces are network integration and private DNS configuration.

Exam trap

The trap here is treating a private-endpoint connectivity failure as a permissions problem and changing RBAC roles instead of fixing DNS and virtual network integration.

Full explanation →

360

MCQhard

A single-page app signs in users with Microsoft Entra ID and calls a protected API. The app cannot safely keep a client secret. Which OAuth flow should be used? The architecture review board prefers a managed Azure-native control.

A.Implicit flow

B.Client credentials flow

C.Resource owner password credentials flow

D.Authorization code flow with PKCE

AnswerD

PKCE adds a dynamically generated code verifier and challenge, binding the authorization code to the client without a secret, which suits a public single-page app. The authorization code flow itself keeps tokens out of the browser front channel, satisfying the review board's preference for a managed Microsoft Entra ID-native control.

Why this answer

The authorization code flow with PKCE (Proof Key for Code Exchange) is the correct choice because it is designed for public clients (like single-page apps) that cannot securely store a client secret. PKCE uses a dynamically generated cryptographic code verifier and challenge to prevent authorization code interception attacks, making it the recommended OAuth 2.0 flow for SPAs calling protected APIs in Microsoft Entra ID.

Exam trap

The trap here is that candidates often confuse the implicit flow (which was historically used for SPAs) with the modern PKCE-enhanced authorization code flow, not realizing that the implicit flow is now deprecated and the authorization code flow with PKCE is the current best practice for public clients.

How to eliminate wrong answers

Option A is wrong because the implicit flow is deprecated by OAuth 2.0 Security Best Current Practice (BCP) and Microsoft Entra ID recommends against it for SPAs due to security risks like access token leakage in the browser history. Option B is wrong because the client credentials flow is intended for server-to-server (confidential client) scenarios where no user is involved, not for a single-page app that signs in users. Option C is wrong because the resource owner password credentials flow requires the app to handle user credentials directly, which is insecure and violates the principle of delegated authentication; it is also not recommended by Microsoft Entra ID for modern applications.

Full explanation →

361

MCQeasy

A company exposes an internal REST API to external partners using Azure API Management. They need to enforce a rate limit of 100 requests per minute per subscription. Which policy should they add?

A.CORS policy

B.Rate limit policy

C.Throttling policy

D.Validate JWT policy

AnswerB

The Rate limit policy in Azure API Management is specifically designed to restrict the number of API calls an individual consumer, identified by a subscription key or user ID, can make within a defined time window. This policy enforces fair usage and prevents abuse by rejecting requests that exceed the configured limit with an HTTP 429 Too Many Requests status. It is ideal for managing consumption per external partner, ensuring each partner adheres to their allocated quota.

Why this answer

The Rate limit policy (option B) is correct because it enforces a per-subscription key rate limit of 100 requests per minute, which is exactly what the scenario requires. Azure API Management's rate-limit policy counts requests against the specified duration and blocks additional calls once the limit is exceeded, returning a 429 Too Many Requests response.

Exam trap

The trap here is that candidates confuse the 'rate-limit' policy (per-subscription, fixed window) with the 'throttling' policy (rate-limit-by-key, per-key or per-identity), but the question's requirement for 'per subscription' directly maps to the rate-limit policy, not the throttling policy.

How to eliminate wrong answers

Option A is wrong because the CORS policy handles cross-origin resource sharing (HTTP headers like Access-Control-Allow-Origin) and does not enforce any request rate limits. Option C is wrong because the throttling policy (rate-limit-by-key) is designed for per-key rate limiting but is typically used for more granular scenarios like per-IP or per-claim, and the question explicitly asks for per-subscription enforcement, which is the standard rate-limit policy. Option D is wrong because the Validate JWT policy validates JSON Web Tokens for authentication/authorization and has no mechanism to control request frequency.

Full explanation →

362

MCQhard

Your company has an Azure Kubernetes Service (AKS) cluster. You need to deploy a containerized application that requires persistent storage across pod restarts. The storage must be backed by Azure Disk and support ReadWriteOnce access mode. Which volume type should you use?

A.Azure Disk

B.Azure Blob Storage

C.EmptyDir

D.Azure Files

AnswerA

Azure Disk is the appropriate choice for persistent storage when a single pod requires dedicated, block-level storage. It natively supports the ReadWriteOnce access mode, meaning the volume can be mounted as read-write by a single node. In AKS, Azure Disks are provisioned dynamically via a StorageClass and PersistentVolumeClaim, ensuring data persistence even if the pod restarts or is rescheduled to a different node within the same cluster. This makes it ideal for stateful applications where data integrity for a single instance is paramount.

Why this answer

Azure Disk is the correct volume type because it provides a durable block storage device that can be attached to a pod in an AKS cluster. It supports the ReadWriteOnce (RWO) access mode, meaning the disk can be mounted as read-write by a single node, which aligns with the requirement for persistent storage that survives pod restarts. Azure Disk is ideal for stateful applications that need high-performance, low-latency storage and do not require concurrent access from multiple pods.

Exam trap

The trap here is that candidates often confuse Azure Files (which supports ReadWriteMany) with Azure Disk (which supports ReadWriteOnce), or they mistakenly choose EmptyDir thinking it provides persistence, when in fact it is temporary and tied to the pod's lifecycle.

How to eliminate wrong answers

Option B is wrong because Azure Blob Storage is object storage, not block storage, and it does not support the ReadWriteOnce access mode; it is typically accessed via REST APIs or Azure Blob CSI driver with different access modes (e.g., ReadWriteMany for multiple clients). Option C is wrong because EmptyDir is ephemeral storage that is created when a pod is assigned to a node and is deleted when the pod is removed, so it does not persist across pod restarts. Option D is wrong because Azure Files supports ReadWriteMany (RWX) access mode, not ReadWriteOnce, and is designed for concurrent access from multiple pods across nodes, which is not required here.

Full explanation →

363

MCQeasy

You are developing a background job that runs every hour on Azure App Service. The job must be resilient to restarts and should not affect the web app's performance. Which technology should you use?

A.A background thread in the web application

B.Azure Logic Apps

C.WebJobs (triggered)

D.Azure Functions (Consumption plan)

AnswerC

Triggered WebJobs are an integral feature of Azure App Service, allowing you to run scripts or executables as background processes within the same App Service plan as your web application. They are ideal for scheduled tasks, as they can be configured to run on a CRON schedule (e.g., hourly) and leverage the existing compute resources without impacting the web app's performance significantly. This provides a highly integrated, cost-effective, and reliable solution for background processing directly alongside the web application.

Why this answer

WebJobs (triggered) are designed specifically for running background tasks on Azure App Service. They run as separate processes from the web app, ensuring they do not affect the web app's performance, and they are resilient to restarts because the Azure WebJobs SDK automatically handles restart and retry logic. This makes them the ideal choice for a scheduled hourly job that must survive App Service restarts.

Exam trap

The trap here is that candidates often confuse Azure Functions with WebJobs, not realizing that WebJobs run inside the App Service sandbox and share the same scaling and restart behavior, whereas Functions on the Consumption plan are independent and subject to cold starts and different billing models.

How to eliminate wrong answers

Option A is wrong because a background thread in the web application runs within the same process as the web app, so if the App Service restarts, the thread is lost, and it can also degrade the web app's performance by competing for CPU and memory resources. Option B is wrong because Azure Logic Apps is a serverless workflow orchestrator that runs outside of App Service and is not designed to be a background job directly attached to a specific web app; it introduces additional latency and cost for a simple hourly task. Option D is wrong because Azure Functions on the Consumption plan can have cold start delays and are not directly tied to the App Service's lifecycle, meaning they do not benefit from the same restart resilience and shared resource management as WebJobs running within the same App Service plan.

Full explanation →

364

MCQmedium

You are developing an ASP.NET Core web API hosted on Azure App Service. The API needs to read secrets from Azure Key Vault at startup. You have enabled a system-assigned managed identity for the App Service. Which code should you use to create the Key Vault SecretClient?

A.new SecretClient(new Uri(keyVaultUrl), new DefaultAzureCredential())

B.new SecretClient(new Uri(keyVaultUrl), new ClientSecretCredential(tenantId, clientId, clientSecret))

C.new SecretClient(new Uri(keyVaultUrl), new ChainedTokenCredential())

D.new SecretClient(new Uri(keyVaultUrl), new InteractiveBrowserCredential())

AnswerA

This is the recommended and most secure approach for Azure App Services. DefaultAzureCredential automatically detects the execution environment and attempts various authentication methods, prioritizing managed identities when available. For an ASP.NET Core Web API hosted on Azure App Service, it will seamlessly leverage the App Service's system-assigned or user-assigned managed identity to authenticate with Azure Key Vault, eliminating the need to manage secrets or credentials in code. This adheres to the principle of least privilege and enhances security by avoiding hardcoded credentials.

Why this answer

`DefaultAzureCredential` automatically attempts to authenticate using the environment's managed identity when running on Azure App Service. Since a system-assigned managed identity is enabled, `DefaultAzureCredential` will chain through available credential sources and successfully use the managed identity endpoint to obtain a token for Key Vault, without requiring any explicit tenant ID, client ID, or secret.

Exam trap

The trap here is that candidates often choose `ClientSecretCredential` (Option B) because they are accustomed to using service principals with secrets, forgetting that managed identities eliminate the need for any hardcoded credentials.

How to eliminate wrong answers

Option B is wrong because `ClientSecretCredential` requires a client secret, which defeats the purpose of using a managed identity—it introduces a secret that must be stored and rotated, increasing security risk. Option C is wrong because `ChainedTokenCredential` is not a concrete credential class; it is a base class for building custom credential chains, and cannot be instantiated directly with `new`. Option D is wrong because `InteractiveBrowserCredential` is designed for interactive user authentication via a browser, which is not suitable for a server-side, unattended startup scenario in Azure App Service.

Full explanation →

365

Drag & Dropmedium

Arrange the steps to configure auto-scaling for an Azure App Service in the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

First navigate to App Service, then scale out, enable autoscale, configure rules, set limits.

Full explanation →

366

MCQmedium

Your Azure Functions app (running on the Consumption plan) processes messages from an Azure Storage queue. Occasionally, the function fails due to a timeout after 5 minutes. You need to increase the maximum execution time without changing the plan. What should you do?

A.Set the functionTimeout property in host.json to 10 minutes

B.Migrate the function app to the Premium or Dedicated plan

C.Use Durable Functions to split the work

D.Increase the visibility timeout of the queue message

AnswerA

The `functionTimeout` property within the `host.json` file is the correct and most direct mechanism to adjust the execution timeout for all functions within an Azure Functions app. On the Consumption plan, this value can be increased from the default 5 minutes up to a maximum of 10 minutes. This modification directly addresses the need to extend a single function's runtime without migrating to a different hosting plan, aligning perfectly with the problem's constraints.

Why this answer

On the Consumption plan, the default function timeout is 5 minutes, but it can be extended up to 10 minutes by setting the functionTimeout property in host.json. This is the only way to increase the timeout without changing the hosting plan. The setting applies to all functions in the app.

Exam trap

AZ-204 often tests the misconception that you can increase timeout by changing queue visibility or by using Durable Functions, but the trap is not knowing the host.json setting and its plan-specific limits.

How to eliminate wrong answers

Option B is wrong because migrating to Premium or Dedicated plan would allow longer timeouts, but the requirement is to avoid changing the plan. Option C is wrong because using Durable Functions is a design pattern to orchestrate long-running workflows, but it doesn't directly increase the timeout of a single function execution; it's a workaround, not a configuration change. Option D is wrong because increasing the visibility timeout of the queue message only affects how long the message is invisible to other consumers, not the function's execution timeout.

Full explanation →

367

MCQeasy

You have an application that stores user profile pictures in Azure Blob Storage. Users upload images via a web app. You need to ensure that the images are served securely over HTTPS and that only authenticated users can access them. The web app uses Azure App Service with built-in authentication. You want to avoid storing any access keys in the web app's configuration. What should you do to grant the web app access to the blobs?

A.Store the storage account access key in the web app's configuration.

B.Enable system-assigned managed identity on the App Service and assign the 'Storage Blob Data Reader' role on the blob container.

C.Enable anonymous public read access on the blob container.

D.Generate a SAS token with long expiration and store it in the web app's configuration.

AnswerB

Enabling a system-assigned managed identity on the App Service provides an Azure Active Directory identity for the application, eliminating the need to manage credentials directly. By assigning the 'Storage Blob Data Reader' role to this identity on the specific blob container, the App Service gains secure, token-based access to read profile pictures without storing any secrets. This method adheres to the principle of least privilege and leverages Azure AD for robust authentication and authorization, simplifying credential management and enhancing security.

Why this answer

Enabling a system-assigned managed identity on the App Service allows it to authenticate to Azure Storage without storing any credentials. By assigning the 'Storage Blob Data Reader' role on the blob container, the web app can securely access blobs using Azure AD authentication, which is the recommended approach for server-side access. This avoids storing access keys or SAS tokens in configuration, meeting the security requirement.

Exam trap

The trap here is that candidates may think a SAS token or access key is necessary for programmatic access, but Azure AD authentication via managed identity is the secure, keyless method that satisfies the 'no stored keys' requirement while still enforcing authentication.

How to eliminate wrong answers

Option A is wrong because storing the storage account access key in the web app's configuration violates the requirement to avoid storing access keys, and exposes the key to potential leakage via configuration management or logs. Option C is wrong because enabling anonymous public read access would allow any user (authenticated or not) to access the blobs, which contradicts the requirement that only authenticated users can access them. Option D is wrong because generating a SAS token with long expiration and storing it in configuration still requires managing a secret in the app settings, which violates the 'avoid storing any access keys' requirement and introduces risk of token leakage or expiration issues.

Full explanation →

368

MCQeasy

You are using Azure CLI to upload a blob using your Azure AD credentials (--auth-mode login). The command fails with an authorization error. What is the most likely cause?

A.The user does not have the 'Storage Blob Data Contributor' role on the storage account

B.The Azure CLI version is outdated

C.The storage account key is not provided

D.The container name does not exist

AnswerA

When using Azure AD for authentication with Azure Storage, authorization is managed through Azure Role-Based Access Control (RBAC). To upload blobs, the user's Azure AD identity must be assigned a data plane role that grants write permissions, such as 'Storage Blob Data Contributor'. Without this specific role, the Azure CLI command will fail with an authorization error, as the identity lacks the necessary permissions to perform the requested operation on the storage account's data plane. This is a fundamental security requirement for least privilege access.

Why this answer

When using `--auth-mode login` with Azure CLI, the operation relies on Azure AD role-based access control (RBAC). The user must be assigned a built-in role like 'Storage Blob Data Contributor' or 'Storage Blob Data Owner' on the storage account to authorize blob uploads. Without this role, the request fails with an authorization error because Azure AD has no permissions to grant access to the blob data plane.

Exam trap

The trap here is that candidates often confuse management-plane roles (e.g., Contributor) with data-plane roles (e.g., Storage Blob Data Contributor), assuming any Azure AD user with access to the storage account can upload blobs, when in fact a specific data-plane RBAC role is required.

How to eliminate wrong answers

Option B is wrong because an outdated Azure CLI version would typically cause syntax or compatibility errors, not an authorization failure specific to Azure AD credentials. Option C is wrong because `--auth-mode login` explicitly uses Azure AD authentication, not a storage account key; the key is irrelevant here. Option D is wrong because the container name not existing would result in a 'container not found' (404) error, not an authorization (403/401) error.

Full explanation →

369

Multi-Selecteasy

Which TWO of the following are features of Azure Blob Storage lifecycle management? (Choose two.)

Select 2 answers

A.Automatically delete blobs after a specified number of days.

B.Automatically move blobs to a cooler tier after a specified number of days.

C.Automatically apply legal hold to blobs.

D.Automatically replicate blobs to another region.

E.Automatically encrypt blobs at rest.

AnswersA, B

Azure Blob Storage lifecycle management policies allow users to define rules that automatically transition or delete blobs based on their age, access time, or other criteria. A common rule is to delete blobs that are older than a specified number of days, moving them to a soft-delete state or permanently removing them. This feature helps optimize storage costs and manage data retention policies efficiently.

Why this answer

Azure Blob Storage lifecycle management policies let you define rule-based actions that run against blobs based on age or last-modified time. Option A is correct because a lifecycle rule can include a delete action that automatically removes blobs after a specified number of days, which is a core use case for expiring stale data. Option B is correct because lifecycle rules can also include tiering actions, such as moving blobs from Hot to Cool or Cool to Archive after a specified number of days, to reduce storage costs.

Option C is not a lifecycle management feature; legal hold is an immutability setting applied through immutability policies or container-level holds, not through lifecycle rules. Option D is not part of lifecycle management; cross-region replication is handled by object replication or geo-redundant storage (GRS/RA-GRS) configurations. Option E is not a lifecycle action; encryption at rest is applied automatically by Azure Storage using Storage Service Encryption (SSE) and is not configured via lifecycle management policies.

Exam trap

The trap here is that candidates confuse lifecycle management with other Azure Blob Storage features like immutability policies (legal hold), replication, or encryption, which are separate capabilities with different purposes and configurations.

Full explanation →

370

MCQeasy

A company stores secrets in Azure Key Vault. Developers need to retrieve secrets from a web app without storing connection strings in code. Which authentication method should the web app use?

A.Register a service principal and use a client secret

B.Enable a managed identity for the web app

C.Use a shared access signature (SAS) token

D.Use a certificate thumbprint in the app settings

AnswerB

Enabling a managed identity for the web app is the recommended and most secure approach for accessing Azure Key Vault. A managed identity provides an automatically managed identity in Azure Active Directory for the application, allowing it to authenticate to Key Vault without any developer needing to manage credentials, secrets, or certificates. Azure handles the lifecycle of this identity, including its authentication tokens, significantly reducing the attack surface and operational overhead associated with secret management.

Why this answer

Managed identities for Azure resources provide an automatically managed identity in Azure AD, allowing the web app to authenticate to Key Vault without any credentials in code. The web app obtains an Azure AD access token directly from the Azure Instance Metadata Service (IMDS) endpoint, which Key Vault accepts. This eliminates the need to store connection strings, client secrets, or certificates in the application.

Exam trap

The trap here is that candidates often confuse managed identities with service principals, assuming a service principal with a client secret is the simplest approach, but they overlook that the client secret itself must be stored somewhere, violating the 'no secrets in code' requirement.

How to eliminate wrong answers

Option A is wrong because registering a service principal and using a client secret still requires storing that secret in the web app's configuration or code, defeating the goal of avoiding stored credentials. Option C is wrong because a shared access signature (SAS) token is used for delegating access to Azure Storage resources, not for authenticating to Key Vault. Option D is wrong because using a certificate thumbprint in app settings still requires the certificate to be deployed and managed on the web app, and the thumbprint alone does not provide authentication; the private key must be accessible, which introduces management overhead.

Full explanation →

371

MCQmedium

You have an Azure Event Grid topic that receives storage blob created events. You only want to process events for files with a '.jpg' extension. You need to minimize cost and latency. How should you filter the events?

A.Configure a subject filter in the Event Grid subscription with suffix '.jpg'

B.Filter inside the Azure Function code by checking the blob name extension

C.Use Azure Service Bus topics instead of Event Grid, with a filter on message properties

D.Create separate Event Grid topics for JPEG files and route only JPEG events

AnswerA

Event Grid subscriptions support robust server-side filtering capabilities, including subject suffix matching. By configuring a `subjectEndsWith` filter with '.jpg', only events where the blob name (which forms part of the event subject for Storage events) ends with '.jpg' will be delivered to the subscriber. This significantly reduces the volume of events processed by the Azure Function, optimizing compute costs and minimizing unnecessary invocations and associated latency.

Why this answer

Event Grid subscriptions support subject filtering with prefix and suffix matching, allowing you to filter events at the Event Grid service level before they are delivered to your endpoint. By configuring a subject filter with suffix '.jpg', only blob created events for files ending in '.jpg' are sent to your Azure Function, minimizing both cost (fewer invocations) and latency (no unnecessary processing). This approach avoids the overhead of receiving and discarding unwanted events in your function code.

Exam trap

The trap here is that candidates often assume filtering in code is simpler or more flexible, but they overlook that Event Grid's built-in subject filtering is the most cost-effective and low-latency approach because it prevents unwanted events from ever reaching the function endpoint.

How to eliminate wrong answers

Option B is wrong because filtering inside the Azure Function code still incurs the cost of every event being delivered to the function and the latency of function invocations for unwanted events, defeating the purpose of minimizing cost and latency. Option C is wrong because Azure Service Bus topics are designed for message queuing and pub/sub with message properties, but Event Grid is the native service for reacting to Azure storage blob events with built-in subject filtering; using Service Bus adds unnecessary complexity and cost. Option D is wrong because creating separate Event Grid topics for JPEG files requires additional management overhead and does not leverage the built-in filtering capability of Event Grid subscriptions, leading to higher cost and complexity without benefit.

Full explanation →

372

MCQeasy

You are deploying a containerized application to Azure Container Instances (ACI). The application writes temporary data to a local disk that must persist across container restarts (e.g., after a crash). Which configuration should you use?

A.Mount an Azure Files share as a volume in the container group.

B.Use the temporary disk automatically allocated by ACI.

C.Store data in an Azure Cosmos DB database.

D.Use an emptyDir volume as available in Kubernetes.

AnswerA

Mounting an Azure Files share as a volume in an Azure Container Instances (ACI) container group is the correct approach for persistent storage. Azure Files provides fully managed file shares that can be accessed via SMB or NFS protocols. When mounted as a volume, data written to the share by the container persists even if the container restarts, the container group is deleted, or a new container group is deployed, ensuring data durability for stateful applications.

Why this answer

Azure Container Instances (ACI) supports mounting an Azure Files share as a persistent volume. When a container restarts (e.g., after a crash), the temporary disk is wiped, but data written to an Azure Files share persists independently of the container's lifecycle. This meets the requirement for data to survive container restarts.

Exam trap

The trap here is that candidates often confuse the temporary disk (which is ephemeral) with persistent storage, or they incorrectly assume Kubernetes concepts like emptyDir apply to ACI, when ACI has its own volume mounting mechanisms (Azure Files, secrets, empty directories).

How to eliminate wrong answers

Option B is wrong because the temporary disk automatically allocated by ACI is ephemeral; its contents are lost when the container restarts or is redeployed, so it cannot persist data across restarts. Option C is wrong because Azure Cosmos DB is a globally distributed NoSQL database designed for structured data and high availability, not for temporary local disk storage; it introduces unnecessary latency and cost for simple temporary data persistence. Option D is wrong because emptyDir volumes are a Kubernetes concept and are not available in Azure Container Instances; ACI does not support Kubernetes-native volume types like emptyDir.

Full explanation →

373

MCQmedium

An application uses Azure Functions with a Durable Functions extension to orchestrate a workflow. The workflow calls multiple external APIs. The developer needs to handle transient failures when calling these APIs. Which pattern should the developer implement?

A.Implement retry logic with exponential backoff

B.Use a saga pattern

C.Use a request-reply pattern

D.Use a circuit breaker pattern

AnswerA

Durable Functions orchestrations are inherently stateful and resilient, making them ideal for implementing robust retry logic. Exponential backoff is a crucial strategy for handling transient failures, where retries are attempted with progressively longer delays between attempts. This prevents overwhelming the failing service and allows it time to recover, significantly improving the reliability of long-running operations within a durable orchestration. It's a best practice for distributed systems to manage intermittent issues effectively.

Why this answer

Durable Functions provides built-in support for automatic retry with exponential backoff via the `CallActivityWithRetryAsync` method or by configuring retry policies in orchestrator functions. This pattern is specifically designed to handle transient failures when calling external APIs, as it automatically retries failed operations with increasing delays, reducing load on the downstream service and improving resilience.

Exam trap

The trap here is that candidates may confuse the circuit breaker pattern with retry logic, but circuit breakers are for preventing cascading failures in long-term outages, not for handling transient failures with exponential backoff.

How to eliminate wrong answers

Option B is wrong because the saga pattern is used for managing distributed transactions and compensating actions across multiple services, not for handling transient failures in API calls. Option C is wrong because the request-reply pattern is a messaging pattern for asynchronous communication between components, not a mechanism for retrying failed operations. Option D is wrong because the circuit breaker pattern is designed to prevent repeated calls to a failing service by opening the circuit and failing fast, but it does not provide retry logic with exponential backoff for transient failures.

Full explanation →

374

Matchingmedium

Match each Azure container service to its primary use case.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Run containers on demand without orchestration

Managed Kubernetes cluster for orchestration

Serverless containers for microservices

Platform for building and managing microservices

Why these pairings

The correct matches are: AKS → orchestration with Kubernetes; ACI → on-demand containers; ACR → image registry; Container Apps → serverless containers with autoscaling. Common confusions include swapping AKS with ACI or mixing orchestration with simple container execution.

Full explanation →

375

MCQhard

Your application writes millions of small records (each under 1 KB) to Azure Table Storage every day. You notice that query performance degrades over time. Which design change would most improve performance?

A.Store all records in a single blob and use Blob Storage.

B.Use a hash of the timestamp as the PartitionKey to distribute writes evenly.

C.Increase the storage account's throughput limits.

D.Use a single PartitionKey and a sequential RowKey.

AnswerB

Using a hash of the timestamp as the PartitionKey is an effective strategy for distributing high-volume writes evenly across multiple partitions in Azure Table Storage. This approach prevents the creation of "hot partitions" by ensuring that records arriving in close temporal proximity are not necessarily grouped into the same physical partition. By spreading the write load, this method maximizes the overall throughput and scalability of the table, allowing the application to handle millions of small records efficiently without encountering throttling.

Why this answer

Using a hash of the timestamp as the PartitionKey distributes writes evenly across partition ranges, preventing hot partitions. Azure Table Storage scales by splitting partitions across storage nodes; sequential timestamps create a hot partition on the last node, degrading throughput. A hash ensures uniform load, maximizing the account's 20,000 IOPS per partition target.

Exam trap

The trap here is that candidates assume increasing throughput limits (Option C) or using a single partition key (Option D) will fix performance, but Azure's per-partition scaling constraints mean only distributing the partition key (Option B) addresses the hot partition bottleneck.

How to eliminate wrong answers

Option A is wrong because storing all records in a single blob eliminates the query and indexing capabilities of Table Storage, making record-level retrieval impractical and introducing a single point of contention for writes. Option C is wrong because increasing storage account throughput limits does not resolve the root cause of hot partitions; Azure enforces per-partition scaling limits (up to 2,000 entities per second) regardless of account-level limits. Option D is wrong because using a single PartitionKey with a sequential RowKey creates a hot partition on the last partition server, exactly the pattern that causes the observed degradation over time.

Full explanation →

Microsoft Azure Developer Associate AZ-204 (AZ-204) — Questions 301–375