Microsoft Azure Developer Associate AZ-204 AZ-204 Questions 376–450 | Page 6/12

376

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 →

377

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 →

378

Multi-Selectmedium

You are developing a solution that uses Azure Container Instances (ACI) to run a batch processing job. The job runs for approximately 30 minutes and requires access to a configuration file stored in Azure Files. You need to ensure the container instance can access the file share securely without using a public endpoint. Which TWO actions should you take?

Select 2 answers

A.Mount the Azure Files share using the storage account name and key.

B.Use a managed identity assigned to the container group to authenticate to the storage account.

C.Deploy the container group in an Azure virtual network that has a service endpoint to Azure Storage.

D.Use a shared access signature (SAS) token to mount the file share.

E.Enable the storage account's firewall to allow access from the container group's public IP.

AnswersA, C

Azure Container Instances (ACI) supports mounting Azure Files shares directly, enabling persistent storage for containers. To mount an Azure Files share, the container group requires the storage account name and its corresponding storage account key. This key acts as the primary credential for authentication and authorization to access the file share. For security, the storage account key should be passed to the container securely, typically via environment variables marked as secure or through Azure Key Vault integration, rather than hardcoding it in the container definition.

Why this answer

Mounting an Azure Files share using the storage account name and key is a supported method in Azure Container Instances. This approach uses the SMB protocol to directly attach the file share to the container, providing access to the configuration file without requiring a public endpoint. The storage account key is passed securely as part of the container group configuration, and the mount is handled internally within the Azure infrastructure.

Exam trap

The trap here is that candidates often assume managed identities can be used for any Azure resource authentication, but Azure Container Instances does not support managed identities for Azure Files mounts, and they may overlook that service endpoints provide private connectivity without needing to change the authentication method.

Full explanation →

379

MCQmedium

A company integrates an Azure Logic App with Microsoft Teams to send notifications when a new file is added to an Azure Blob storage container. The Logic App currently polls the blob container every minute. They want to reduce latency and avoid polling. What should they do?

A.Increase the polling frequency to every 10 seconds.

B.Add an Event Grid subscription to the blob storage.

C.Use Azure Data Factory to monitor the storage.

D.Use Azure Service Bus topics for file notifications.

AnswerB

Adding an Event Grid subscription to the blob storage is the correct approach because Azure Event Grid provides a fully managed, real-time event routing service. When a new blob is created, Event Grid automatically publishes an event. The Logic App, configured as an Event Grid subscriber, then receives this event directly, eliminating the need for constant polling and enabling an efficient, push-based, event-driven workflow for immediate notifications.

Why this answer

Azure Event Grid provides a reactive, event-driven model that eliminates the need for polling. By subscribing to the Blob Storage 'BlobCreated' event, the Logic App is triggered instantly when a new file is added, reducing latency to near real-time. This aligns with the requirement to avoid polling and improve responsiveness.

Exam trap

The trap here is that candidates may think increasing polling frequency (Option A) is a valid optimization, but the question explicitly requires eliminating polling, not just reducing its interval.

How to eliminate wrong answers

Option A is wrong because increasing polling frequency to every 10 seconds still uses polling, which incurs unnecessary compute costs and does not eliminate latency; it only reduces it marginally. Option C is wrong because Azure Data Factory is an orchestration and data movement service, not designed for real-time event monitoring or triggering Logic Apps based on blob storage events. Option D is wrong because Azure Service Bus topics are used for decoupled messaging between applications, not for directly triggering Logic Apps from blob storage events; they would require an additional publisher component to send notifications, adding complexity without solving the polling issue.

Full explanation →

380

Multi-Selecteasy

You need to grant a user access to read and write blobs in a specific container for exactly 24 hours. The user is external to your organization. Which two methods can you use? (Choose two.)

Select 2 answers

A.Create a shared access signature (SAS) token with an expiry time of 24 hours

B.Share the storage account access key with the user

C.Create an account SAS token with read and write permissions

D.Generate a user delegation SAS key using Azure AD credentials

E.Assign the 'Storage Blob Data Contributor' role to the user's Microsoft account

AnswersA, D

A service-level Shared Access Signature (SAS) token is the most appropriate solution here because it allows for granular, time-limited access to specific resources, such as a container or blob. By generating a service SAS for the target container with read and write permissions and a 24-hour expiry, the user gains the necessary access without compromising the entire storage account. This method adheres to the principle of least privilege, providing temporary, scoped access.

Why this answer

A shared access signature (SAS) token can be scoped to a specific container and granted read and write permissions, with an expiry time set to exactly 24 hours. This allows the external user to access only that container for the specified duration without exposing the storage account key or requiring Azure AD authentication.

Exam trap

The trap here is that candidates often confuse an account SAS with a service SAS, assuming an account SAS can be scoped to a single container, but in reality, an account SAS applies to the entire storage account and cannot be restricted to a specific container.

Full explanation →

381

MCQeasy

You need to securely connect an on-premises application to Azure Blob Storage without exposing data to the public internet. Which feature should you use?

A.IP firewall rules on the storage account

B.Azure Private Endpoint

C.Storage account access keys

D.Shared access signature (SAS) with stored access policy

AnswerB

Azure Private Endpoint establishes a private link from a virtual network (VNet) to an Azure service, such as a storage account. It assigns a private IP address from the VNet to the storage account's endpoint, making the service accessible only within that VNet or connected networks, like an on-premises environment via VPN or ExpressRoute. This completely bypasses the public internet, ensuring that all traffic remains within the Microsoft backbone and the private network, thus providing the highest level of secure, private connectivity.

Why this answer

Azure Private Endpoint uses a private IP address from your virtual network to connect to Azure Blob Storage over the Microsoft backbone network, ensuring traffic never traverses the public internet. This provides a secure, private connection for on-premises applications via VPN or ExpressRoute, meeting the requirement to avoid public exposure.

Exam trap

The trap here is that candidates often confuse IP firewall rules or SAS tokens as providing private connectivity, when in fact they only control access or authentication but still route traffic over the public internet.

How to eliminate wrong answers

Option A is wrong because IP firewall rules restrict access based on public IP addresses, but traffic still flows over the public internet, failing the 'no public internet' requirement. Option C is wrong because storage account access keys are shared secrets that authenticate requests over HTTPS, but they do not prevent data from traversing the public internet; they also pose security risks if leaked. Option D is wrong because a shared access signature (SAS) with a stored access policy provides time-limited, delegated access over HTTPS, but the data path still uses the public internet endpoint, not a private connection.

Full explanation →

382

MCQmedium

A company deploys an Azure App Service web app that stores sensitive data in Azure Blob Storage. The security team requires that all access to the blob storage must be authenticated and authorized via Microsoft Entra ID, and that no anonymous access is permitted. The web app must also be able to access the storage using its managed identity. Which configuration should the company implement?

A.Create a custom RBAC role that allows full access to the storage account and assign it to the web app's service principal.

B.Enable the web app's system-assigned managed identity, assign the Storage Blob Data Contributor role to the identity, and disable anonymous access on the storage account.

C.Use storage account access keys and store them in Key Vault, then configure the web app to retrieve them at runtime.

D.Generate a shared access signature (SAS) token with read permissions, store it in App Settings, and configure the web app to use it.

AnswerB

This is the correct and recommended approach for secure access. Enabling a system-assigned managed identity provides the web app with an identity in Microsoft Entra ID, eliminating the need for credential management. Assigning the Storage Blob Data Contributor role grants the necessary data plane permissions to the identity, adhering to the principle of least privilege. Disabling anonymous access on the storage account ensures all interactions are authenticated and authorized via Microsoft Entra ID and RBAC.

Why this answer

It satisfies all requirements: enabling a system-assigned managed identity for the web app allows it to authenticate to Azure Blob Storage without storing credentials, assigning the Storage Blob Data Contributor RBAC role authorizes that identity to read/write blobs, and disabling anonymous access ensures no unauthenticated requests are permitted. This configuration enforces Microsoft Entra ID (formerly Azure AD) as the sole authentication mechanism, meeting the security team's mandate.

Exam trap

The trap here is that candidates often confuse RBAC roles with access keys or SAS tokens, mistakenly thinking any form of credential (like a key or token) satisfies the 'authenticated and authorized via Microsoft Entra ID' requirement, when in fact only managed identity with RBAC and disabled anonymous access enforces Entra ID as the sole authentication method.

How to eliminate wrong answers

Option A is wrong because creating a custom RBAC role for full access is unnecessary and overly permissive; the built-in Storage Blob Data Contributor role already provides the required blob-level access, and the web app's service principal is automatically used via managed identity, not a separate custom role. Option C is wrong because using storage account access keys bypasses Microsoft Entra ID authentication entirely, violating the requirement that all access must be authenticated and authorized via Entra ID; keys are shared secrets that do not support identity-based authorization. Option D is wrong because a shared access signature (SAS) token does not use Microsoft Entra ID authentication; it relies on a token derived from the storage account key, which does not enforce identity-based access and cannot be scoped to a managed identity.

Full explanation →

383

Multi-Selecthard

Your company uses Azure API Management to manage APIs. You need to implement policies that ensure only authenticated requests from partners are allowed, and that responses are cached to improve performance. Which THREE policies should you configure?

Select 3 answers

A.set-header

B.rate-limit

C.cache-store

D.validate-jwt

E.cache-lookup

AnswersC, D, E

The cache-store policy in Azure API Management is specifically designed to take the current response from the backend service and store it within the API Management's internal cache. This policy is typically executed after a successful backend call, especially when a preceding cache-lookup policy indicates a cache miss. By storing the response for a specified duration, subsequent identical requests can be served directly from the cache, significantly reducing latency and the load on the backend API.

Why this answer

(cache-store) is correct because it is part of the caching policy in Azure API Management. When combined with cache-lookup, it stores the response in the internal or external cache after the backend has processed the request, reducing latency and backend load for subsequent identical requests. This directly supports the requirement to improve performance by caching responses.

Exam trap

The trap here is that candidates often confuse caching policies (cache-store, cache-lookup) with other performance-related policies like rate-limit or set-header, failing to recognize that caching requires a specific pair of policies to function correctly.

Full explanation →

384

Matchingmedium

Match each Azure security feature to its function.

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

Concepts

Matches

Securely store and manage secrets, keys, and certificates

Cloud workload protection with threat detection

Enforce organizational standards and compliance rules

Fine-grained access management for Azure resources

Why these pairings

Azure Security Center provides unified security management and threat protection; Azure Sentinel is a cloud-native SIEM/SOAR; Azure Key Vault safeguards keys and secrets; Azure Active Directory manages identity and access. Common confusions include mixing Security Center with Sentinel or Sentinel with Azure AD.

Full explanation →

385

MCQmedium

Refer to the exhibit. An Azure App Service deployment is configured using this ARM template snippet. The web app is built from a GitHub repository. However, when a pull request is merged to main, the app does not automatically deploy. What is the most likely cause?

A.The isManualIntegration property is set to false.

B.The runtime stack is incorrect for the application.

C.The branch is set to main, but the deployments only trigger on a different branch.

D.The GitHub Actions workflow file is missing from the repository.

AnswerD

The ARM template only enables the integration; the actual workflow file must exist in the repo.

Why this answer

The most likely cause is that the GitHub Actions workflow file is missing from the repository. The ARM template configures the web app to use GitHub Actions for deployment, but it does not create the workflow file. Without the workflow file in the repository at the path referenced (e.g., .github/workflows/), the deployment will not trigger on pull request merges.

Option A is incorrect because isManualIntegration: false means automated deployment is expected. Option B is unlikely because the runtime stack is typically specified correctly in the ARM template. Option C is incorrect because the branch is set to main, which typically triggers deployments on merges to main.

Full explanation →

386

MCQhard

You are using Azure API Management to expose a legacy SOAP API as a RESTful API. The SOAP API has complex XML schemas. You need to transform the SOAP response to JSON. Which policy should you use?

A.transform-body

B.return-response

C.convert-to-json

D.set-body

AnswerD

The `set-body` policy is the correct and most versatile policy for transforming the request or response body in Azure API Management. It allows developers to programmatically modify the content using C# expressions, Liquid templates, or XSLT, enabling complex transformations like converting a SOAP XML response into a modern JSON format. This policy can access context variables and apply sophisticated logic to reshape the data before it reaches the client.

Why this answer

The `set-body` policy is correct because it allows you to replace the body of the SOAP response with a JSON representation. In Azure API Management, you can use the `set-body` policy with a Liquid template or a .NET expression to transform the incoming XML SOAP response into JSON, effectively converting the complex XML schemas to a RESTful JSON output.

Exam trap

The trap here is that candidates may confuse the conceptual need to 'convert to JSON' with a non-existent policy name like `convert-to-json`, or they might think `transform-body` is a real policy, when in fact Azure API Management uses `set-body` for all body transformations.

How to eliminate wrong answers

Option A is wrong because `transform-body` is not a valid Azure API Management policy; the correct policy for modifying the body is `set-body`. Option B is wrong because `return-response` is used to completely override the response with a new status code, headers, and body, but it does not provide the transformation logic needed to convert SOAP XML to JSON. Option C is wrong because `convert-to-json` is not a built-in policy in Azure API Management; the platform does not have a direct policy with that name, and the transformation must be done via `set-body` with appropriate expressions.

Full explanation →

387

MCQmedium

Your IoT solution generates billions of small telemetry entries (each ~100 bytes). Data is written once and rarely updated. You need to run analytical queries on the last 30 days of data daily, scanning large ranges by timestamp, requiring sub-second response times. You want the lowest storage cost. Which Azure Storage solution should you use?

A.Azure Blob Storage

B.Azure Table Storage

C.Azure Cosmos DB

D.Azure Data Lake Storage

AnswerB

Azure Table Storage is a highly scalable and cost-effective NoSQL key-value store specifically designed for storing massive amounts of structured, non-relational data. Its architecture allows for efficient storage and retrieval of billions of small telemetry entries, leveraging PartitionKey and RowKey for rapid lookups and range queries, which is crucial for time-series data analysis without the overhead of a full relational database or higher-cost NoSQL alternatives.

Why this answer

Azure Table Storage is correct because it is a NoSQL key-value store optimized for high-volume, low-cost storage of structured data like telemetry entries. It supports efficient range queries on the partition key (e.g., timestamp) and row key, enabling sub-second scans of large date ranges. Its storage cost is the lowest among Azure storage options for this workload, as it charges only for consumed capacity with no minimum throughput commitments.

Exam trap

The trap here is that candidates often choose Azure Cosmos DB for its low-latency queries, overlooking the explicit 'lowest storage cost' requirement, which Table Storage satisfies due to its simpler architecture and lack of provisioned throughput costs.

How to eliminate wrong answers

Option A is wrong because Azure Blob Storage is designed for unstructured binary or text data, not for efficient range queries on structured fields like timestamps; scanning billions of small entries would require costly and slow blob listing or external indexing. Option C is wrong because Azure Cosmos DB, while supporting fast queries, has significantly higher storage and throughput costs compared to Table Storage, making it unsuitable for the lowest storage cost requirement. Option D is wrong because Azure Data Lake Storage is optimized for big data analytics on large files (e.g., petabytes) and hierarchical namespaces, not for sub-second range queries on billions of tiny records; its cost per GB is higher than Table Storage for this scale.

Full explanation →

388

Multi-Selectmedium

A company is designing a serverless application using Azure Functions. They need to orchestrate multiple functions in a workflow, handle errors, and manage state. Which TWO features should they use?

Select 2 answers

A.Fan-out/Fan-in pattern

B.Azure Event Grid

C.Durable Functions

D.Azure Logic Apps

E.Azure Data Factory

AnswersA, C

This pattern is a common and powerful serverless orchestration technique, particularly well-suited for Azure Durable Functions. It involves executing multiple functions in parallel (fan-out) and then waiting for all of them to complete before aggregating their results (fan-in). This enables efficient parallel processing of independent tasks within a single, stateful workflow, making it ideal for scenarios like image processing, batch data processing, or complex report generation.

Why this answer

The Fan-out/Fan-in pattern is a core feature of Durable Functions that allows you to execute multiple functions in parallel (fan-out) and then aggregate their results (fan-in). This pattern is essential for orchestrating workflows, handling errors via retry policies, and managing state across function executions. Durable Functions provide built-in state management and checkpointing, making them ideal for serverless orchestration scenarios.

Exam trap

The trap here is that candidates may confuse Azure Logic Apps with Durable Functions, but Logic Apps is a separate service with its own pricing and execution model, not a feature of Azure Functions, and the question explicitly asks for features within a serverless application using Azure Functions.

Full explanation →

389

MCQhard

Refer to the exhibit. You are deploying an ARM template that assigns the 'Storage Blob Data Contributor' role to the managed identity of an App Service named 'myapp' at the storage account 'mystorageacct' scope. The deployment fails with an error that 'principalId' is null. What is the most likely cause?

A.The role definition ID is incorrect.

B.The storage account name 'mystorageacct' does not exist.

C.The role assignment name is not unique.

D.The App Service 'myapp' does not have a managed identity enabled.

AnswerD

For an Azure resource like an App Service to be assigned an Azure RBAC role, it must possess an associated Azure Active Directory identity, which is provided by a managed identity. If the App Service 'myapp' does not have a system-assigned or user-assigned managed identity enabled, it lacks the necessary `principalId` (object ID) that Azure RBAC requires to create the role assignment. Consequently, the deployment fails because the `principalId` property cannot be resolved or is null, preventing the role from being assigned to the service.

Why this answer

The error 'principalId' is null indicates that the ARM template is attempting to assign a role to a principal that does not exist. In this scenario, the principal is the managed identity of the App Service 'myapp'. If the App Service does not have a managed identity enabled, the 'principalId' property in the role assignment resource will be null, causing the deployment to fail.

Enabling a system-assigned or user-assigned managed identity on the App Service is required before the role assignment can succeed.

Exam trap

The trap here is that candidates may assume the error is due to a missing storage account or incorrect role definition, but the null 'principalId' directly points to the managed identity not being enabled on the App Service.

How to eliminate wrong answers

Option A is wrong because an incorrect role definition ID would cause a 'RoleDefinitionIdNotFound' or similar error, not a null 'principalId'. Option B is wrong because a non-existent storage account would result in a 'ResourceNotFound' error, not a null 'principalId'. Option C is wrong because a non-unique role assignment name would produce a 'RoleAssignmentExists' conflict error, not a null 'principalId'.

Full explanation →

390

MCQmedium

You are developing a web application that processes images uploaded by users. The images must be resized and analyzed for offensive content before being stored. You need to implement the solution with minimal latency and cost. What should you do?

A.Use Azure Batch to process images in parallel.

B.Use Durable Functions to orchestrate the resizing and analysis.

C.Use Azure Logic Apps with a trigger for each upload.

D.Use an Azure Function triggered by Blob Storage, with Consumption plan.

AnswerD

An Azure Function triggered by Blob Storage on a Consumption plan is an ideal solution because it is inherently event-driven, reacting immediately to new image uploads. The Consumption plan offers a serverless execution model, meaning you only pay for the compute resources and execution time consumed, making it highly cost-effective for intermittent or variable workloads. Furthermore, it automatically scales out or in based on demand, ensuring high availability and performance without manual intervention, perfectly suiting a web application's dynamic image processing needs.

Why this answer

Using an Azure Function triggered by Blob Storage on a Consumption plan provides a serverless, event-driven architecture that automatically scales to process each image upload with minimal latency and cost. The Consumption plan charges only for execution time and resources used, making it cost-effective for sporadic workloads, while the Blob Storage trigger ensures immediate processing upon upload without polling or additional infrastructure.

Exam trap

The trap here is that candidates often over-engineer the solution by choosing orchestration tools like Durable Functions or Logic Apps for simple sequential tasks, missing that a single Azure Function triggered by Blob Storage is the simplest, lowest-latency, and most cost-effective approach for event-driven image processing.

How to eliminate wrong answers

Option A is wrong because Azure Batch is designed for large-scale, compute-intensive batch jobs with job scheduling and pool management, which introduces overhead and latency unsuitable for real-time, per-upload processing. Option B is wrong because Durable Functions are meant for orchestrating long-running, stateful workflows with checkpoints and retries, adding unnecessary complexity and latency for simple, sequential operations like resizing and analysis. Option C is wrong because Azure Logic Apps incur higher per-action costs and introduce connector-based latency compared to a direct Azure Function trigger, and they are better suited for enterprise integration workflows rather than lightweight, event-driven image processing.

Full explanation →

391

MCQmedium

You are monitoring a web application with Application Insights. The application occasionally returns HTTP 500 errors. You want to be notified immediately when the error rate exceeds 5% of all requests in a rolling 5-minute window. Which feature of Application Insights should you configure?

A.Create a Smart Detection rule for anomalous failures.

B.Create a metric alert on the 'Failed requests' metric with a threshold of 5%.

C.Create a log alert using a Kusto query that calculates the percentage of failed requests over the last 5 minutes, with an alert condition when the result exceeds 0.05.

D.Create an availability test that checks for HTTP 200 responses and alert on failures.

AnswerC

Log alerts allow complex queries. For example: 'requests | where timestamp > ago(5m) | summarize total=count(), failures=countif(success == false) | extend percent = failures * 100.0 / total | where percent > 5'. This triggers an alert when the condition is met.

Why this answer

A log alert using a Kusto query allows you to calculate the exact percentage of failed requests over a rolling 5-minute window and trigger when that percentage exceeds 0.05 (5%). This is the only option that supports a dynamic, percentage-based threshold on a rolling time window, which is required for the stated condition. Metric alerts on 'Failed requests' measure absolute counts, not percentages, and Smart Detection does not allow custom percentage thresholds.

Exam trap

The trap here is that candidates confuse metric alerts (which work on absolute counts or rates) with log alerts (which can compute custom ratios like percentages), leading them to choose Option B without realizing that the 'Failed requests' metric cannot be configured to alert on a percentage threshold.

How to eliminate wrong answers

Option A is wrong because Smart Detection for anomalous failures uses machine learning to detect unusual patterns in failure rates, not a fixed 5% threshold over a 5-minute window; it cannot be configured to alert on a specific percentage. Option B is wrong because a metric alert on the 'Failed requests' metric measures the absolute count or rate of failed requests, not the percentage of failed requests relative to total requests; you cannot set a threshold of 5% on this metric directly. Option D is wrong because an availability test checks specific URLs for HTTP 200 responses and alerts on individual test failures, not on the aggregate error rate across all requests in a rolling time window.

Full explanation →

392

MCQmedium

You are building an API that needs to send notifications to multiple subscribers. Each subscriber has a different callback URL, and you need to ensure each notification is sent exactly once and retried on failure. Which Azure service should you use?

A.Azure Event Grid.

B.Azure Service Bus.

C.Azure Notification Hubs.

D.Azure Queue Storage.

AnswerB

Correct. Service Bus topics with duplicate detection provide exactly-once delivery. Subscribers can receive messages and send them to callback URLs via custom handlers, and retries are handled automatically.

Why this answer

Azure Service Bus is the correct choice because it supports exactly-once delivery through duplicate detection and can fan out notifications to multiple subscribers using topics and subscriptions. It also provides built-in retry logic on failures. While Event Grid offers at-least-once delivery, only Service Bus can guarantee exactly-once when properly configured.

Exam trap

Candidates often choose Event Grid for notification routing but overlook the 'exactly once' requirement. Event Grid is at-least-once. Service Bus, with duplicate detection, can achieve exactly-once delivery.

How to eliminate wrong answers

Option B (Azure Service Bus) is wrong because it is a message broker designed for point-to-point or competing consumer patterns, not for broadcasting to multiple subscribers with individual callback URLs; it lacks native webhook delivery and requires custom polling or relay logic. Option C (Azure Notification Hubs) is wrong because it is optimized for push notifications to mobile devices (e.g., iOS, Android) and does not support arbitrary HTTP callback URLs or exactly-once delivery to multiple webhook subscribers. Option D (Azure Queue Storage) is wrong because it is a simple message queue for decoupling components with at-least-once delivery and no built-in retry or webhook subscription model; it cannot directly send notifications to multiple callback URLs.

Full explanation →

393

MCQhard

Your application uses Azure Key Vault to store cryptographic keys used for signing. You need to ensure that the keys can be used by multiple applications, but only one application should be able to delete the key. What should you do?

A.Assign the 'Key Vault Crypto Officer' role to the application that needs to delete, and 'Key Vault Crypto User' to others.

B.Enable soft-delete and purge protection on the key vault.

C.Create a key rotation policy that automatically deletes old keys.

D.Configure the key vault firewall to allow only the authorized application's IP.

AnswerA

The 'Key Vault Crypto Officer' Azure RBAC role grants comprehensive permissions over cryptographic keys, including the `delete` action, making it suitable for applications requiring the ability to remove keys. Conversely, the 'Key Vault Crypto User' role provides permissions for cryptographic operations like `encrypt` and `decrypt` but explicitly excludes deletion capabilities. This granular role assignment directly implements the principle of least privilege, ensuring only authorized applications can perform destructive actions on sensitive cryptographic material.

Why this answer

Azure RBAC for Key Vault allows granular permissions. The 'Key Vault Crypto Officer' role includes delete permission for keys, while the 'Key Vault Crypto User' role only allows cryptographic operations (sign, verify, encrypt, decrypt) without delete. This meets the requirement of allowing multiple applications to use keys but restricting deletion to one specific application.

Exam trap

The trap here is that candidates often confuse soft-delete/purge protection with access control, thinking they restrict who can delete, when in fact they only protect against permanent loss after a delete is already authorized.

How to eliminate wrong answers

Option B is wrong because soft-delete and purge protection prevent accidental or permanent deletion of keys, but they do not restrict which application can initiate a delete operation; any application with delete permission can still trigger soft-delete. Option C is wrong because a key rotation policy automatically creates new key versions and optionally archives old ones, but it does not control which application can delete keys; it is a lifecycle management feature, not an access control mechanism. Option D is wrong because configuring the key vault firewall restricts network access to the vault itself, but it does not differentiate permissions between applications that are allowed through the firewall; all allowed applications would have the same access level unless combined with RBAC roles.

Full explanation →

394

MCQmedium

Your API is secured using Azure AD (now Microsoft Entra ID) tokens. You need to validate the token in your custom code. Which library should you use to validate the token's signature, issuer, and audience?

A.ASP.NET Core Identity

B.Microsoft Graph SDK

C.Microsoft Authentication Library (MSAL)

D.Microsoft.IdentityModel.Tokens and System.IdentityModel.Tokens.Jwt

AnswerD

These libraries are the foundational components in .NET for handling and validating JSON Web Tokens (JWTs) issued by identity providers like Azure AD/Microsoft Entra ID. System.IdentityModel.Tokens.Jwt provides the core classes for reading, writing, and performing cryptographic validation of JWTs. Microsoft.IdentityModel.Tokens supplies the necessary security token validation parameters, such as issuer, audience, lifetime, and signing key resolution, to ensure the token's authenticity and integrity when securing an API.

Why this answer

The Microsoft.IdentityModel.Tokens and System.IdentityModel.Tokens.Jwt libraries provide the core token validation logic (signature verification, issuer, audience) that can be used in custom code, independent of any framework. These libraries implement the JWT validation pipeline as defined in RFC 7519, allowing you to call TokenValidationParameters and JwtSecurityTokenHandler.ValidateToken() to manually verify the token's integrity and claims.

Exam trap

The trap here is that candidates often confuse MSAL (which acquires tokens) with the token validation libraries, assuming the same library handles both sides of the authentication flow.

How to eliminate wrong answers

Option A is wrong because ASP.NET Core Identity is a membership and user store framework for managing user accounts, not a library for validating JWT tokens issued by Azure AD. Option B is wrong because the Microsoft Graph SDK is used to call Microsoft Graph APIs, not to validate tokens; it relies on an already-validated token to make requests. Option C is wrong because MSAL is designed for acquiring tokens (authentication), not for validating them; token validation is the responsibility of the resource API, not the client library.

Full explanation →

395

MCQhard

You deploy a microservices architecture on Azure Kubernetes Service (AKS). Some pods report OOMKilled errors. Which diagnostic step should you take first?

A.Enable cluster autoscaler to add more nodes

B.Review container resource requests and limits in the pod YAML

C.Check node memory utilization with kubectl top nodes

D.Configure horizontal pod autoscaler based on memory

AnswerB

An OOMKilled (Out Of Memory Killed) event is a direct indication that a container process attempted to consume more memory than the `resources.limits.memory` value specified in its pod's YAML definition. Reviewing these container resource limits is the most direct and effective action, as it allows you to identify if the allocated memory is insufficient for the application's actual workload. Adjusting these limits, after proper profiling, directly addresses the root cause of the termination.

Why this answer

The OOMKilled error indicates that a container exceeded its memory limit. The first diagnostic step is to review the container's resource requests and limits in the pod YAML to determine if the memory limit is set too low for the workload. This directly addresses the root cause before scaling or checking node-level metrics.

Exam trap

The trap here is that candidates often jump to scaling solutions (cluster autoscaler or HPA) or node-level monitoring, overlooking that OOMKilled is a container-level limit violation that must be diagnosed by examining the pod's resource configuration first.

How to eliminate wrong answers

Option A is wrong because enabling cluster autoscaler adds more nodes to handle node-level resource pressure, but it does not fix a container that is already hitting its memory limit; the pod will still be OOMKilled on any node. Option C is wrong because checking node memory utilization with 'kubectl top nodes' shows aggregate node memory usage, not per-container limits, and cannot identify if a specific container's limit is too low. Option D is wrong because configuring a horizontal pod autoscaler based on memory would scale the number of pods in response to average memory utilization, but it does not address the immediate cause of a single container exceeding its hard limit; the pod would still be OOMKilled before scaling occurs.

Full explanation →

396

MCQeasy

You are using Azure Application Insights to monitor a web application. You need to create a custom dashboard that shows the number of failed requests per endpoint over the last 24 hours. Which query language should you use?

A.Python

B.Kusto Query Language (KQL)

C.SQL

D.PowerShell

AnswerB

KQL is the query language for Azure Data Explorer and Application Insights.

Why this answer

Azure Application Insights stores telemetry data in a Log Analytics workspace, which is queried using Kusto Query Language (KQL). To create a custom dashboard showing failed requests per endpoint over the last 24 hours, you would use a KQL query that filters on 'requests' where 'success == false', then summarizes by 'cloud_RoleInstance' or 'url' using the 'summarize' operator and the 'bin' function for time intervals. KQL is the native query language for Azure Monitor and Application Insights, making it the correct choice for this scenario.

Exam trap

The trap here is that candidates may confuse Application Insights with traditional SQL-based monitoring tools, or assume that any scripting language (like Python or PowerShell) can be used directly in the Azure portal's query editor, when in fact KQL is the only supported query language for Application Insights log queries and dashboards.

How to eliminate wrong answers

Option A is wrong because Python is a general-purpose programming language and is not used to directly query Application Insights data; while you could use Python with the Azure Monitor SDK to retrieve data, the question specifically asks for the query language used within the Azure portal or dashboards, which is KQL. Option C is wrong because SQL is not supported for querying Application Insights telemetry; Application Insights uses KQL, which has a different syntax and operators (e.g., 'summarize', 'where', 'project') compared to SQL's SELECT/FROM/WHERE structure. Option D is wrong because PowerShell is a scripting language and automation tool, not a query language for directly querying Application Insights data; although you can use PowerShell cmdlets to retrieve logs, the native query language for dashboards and log analytics is KQL.

Full explanation →

397

MCQhard

Your application uses Azure Queue Storage to process orders. Occasionally, messages are not processed and remain in the queue. You need to ensure that messages are automatically retried after a specified time if they are not deleted. What should you configure?

A.Set the message visibility timeout to a small value

B.Configure a dead-letter queue

C.Enable queue storage logging

D.Increase the message time-to-live (TTL)

AnswerA

When a message is dequeued, it becomes temporarily invisible for the duration of the visibility timeout. Setting a small visibility timeout ensures that if a worker fails to process the message and does not delete it, the message quickly reappears in the queue. This allows another worker, or the same worker after a short delay, to pick up the message for a retry attempt, making it an effective strategy for handling transient processing failures.

Why this answer

Setting the message visibility timeout to a small value ensures that if a message is not deleted after processing (i.e., the worker fails or crashes), the message becomes visible again in the queue after the short timeout. This allows other queue consumers to retry processing the message automatically. The visibility timeout controls how long a message is hidden from other consumers after being dequeued, and a small value reduces the delay before a retry occurs.

Exam trap

The trap here is that candidates often confuse the visibility timeout with the message time-to-live (TTL) or think that logging or dead-letter queues directly enable automatic retries, when in fact the visibility timeout is the key mechanism for controlling retry timing.

How to eliminate wrong answers

Option B is wrong because a dead-letter queue is used to isolate messages that have exceeded their maximum delivery count or failed processing repeatedly, not to automatically retry messages after a specified time. Option C is wrong because enabling queue storage logging only records operations for auditing and diagnostics; it does not affect message retry behavior. Option D is wrong because increasing the message time-to-live (TTL) only extends how long a message can remain in the queue before expiring; it does not control when or how messages are retried after a processing failure.

Full explanation →

398

MCQeasy

You deploy a container to Azure Container Instances. The container needs to persist data when it restarts. You mount an Azure Files share to a directory inside the container. Which volume type is this?

A.emptyDir

B.gitRepo

C.azureFile

D.secret

AnswerC

An azureFile volume mounts an Azure Files share directly into a container, providing robust, network-attached persistent storage. Data written to this volume is stored externally in Azure Storage, ensuring it survives container restarts, crashes, or even the complete deletion and recreation of the container instance. This decoupling of storage from the container lifecycle is crucial for stateful applications requiring data durability and availability across container operations.

Why this answer

Azure Container Instances supports mounting an Azure Files share as a volume to persist data across container restarts. The `azureFile` volume type references a pre-created Azure storage account and file share, which is mounted into the container's filesystem using SMB 3.0 protocol. This ensures data survives container crashes or restarts, as it is stored externally in Azure Files.

Exam trap

The trap here is that candidates may confuse `emptyDir` with persistent storage because it is commonly used in Kubernetes for temporary data, but in Azure Container Instances, `emptyDir` does not survive container restarts, whereas `azureFile` is the correct choice for persistence.

How to eliminate wrong answers

Option A is wrong because `emptyDir` is a temporary volume that exists only as long as the container runs; it is created empty when a container starts and is deleted when the container stops, so it does not persist data across restarts. Option B is wrong because `gitRepo` is a volume type used to clone a Git repository into the container at startup, not for persistent storage of application data. Option D is wrong because `secret` is used to inject sensitive data (e.g., certificates, keys) into a container as files, not for general-purpose persistent data storage.

Full explanation →

399

MCQmedium

You are building an Azure Logic App that must send a confirmation email to users after a purchase. Your company uses Office 365 for email and you want to use the corporate email address. Which connector should you use?

A.Office 365 Outlook

B.SMTP

C.SendGrid

D.Outlook.com

AnswerA

This connector provides native and secure integration with Microsoft 365 (formerly Office 365) environments, leveraging OAuth 2.0 for authentication against a corporate Azure Active Directory tenant. It enables the Logic App to send emails directly from a user's or shared mailbox's corporate email account, ensuring compliance and proper sender identity. This is the recommended and most robust method for sending business-related confirmations within an organization's email infrastructure.

Why this answer

The Office 365 Outlook connector is the correct choice because it provides direct, managed integration with Office 365 email services, allowing the Logic App to send emails using the corporate email address without needing to configure SMTP server details or handle authentication manually. This connector supports OAuth 2.0 authentication, which is the recommended and secure method for accessing Office 365 resources, and it is specifically designed for enterprise Office 365 accounts.

Exam trap

The trap here is that candidates confuse the Outlook.com connector (for personal accounts) with the Office 365 Outlook connector (for enterprise accounts), or they assume SMTP is always the simplest choice without considering authentication and security requirements in a cloud-native service.

How to eliminate wrong answers

Option B (SMTP) is wrong because while SMTP can technically send emails, it requires manual configuration of server, port, and credentials, and does not natively support OAuth 2.0 for Office 365, making it less secure and more complex to maintain in a Logic App. Option C (SendGrid) is wrong because SendGrid is a third-party email delivery service, not designed for sending emails directly from a corporate Office 365 mailbox; it would require a separate SendGrid account and API key. Option D (Outlook.com) is wrong because the Outlook.com connector is intended for personal Microsoft accounts (e.g., @outlook.com, @hotmail.com), not for corporate Office 365 accounts, and it does not support enterprise features like shared mailboxes or Exchange Online policies.

Full explanation →

400

MCQmedium

Refer to the exhibit. You are deploying an ARM template that includes the above network security group rule. The rule is intended to block all outbound internet traffic from a virtual network. However, after deployment, virtual machines in the subnet still have outbound internet access. What is the most likely reason?

A.The destination port range '*' is invalid; you must specify explicit ports.

B.The source address prefix should be '*' instead of 'VirtualNetwork'.

C.The network security group is not associated with the subnet or network interface.

D.The rule priority is too low; it should be lower than the default allow rule.

AnswerC

An Azure Network Security Group, even when perfectly configured with appropriate rules, remains ineffective until it is explicitly associated with either a subnet or a specific network interface (NIC). Without this crucial association step, the NSG rules are not applied to any network traffic flowing to or from virtual machines or other resources. Therefore, the lack of association renders any defined security rules inert and unable to enforce traffic filtering.

Why this answer

A network security group (NSG) rule only takes effect when the NSG is explicitly associated with a subnet or a network interface. Without this association, the rule is not applied to traffic flowing through the subnet, so virtual machines retain default outbound internet access. The ARM template may have defined the NSG and its rules, but if the association step (e.g., via Microsoft.Network/virtualNetworks/subnets with the networkSecurityGroup property) is missing or misconfigured, the rule is effectively ignored.

Exam trap

The trap here is that candidates often assume defining a rule in an ARM template automatically applies it to traffic, but Azure requires explicit association of the NSG with a subnet or NIC for the rules to be enforced.

How to eliminate wrong answers

Option A is wrong because the destination port range '*' is valid in an NSG rule and means 'all ports', which is appropriate for blocking all outbound internet traffic. Option B is wrong because using 'VirtualNetwork' as the source address prefix is correct for targeting traffic originating from within the virtual network; using '*' would also work but is less specific and not the cause of the issue. Option D is wrong because the rule priority is not too low; the default allow rules have high priority numbers (e.g., 65000 and 65500), so a lower priority number (e.g., 100) would actually override them.

The problem is the lack of association, not the priority value.

Full explanation →

401

MCQhard

Your application uses Azure Functions and needs to authenticate to a downstream API using OAuth 2.0. The function app uses a system-assigned managed identity. Which token endpoint should the function app call to get a token for the downstream API?

A.https://{function-app}.azurewebsites.net/.auth/login

B.https://{downstream-api}.azurewebsites.net/.auth/me

C.https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token

D.http://169.254.169.254/metadata/identity/oauth2/token

AnswerD

This is the correct and secure endpoint for Azure resources configured with a Managed Identity to acquire an access token. The Azure Instance Metadata Service (IMDS) provides this non-routable, local REST endpoint, accessible only from within the Azure resource (e.g., an Azure Function instance). When a managed identity makes a request to this specific IP address, IMDS intercepts it, authenticates the request as coming from the managed identity, and then securely requests an access token from Azure AD on behalf of that identity, returning it to the calling application. This mechanism eliminates the need for developers to manage any credentials.

Why this answer

The Azure Instance Metadata Service (IMDS) endpoint at http://169.254.169.254/metadata/identity/oauth2/token is the standard way for an Azure resource (like a Function App) with a system-assigned managed identity to obtain an OAuth 2.0 access token for a downstream API. This endpoint is used internally by the Azure SDK and is the only endpoint that directly leverages the managed identity without requiring any client secret or certificate.

Exam trap

The trap here is that candidates often confuse the standard Azure AD OAuth 2.0 token endpoint (Option C) with the managed identity token endpoint, not realizing that managed identities use a special internal endpoint (IMDS) that does not require tenant ID or client credentials.

How to eliminate wrong answers

Option A is wrong because https://{function-app}.azurewebsites.net/.auth/login is the App Service Authentication (EasyAuth) login endpoint, which is used to authenticate users (not the function app itself) and does not issue tokens for downstream APIs via managed identity. Option B is wrong because https://{downstream-api}.azurewebsites.net/.auth/me is an endpoint that returns claims about the currently authenticated user (or app) to the downstream API, but it is not a token endpoint that the function app can call to obtain a token. Option C is wrong because https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token is the standard OAuth 2.0 token endpoint for Azure AD applications that require a client secret or certificate; managed identities do not use this endpoint because they have no secrets to present.

Full explanation →

402

MCQeasy

You need to store millions of small JSON documents (each ~1 KB) that are frequently updated by multiple concurrent users. You require low-latency access to individual documents. Which Azure Storage solution should you use?

A.Azure Blob Storage with Block blobs

B.Azure Table Storage

C.Azure Files with SMB protocol

D.Azure Cosmos DB for NoSQL

AnswerB

Azure Table Storage is a highly scalable and cost-effective NoSQL key-value store specifically designed for storing massive quantities of structured, non-relational data. It excels at handling millions of small entities, like 1KB JSON documents, by leveraging PartitionKey and RowKey for efficient lookups and queries. Its design prioritizes low-cost storage and high throughput for simple data models, making it ideal for this scenario where cost-efficiency and scale for small documents are paramount.

Why this answer

Azure Table Storage is a NoSQL key-value store optimized for storing large volumes of structured, non-relational data with low-latency access by partition key and row key. It supports millions of small JSON documents (~1 KB) and handles frequent concurrent updates via optimistic concurrency control using ETags, making it ideal for this scenario.

Exam trap

The trap here is that candidates often choose Azure Cosmos DB for NoSQL because it is a more feature-rich document database, but the question emphasizes cost-effectiveness and simplicity for high-volume, low-latency key-value access, which is exactly where Azure Table Storage excels.

How to eliminate wrong answers

Option A is wrong because Azure Blob Storage with Block blobs is designed for large, unstructured binary or text objects (up to ~4.7 TB per blob) and does not provide native key-value lookup for individual small documents; it also lacks built-in optimistic concurrency for frequent updates by multiple users. Option C is wrong because Azure Files with SMB protocol provides file-level access with network shares, not a document store; it introduces protocol overhead and is not optimized for low-latency access to millions of individual small JSON documents. Option D is wrong because Azure Cosmos DB for NoSQL, while capable of storing JSON documents, is a premium, globally distributed database service with higher cost and complexity; for this specific requirement of millions of small, frequently updated documents with low-latency access, Azure Table Storage is the more cost-effective and purpose-built solution.

Full explanation →

403

MCQmedium

Refer to the exhibit. You have an HTTP-triggered Azure Function that writes the request body to a blob in the 'samples-workitems' container. The function runs successfully but does not create a blob. What is the most likely cause?

A.The container name 'samples-workitems' is invalid

B.The blob name pattern {rand-guid} is not supported

C.The storage account connection string is not set in the function app settings

D.The blob output binding syntax is incorrect

AnswerC

Azure Functions bindings, particularly for external services like Blob Storage, critically depend on a configured connection string to authenticate and authorize access. This connection string, often referenced by a setting like `AzureWebJobsStorage` or a custom name specified in the binding's `connection` property, must be present in the Function App's application settings. Without this essential configuration, the Azure Functions runtime cannot establish a connection to the specified storage account, leading to binding failures.

Why this answer

The most likely cause is that the storage account connection string is not set in the function app settings. Azure Functions require the connection string for the storage account to be configured via the `AzureWebJobsStorage` app setting (or a custom connection setting referenced in the binding). Without it, the runtime cannot authenticate or communicate with Blob Storage, so the output binding silently fails to write the blob, even though the function executes successfully.

Exam trap

The trap here is that candidates assume the function code itself must be wrong (e.g., invalid container name or binding syntax) when the issue is a missing configuration setting that the Azure Functions runtime requires to connect to storage.

How to eliminate wrong answers

Option A is wrong because 'samples-workitems' is a valid container name; Azure Blob Storage allows lowercase letters, numbers, and hyphens, and this name follows those rules. Option B is wrong because the `{rand-guid}` pattern is a supported binding expression in Azure Functions that generates a random GUID for the blob name. Option D is wrong because the binding syntax shown (using `direction`, `type`, `name`, `path`, and `connection`) is correct for a blob output binding in a function.json file.

Full explanation →

404

MCQhard

You are developing an application that writes blobs to Azure Blob Storage. The application requires high throughput and must handle transient failures. You need to implement a retry policy. Which approach should you use?

A.Use a circuit breaker pattern

B.Implement a custom retry loop with Thread.Sleep

C.Generate a SAS token with a long expiry

D.Configure the retry policy in the Azure.Storage.Blobs SDK

AnswerD

Configuring the retry policy within the Azure.Storage.Blobs SDK is the recommended and most robust approach for handling transient faults during blob write operations. The SDK's built-in retry mechanisms automatically implement best practices like exponential backoff with jitter, which intelligently increases the delay between retries and adds randomness to prevent simultaneous retries from multiple clients. This approach significantly improves application resilience and reliability by gracefully recovering from temporary service interruptions without complex custom code.

Why this answer

The Azure.Storage.Blobs SDK provides built-in retry policies (e.g., ExponentialRetry, FixedRetry) that handle transient failures automatically with configurable delays, retry counts, and backoff strategies. This is the recommended approach because it integrates directly with the SDK's client pipeline, respects service throttling, and avoids blocking threads or reinventing error handling logic.

Exam trap

The trap here is that candidates confuse the circuit breaker pattern (a resilience pattern for preventing cascading failures) with a retry policy, or they incorrectly assume that a custom Thread.Sleep loop is acceptable in modern asynchronous Azure SDK applications.

How to eliminate wrong answers

Option A is wrong because the circuit breaker pattern is designed to prevent repeated calls to a failing service by opening the circuit, not to handle transient failures with retries; it is a complementary pattern, not a retry policy. Option B is wrong because Thread.Sleep blocks the current thread synchronously, which reduces throughput and scalability in an asynchronous application; it also lacks exponential backoff and integration with Azure SDK retry logic. Option C is wrong because a SAS token with a long expiry addresses authentication and access duration, not transient failure handling; retry policies are independent of token expiry.

Full explanation →

405

MCQeasy

You need to diagnose why an Azure App Service web app returns HTTP 503 errors during peak traffic. Which Application Insights feature should you use?

A.Availability tests

B.Log Analytics query for failed requests

C.Application Map

D.Live Metrics

AnswerD

Live Metrics Stream, part of Application Insights, provides a real-time, near-instantaneous view of your application's performance and health directly from the running application instance. It streams key metrics like requests, failures, CPU usage, memory, and custom events with minimal latency. This capability is essential for diagnosing why a web app is returning errors right now, allowing developers to observe active issues, trace individual requests, and identify performance anomalies as they occur.

Why this answer

Live Metrics (D) is the correct choice because it provides real-time monitoring of server-side performance metrics, including HTTP 503 errors, as they occur during peak traffic. This allows you to immediately correlate the errors with spikes in CPU, memory, or request rates, enabling rapid diagnosis of resource exhaustion or throttling issues in the App Service plan.

Exam trap

The trap here is that candidates often choose Log Analytics queries (B) because they associate 'failed requests' with error diagnosis, but they overlook that Live Metrics provides the only real-time view necessary to diagnose transient 503 errors during active peak traffic.

How to eliminate wrong answers

Option A is wrong because Availability tests are designed to proactively monitor the uptime and responsiveness of your web app from external locations, not to diagnose the cause of 503 errors during live traffic. Option B is wrong because Log Analytics queries for failed requests are historical and require data to be ingested and indexed, which introduces latency; they cannot provide the real-time diagnostics needed during an ongoing peak traffic event. Option C is wrong because Application Map visualizes the distributed topology and dependencies of your application, but it does not offer real-time performance counters or live error rates needed to pinpoint the immediate cause of 503 errors.

Full explanation →

406

MCQmedium

You are deploying an Azure Functions app that processes messages from an Azure Storage queue. The function must ensure that each message is processed at least once, and if processing fails, the message should be retried up to 5 times before being moved to a poison queue. Which configuration should you set?

A.Set the maxDequeueCount property in the host.json for the queue trigger to 5.

B.Manually implement a retry loop in the function code.

C.Set the visibility timeout to 5 minutes in the queue.

D.Set the message time-to-live to 5 in the queue.

AnswerA

The `maxDequeueCount` property, configured within the `host.json` file for a queue trigger, directly controls the maximum number of times an Azure Function will attempt to process a specific queue message. If the function fails to successfully process the message (e.g., due to an unhandled exception) after this many attempts, the message is automatically moved to a designated poison queue. Setting this to 5 ensures the function will retry processing the message up to five times before it is considered unprocessable and moved for further investigation.

Why this answer

The Azure Storage queue trigger's `maxDequeueCount` property in `host.json` controls the maximum number of times a message is dequeued for processing before it is moved to the poison queue. Setting it to 5 ensures that after 5 failed processing attempts, the message is automatically moved to the poison queue, satisfying the at-least-once processing and retry requirements without custom code.

Exam trap

The trap here is that candidates often confuse the `maxDequeueCount` property with other queue settings like visibility timeout or TTL, mistakenly thinking those control retry behavior, when in fact only `maxDequeueCount` governs the number of retries before poison queue escalation.

How to eliminate wrong answers

Option B is wrong because manually implementing a retry loop in the function code is unnecessary and error-prone; the Azure Functions runtime already provides built-in retry logic via the `maxDequeueCount` property, and manual loops can lead to infinite retries or improper poison message handling. Option C is wrong because setting the visibility timeout to 5 minutes only controls how long a message remains invisible after being dequeued, not the number of retry attempts; it does not limit retries or move messages to a poison queue. Option D is wrong because setting the message time-to-live (TTL) to 5 (likely meaning 5 seconds or 5 minutes) controls how long a message stays in the queue before expiring, not the retry count; expired messages are simply deleted, not moved to a poison queue.

Full explanation →

407

Multi-Selectmedium

You are planning to migrate an on-premises application to Azure App Service. The application consists of a web frontend and a background worker that processes messages from a queue. Which TWO Azure services should you use to implement this solution?

Select 2 answers

A.Azure Kubernetes Service

B.Azure Batch

C.Azure Functions

D.Azure App Service

E.Azure Logic Apps

AnswersC, D

Azure Functions is a serverless compute service that allows you to run event-driven code without provisioning or managing infrastructure. It is an excellent choice for a background worker processing queue messages, as it can be directly triggered by new messages in an Azure Storage Queue or Service Bus Queue. This enables automatic scaling and cost-efficiency, as you only pay for the compute resources consumed when your function is actively processing messages.

Why this answer

Azure Functions (C) is correct because it provides a serverless compute service that can be triggered by queue messages, making it ideal for the background worker that processes messages from a queue. Azure App Service (D) is correct because it hosts the web frontend, providing a fully managed platform for web applications with built-in scaling and load balancing.

Exam trap

The trap here is that candidates often confuse Azure Functions with Azure Logic Apps, but Logic Apps is a workflow orchestration service (not a compute service) and cannot run arbitrary code like a background worker processing queue messages.

Full explanation →

408

MCQeasy

Contoso is building a serverless application using Azure Functions. One function needs to read messages from an Azure Event Hub and store them in Azure Blob Storage. The function uses the Event Hubs trigger. The team wants to authenticate to both Event Hubs and Blob Storage using managed identities. The Function app has system-assigned managed identity enabled. Which role assignments are required on the Event Hubs namespace and the storage account?

A.Assign the 'Azure Event Hubs Data Sender' role and 'Storage Blob Data Reader' role.

B.Assign the 'Azure Event Hubs Data Reader' role (which does not exist) and 'Storage Blob Data Contributor' role.

C.Assign the 'Azure Event Hubs Data Receiver' role to the managed identity on the Event Hubs namespace. Assign the 'Storage Blob Data Contributor' role to the managed identity on the storage account.

D.Assign the 'Azure Event Hubs Data Owner' role and 'Storage Blob Data Owner' role.

AnswerC

This option correctly assigns the necessary permissions for a serverless application to consume events from Event Hubs and interact with blob storage. The 'Azure Event Hubs Data Receiver' role grants the managed identity the specific authorization to read and process messages from an Event Hub. Simultaneously, the 'Storage Blob Data Contributor' role provides comprehensive access to read, write, and delete blobs, which is essential for tasks such as managing Event Hub consumer group checkpoints or storing processed data outputs within an Azure Storage Account, adhering to the principle of least privilege.

Why this answer

The function uses an Event Hubs trigger, which requires the 'Azure Event Hubs Data Receiver' role to read messages from the Event Hubs namespace. To write data to Azure Blob Storage, the 'Storage Blob Data Contributor' role is needed on the storage account. Both roles are assigned to the function app's system-assigned managed identity, enabling secure, keyless authentication.

Exam trap

The trap here is that candidates confuse the 'Data Sender' role (for output bindings) with the 'Data Receiver' role (for triggers), or assume a generic 'Reader' role exists for Event Hubs, leading them to pick options with invalid or mismatched roles.

How to eliminate wrong answers

Option A is wrong because it assigns the 'Azure Event Hubs Data Sender' role, which is for sending events, not receiving them; the trigger needs the 'Data Receiver' role. It also assigns 'Storage Blob Data Reader', which only allows reading blobs, not writing them. Option B is wrong because 'Azure Event Hubs Data Reader' is not a valid Azure RBAC role; the correct role for receiving is 'Azure Event Hubs Data Receiver'.

Option D is wrong because it assigns overly permissive 'Owner' roles on both resources, violating the principle of least privilege; the function only needs receiver and contributor permissions, not full ownership.

Full explanation →

409

MCQhard

You deploy a microservices application to Azure Kubernetes Service (AKS). The application uses Azure Cache for Redis to store session state. Users report that they are frequently logged out. You suspect that the session data is being evicted from the cache. Which configuration change should you make to reduce evictions?

A.Enable clustering for the cache

B.Enable data persistence using RDB or AOF

C.Increase the maxmemory-reserved setting or change eviction policy

D.Upgrade to a higher-tier Azure Cache for Redis

AnswerC

Increasing reserved memory or using a more suitable eviction policy reduces evictions.

Why this answer

Increasing the `maxmemory-reserved` setting allocates more memory exclusively for non-cache operations (like replication buffers), reducing the chance that session data is evicted under memory pressure. Alternatively, changing the eviction policy to `allkeys-lru` or `volatile-lru` can prioritize keeping recently used keys, which helps retain active session state. Both adjustments directly address the symptom of frequent evictions causing session loss.

Exam trap

The trap here is that candidates often assume the only way to reduce evictions is to add more memory (Option D), when in fact adjusting memory reservation or eviction policy (Option C) can resolve the issue without incurring additional cost, and persistence (Option B) is mistakenly thought to prevent evictions when it only protects against data loss on restart.

How to eliminate wrong answers

Option A is wrong because enabling clustering partitions data across multiple shards, which improves throughput and scalability but does not reduce evictions within a shard; evictions still occur if a shard's memory limit is reached. Option B is wrong because data persistence (RDB snapshots or AOF logs) ensures data survives restarts but does not prevent evictions during runtime; evictions are a memory-management mechanism triggered when the `maxmemory` limit is hit, regardless of persistence settings. Option D is wrong because upgrading to a higher-tier cache increases total memory capacity, which can reduce evictions, but it is a more costly and indirect solution compared to tuning the existing cache's memory reservation or eviction policy, which directly addresses the root cause of memory pressure.

Full explanation →

410

MCQmedium

A developer is implementing Key Vault certificate retrieval. The application runs on Azure App Service and must avoid stored credentials. Which design should be used? The design must avoid adding custom operational scripts.

A.Use a shared administrator account

B.Store a client secret in source control

C.Enable managed identity and grant least-privilege access to the target resource

D.Disable authentication for the target resource

AnswerC

Managed identity lets Azure-hosted apps authenticate without stored secrets.

Why this answer

Managed identity (system-assigned or user-assigned) allows the App Service to authenticate to Key Vault without any stored credentials, because Azure automatically rotates the identity's service principal and provides an access token via the Azure Instance Metadata Service (IMDS) endpoint. By granting least-privilege access (e.g., a Key Vault access policy with only 'Get' on secrets), the design meets the requirement to avoid stored credentials and custom operational scripts.

Exam trap

The trap here is that candidates may think storing a client secret in Azure App Service application settings (Option B) is acceptable because it's not in source control, but the question explicitly requires avoiding stored credentials entirely, and managed identity is the only zero-credential solution.

How to eliminate wrong answers

Option A is wrong because using a shared administrator account requires storing credentials (username/password or certificate) in the application configuration or code, violating the 'avoid stored credentials' requirement. Option B is wrong because storing a client secret in source control is a security anti-pattern that exposes credentials in the codebase, and it still requires manual secret rotation and management. Option D is wrong because disabling authentication for the target resource (Key Vault) would allow anonymous access, which is a severe security vulnerability and contradicts the principle of least privilege.

Full explanation →

411

Multi-Selecteasy

Which TWO Azure services can be used to implement serverless event-driven architectures?

Select 2 answers

A.Azure Batch

B.Azure Logic Apps

C.Azure Functions

D.Azure Container Instances

E.Azure Virtual Machines

AnswersB, C

Azure Logic Apps provide a serverless platform for building automated workflows that integrate applications, data, services, and systems. They operate on a consumption-based billing model, where you only pay for executed actions, and automatically scale based on demand without requiring any server or infrastructure management. Logic Apps are inherently event-driven, triggered by various connectors, making them a prime example of serverless orchestration.

Why this answer

Azure Logic Apps is correct because it provides a fully managed integration platform for orchestrating workflows that respond to events from various sources, such as HTTP requests, Azure services, or third-party apps, using a visual designer and connectors. Azure Functions is correct because it offers event-driven compute capabilities where code executes in response to triggers like HTTP requests, queue messages, or timer events, enabling serverless architectures without managing infrastructure.

Exam trap

The trap here is that candidates often confuse Azure Batch or Azure Container Instances as serverless event-driven services because they are 'serverless' in some sense, but they lack the native event-triggering and orchestration capabilities that define serverless event-driven architectures.

Full explanation →

412

MCQmedium

A company uses Azure Logic Apps to integrate with a third-party SaaS application. The Logic App must send an HTTP request to the SaaS API and handle pagination. Which connector should be used?

A.API Connection

B.HTTP + Swagger

C.HTTP

D.HTTP Webhook

AnswerC

The HTTP connector provides unparalleled control over every aspect of an HTTP request and response, including methods, URLs, headers, query parameters, and body content. This granular control is essential for implementing custom pagination logic, as it allows the Logic App to dynamically construct subsequent requests, extract next page tokens or offsets from responses, and manage iterative calls within a loop until all data pages are retrieved from the third-party API.

Why this answer

The HTTP connector is the correct choice because it allows the Logic App to send a raw HTTP request to any REST API and handle pagination manually by inspecting response headers (e.g., 'nextLink') or body properties. Unlike other connectors, it provides full control over request/response cycles, enabling custom pagination logic without relying on a predefined API schema.

Exam trap

The trap here is that candidates often confuse the HTTP + Swagger connector with the plain HTTP connector, assuming Swagger is required for any API interaction, but the HTTP connector is sufficient and more flexible for custom pagination without a predefined schema.

How to eliminate wrong answers

Option A is wrong because API Connection is a generic term for a managed connector that requires a pre-built API definition or a custom connector, not a direct HTTP request for handling pagination. Option B is wrong because HTTP + Swagger is used when the API exposes a Swagger/OpenAPI definition to generate a custom connector, but it does not inherently handle pagination logic better than the plain HTTP connector. Option D is wrong because HTTP Webhook is designed for asynchronous callback patterns (e.g., subscribing to events), not for synchronous request-response pagination.

Full explanation →

413

MCQeasy

A developer needs to deploy a web app that uses Azure SQL Database. They want to connect to the database using a connection string without storing it in code. Which feature of Azure App Service should they use?

A.Key Vault references

B.Environment variables

C.Application settings

D.Azure App Configuration

AnswerA

Key Vault references are a feature of Azure App Service that allow referencing secrets from Azure Key Vault. While they can be used for connection strings, they require additional setup and are not the simplest built-in feature for this purpose.

Why this answer

Key Vault references in Azure App Service allow the web app to securely retrieve secrets, such as connection strings, from Azure Key Vault. This is considered a best practice for managing sensitive information, as Key Vault provides centralized secret management, access control, auditing, and secret rotation capabilities. The App Service can resolve these references at runtime, injecting the secret into the application as an environment variable without storing it directly in the App Service configuration or code.

Option C (Application settings) can store connection strings and are encrypted at rest, but Key Vault offers superior security and management features specifically for secrets. Option B (Environment variables) are not a persistent or managed solution for configuration in App Service. Option D (Azure App Configuration) is a centralized configuration service, but Key Vault is specifically designed for secrets and is more directly integrated for this purpose with App Service via references.

Full explanation →

414

MCQmedium

You are deploying a containerized application to Azure Container Instances. The application must restart automatically if it crashes. You set the restart policy to 'Always'. However, the container keeps restarting continuously even when there is no crash. What is the most likely cause?

A.The container is configured with an Azure Files volume that is not accessible.

B.The application inside the container exits with a non-zero exit code on startup.

C.The container is trying to bind to a port that is already in use on the host.

D.The container is exceeding the allocated CPU or memory limits.

AnswerB

Container orchestrators, such as Azure Container Instances (ACI), are designed to monitor the primary process running within a container. When this process exits with a non-zero status code, it signals an abnormal termination or a critical failure within the application. ACI's default restart policies (like 'Always' or 'OnFailure') will then automatically attempt to restart the container. If the application consistently fails and exits immediately upon startup with a non-zero code, this creates a continuous restart loop, as the orchestrator repeatedly tries to bring up a failing container.

Why this answer

The 'Always' restart policy in Azure Container Instances restarts the container whenever it stops, regardless of the exit code. If the application exits with a non-zero exit code on startup (e.g., due to a configuration error or missing dependency), the container will stop immediately, triggering an infinite restart loop. This is the most likely cause because the container is not crashing due to external factors but rather failing during its initialization phase.

Exam trap

The trap here is that candidates often confuse 'Always' with 'OnFailure' — 'Always' restarts on any exit, including non-zero exit codes on startup, while 'OnFailure' only restarts on non-zero exit codes, making the continuous restart loop a symptom of an application that fails immediately with a non-zero exit code.

How to eliminate wrong answers

Option A is wrong because an inaccessible Azure Files volume would cause the container to fail at mount time, but the restart policy would still apply; however, the container would not restart continuously unless the application itself exits with a non-zero code after the mount failure. Option C is wrong because port binding conflicts on the host are not a direct concern in Azure Container Instances, as each container instance gets its own isolated network namespace and port mapping is handled by the platform. Option D is wrong because exceeding CPU or memory limits would cause the container to be throttled or killed by the Azure Container Instances orchestrator, but the restart policy would then restart it; however, the continuous restart loop described is more characteristic of an application that exits immediately on startup rather than resource exhaustion, which typically results in a single termination followed by a restart.

Full explanation →

415

MCQhard

You are deploying a containerized application on Azure Container Instances (ACI) that needs to run as a background job every hour. The job processes data from an Azure SQL Database and sends a report via email. You need to minimize costs while ensuring the job runs reliably on schedule. The job takes about 10 minutes to complete. What should you do?

A.Use Azure Batch with a job schedule to run the container as a task.

B.Create an Azure Logic App with a recurrence trigger that starts the container group using the 'Start Container Group' action, and stop it after completion.

C.Deploy the container on a single Azure virtual machine and schedule it using Windows Task Scheduler.

D.Use an Azure Function with a timer trigger that uses the Azure Container Instances SDK to start the container group.

AnswerB

This solution effectively leverages Azure Logic Apps' serverless workflow capabilities to precisely manage the lifecycle of an Azure Container Instance (ACI) container group. A recurrence trigger initiates the workflow on a defined schedule, and the dedicated 'Start Container Group' and 'Stop Container Group' actions ensure the container is provisioned and de-provisioned only for the duration of the task, significantly minimizing operational costs for intermittent workloads.

Why this answer

It uses Azure Logic Apps with a recurrence trigger to start the container group only when needed, and stops it after the job completes. This minimizes costs by avoiding continuous running charges for the container, while the Logic App itself incurs minimal execution cost. The job's 10-minute duration fits well within the 1-hour recurrence window, ensuring reliable scheduling without idle compute time.

Exam trap

The trap here is that candidates may assume an Azure Function with a timer trigger is the cheapest option, but they overlook the Function's execution timeout limits and the need to manage container lifecycle, making Logic Apps the more reliable and cost-effective choice for this specific scenario.

How to eliminate wrong answers

Option A is wrong because Azure Batch is designed for large-scale parallel batch processing across multiple nodes, which is overkill and more expensive for a single container running a 10-minute job every hour. Option C is wrong because deploying a dedicated Azure VM incurs continuous compute costs even when the job is not running, and Windows Task Scheduler does not natively manage container lifecycle or provide the same reliability as Azure-native scheduling. Option D is wrong because an Azure Function with a timer trigger using the ACI SDK to start the container group would still require the container to run continuously or incur additional complexity for stopping it, and the Function's execution time limit (default 5 minutes, max 10 minutes) may not reliably accommodate the job's 10-minute duration without premium plans.

Full explanation →

416

MCQmedium

You are building an Azure Logic App that must call a third-party REST API secured with OAuth 2.0 Client Credentials flow. The client ID and client secret are stored in Azure Key Vault. You need to securely obtain an access token and include it in requests to the API. Which approach should you use in the Logic App?

A.Use the HTTP action with 'Active Directory OAuth' authentication and hardcode the client secret in the connection parameters.

B.Create an Azure API connection (custom connector) with the OAuth 2.0 settings and store the secret in the connector's definition.

C.Enable a system-assigned managed identity for the Logic App, grant it access to Key Vault, use the 'Get secret' action to retrieve the client secret into a variable, then use the HTTP action with 'Active Directory OAuth' authentication referencing that variable for the secret.

D.Store the client secret in an Azure App Service application setting and reference it in the Logic App via a connector.

AnswerC

This approach uses managed identity to securely access Key Vault, and the secret is passed at runtime without being exposed in the workflow definition. The HTTP action's OAuth authentication can use a variable for the client secret.

Why this answer

It securely retrieves the client secret from Azure Key Vault at runtime using a managed identity, avoiding any hardcoded secrets. The Logic App's system-assigned managed identity is granted access to Key Vault, then the 'Get secret' action fetches the secret into a variable, which is passed to the HTTP action's 'Active Directory OAuth' authentication. This approach follows the principle of least privilege and eliminates secret exposure in connection definitions or source code.

Exam trap

The trap here is that candidates may think a custom connector (Option B) is the correct way to handle OAuth 2.0, but they overlook that storing the secret in the connector definition is not secure and that managed identities with Key Vault provide a more robust and auditable solution.

How to eliminate wrong answers

Option A is wrong because hardcoding the client secret in the HTTP action's connection parameters violates security best practices and exposes the secret in the Logic App's definition and runtime history. Option B is wrong because storing the secret in the custom connector's definition embeds it in the connector metadata, which is not secure and cannot be dynamically rotated without redeploying the connector. Option D is wrong because Azure App Service application settings are not designed for Logic Apps (they are for App Service apps) and referencing them via a connector still exposes the secret in the Logic App's configuration, lacking the secure retrieval and dynamic secret management that Key Vault provides.

Full explanation →

417

MCQmedium

You are building a serverless workflow using Azure Logic Apps. The workflow must start when a new blob is uploaded to a specific container in Azure Blob Storage. Which trigger should you configure?

A.When a blob is created or modified (blob trigger)

B.HTTP request trigger

C.Recurrence trigger

D.Service Bus trigger

AnswerA

The "When a blob is created or modified" trigger is purpose-built for integrating Logic Apps with Azure Blob Storage. It actively monitors a specified storage account and container, automatically initiating the workflow whenever a new blob is uploaded or an existing blob's content is updated. This direct, event-driven integration makes it the ideal and most efficient choice for processing changes within blob storage.

Why this answer

The 'When a blob is created or modified (blob trigger)' is the native Azure Logic Apps trigger designed to start a workflow automatically when a new blob is uploaded or an existing blob is modified in a specified Azure Blob Storage container. This trigger uses the Azure Blob Storage event subscription to detect changes and is the appropriate choice for event-driven serverless workflows that respond to blob storage events.

Exam trap

The trap here is that candidates often confuse the Blob Storage trigger with the HTTP trigger, thinking they can manually invoke the workflow via a URL, but the question specifically requires an event-driven start from a blob upload, which only the blob trigger supports.

How to eliminate wrong answers

Option B is wrong because the HTTP request trigger is used to start a workflow when an external HTTP request is received, not when a blob is uploaded to Blob Storage. Option C is wrong because the Recurrence trigger runs the workflow on a fixed schedule (e.g., every hour) and does not respond to real-time blob upload events. Option D is wrong because the Service Bus trigger is designed to start a workflow when a message is received from an Azure Service Bus queue or topic, not from Blob Storage.

Full explanation →

418

MCQmedium

Your company is building a real-time dashboard that displays sales data from multiple stores. The data is generated as events from point-of-sale systems and must be ingested with low latency. The dashboard needs to display aggregated data (e.g., total sales per store per minute) with a maximum delay of 5 seconds from event generation. You have decided to use Azure Event Hubs for ingestion and Azure Stream Analytics for real-time processing. The processed data will be stored in Azure Cosmos DB for the dashboard to query. However, the dashboard requires that the data in Cosmos DB be updated as soon as new aggregations are available. You need to design the output from Azure Stream Analytics to Cosmos DB. Which output configuration should you use?

A.Configure the output to use Cosmos DB MongoDB API and use a unique index on store ID and timestamp.

B.Output to Azure Cosmos DB Table API with a partition key of store ID.

C.Write the output to Azure Blob Storage and use an Azure Function triggered by blob creation to update Cosmos DB.

D.Configure the output to use Cosmos DB SQL API with the document ID set to a concatenation of store ID and minute timestamp, and enable upsert.

AnswerD

Configuring the output to use Azure Cosmos DB SQL API with a document ID concatenated from the store ID and minute timestamp, combined with enabling upsert, is the most efficient solution. This approach allows for direct, low-latency updates or insertions of specific minute-level data for each store, leveraging the SQL API's native document model and optimized upsert functionality for real-time data processing.

Why this answer

It uses the Cosmos DB SQL API with a document ID that uniquely identifies each aggregation (store ID + minute timestamp), and enables upsert. This ensures that when Stream Analytics emits a new aggregation for the same store and minute, it overwrites the existing document, providing low-latency updates to the dashboard. The SQL API supports native upsert semantics, which is the most direct and efficient way to achieve real-time updates without additional services or complex logic.

Exam trap

The trap here is that candidates may think any Cosmos DB API works the same way, but only the SQL API (and Table API with specific row key design) supports native upsert from Stream Analytics, and the MongoDB API does not have a direct output adapter in Stream Analytics.

How to eliminate wrong answers

Option A is wrong because the MongoDB API does not support native upsert from Azure Stream Analytics; Stream Analytics outputs to Cosmos DB only support the SQL API and Table API, and using a unique index alone does not enable automatic document replacement. Option B is wrong because the Table API uses a different data model (key-value with partition key and row key) and does not support the document-level upsert with a composite ID needed for per-minute aggregations; it also lacks the SQL query capabilities the dashboard may require. Option C is wrong because writing to Blob Storage and triggering an Azure Function introduces additional latency and complexity, violating the 5-second maximum delay requirement; it also adds a dependency on an intermediate service that can fail or throttle.

Full explanation →

419

MCQmedium

You are investigating a slow API call in your Azure web app. Application Insights shows that the request took 10 seconds. You need to view all the dependencies (database calls, external HTTP requests) that contributed to this request. What should you use?

A.Application Map

B.Live Metrics

C.Transaction Search

D.Usage Analysis

AnswerC

Transaction Search in Application Insights is the ideal tool for investigating a specific slow API call because it allows you to locate individual requests using criteria like request ID, URL, or duration. Once identified, it provides a comprehensive end-to-end transaction trace, detailing all operations, dependencies (like database calls or external HTTP requests), and their respective durations within that single request. This granular view is crucial for pinpointing the exact bottleneck responsible for the slowness.

Why this answer

Transaction Search (now part of the 'Search' experience in Application Insights) allows you to query individual requests and drill into their correlated dependency calls, such as SQL queries or external HTTP requests, showing the exact duration and sequence of each dependency. This is the correct tool to identify which specific dependencies contributed to the 10-second request latency.

Exam trap

The trap here is that candidates often confuse Application Map (a high-level topology view) with the detailed dependency drill-down available in Transaction Search, leading them to choose A when they need to see the specific calls and timings for a single request.

How to eliminate wrong answers

Option A is wrong because Application Map provides a topological view of your application's components and their health, but it does not show the detailed dependency call list or timing for a specific request. Option B is wrong because Live Metrics shows real-time performance data (e.g., request rate, failure count) but does not allow you to inspect historical dependency details for a past slow request. Option D is wrong because Usage Analysis focuses on user behavior metrics (e.g., page views, sessions) and is not designed for diagnosing dependency-level performance issues.

Full explanation →

420

MCQmedium

You are troubleshooting an Azure App Service that runs a Node.js application. The application returns HTTP 500 errors intermittently. Application Insights is configured. Which telemetry item should you examine first to find the root cause?

A.Exceptions

B.Traces

C.Dependencies

D.Requests

AnswerA

When troubleshooting an application crash or unexpected behavior, Exceptions telemetry in Application Insights is the most direct and comprehensive data type. It automatically collects unhandled exceptions, including stack traces, exception types, messages, and associated request context, which are crucial for pinpointing the exact line of code or component causing the issue in an Azure App Service. This detailed information is invaluable for debugging and understanding the root cause of application failures.

Why this answer

HTTP 500 errors indicate server-side failures, and Application Insights captures these as Exception telemetry when an unhandled exception occurs in the Node.js runtime. Examining the Exception telemetry first allows you to see the stack trace, error message, and call details, which directly point to the root cause of the intermittent failures.

Exam trap

The trap here is that candidates often pick 'Requests' because they see the 500 status code, but they forget that request telemetry only shows the outcome, not the underlying exception details needed for root cause analysis.

How to eliminate wrong answers

Option B (Traces) is wrong because traces are custom log messages (e.g., console.log or app insights trackTrace) and do not automatically capture unhandled exceptions that cause HTTP 500 errors. Option C (Dependencies) is wrong because dependency telemetry tracks outbound calls (e.g., to databases or APIs) and may show failures, but it does not directly reveal the server-side exception that triggered the 500 response. Option D (Requests) is wrong because request telemetry records the incoming HTTP request and its result code (500), but it does not include the exception details or stack trace needed to diagnose the intermittent failure.

Full explanation →

421

MCQeasy

You need to restrict access to an Azure web app so that only traffic from a specific virtual network (VNet) can reach it. The web app is already deployed. What should you configure on the web app?

A.VNet integration

B.Access restrictions

C.Network Security Group (NSG) on the subnet

D.Point-to-Site VPN

AnswerB

Access restrictions are a native feature of Azure App Service designed specifically to control inbound network traffic to a web app. They allow administrators to define a set of allow/deny rules based on IP addresses (IPv4/IPv6 CIDR blocks) or by leveraging Virtual Network service endpoints to restrict access to specific subnets within an Azure VNet. This directly addresses the need to deny all traffic except from a particular source.

Why this answer

Access restrictions (also known as IP restrictions) allow you to define allow/deny rules based on source IP addresses or Virtual Network (VNet) service endpoints. By configuring a service endpoint-based rule that permits traffic only from your specific VNet, you can block all other inbound traffic to the web app. This is the correct mechanism for restricting access at the web app level without modifying the underlying infrastructure.

Exam trap

The trap here is confusing VNet integration (outbound) with access restrictions (inbound), leading candidates to select VNet integration when the question asks about restricting incoming traffic from a VNet.

How to eliminate wrong answers

Option A is wrong because VNet integration enables the web app to access resources inside a VNet (outbound connectivity), not to restrict inbound traffic from that VNet. Option C is wrong because an NSG on the subnet controls traffic to and from resources within that subnet, but it cannot directly filter traffic to an Azure App Service, which is a PaaS service not hosted in your VNet. Option D is wrong because Point-to-Site VPN is used for individual client machines to connect to a VNet, not for restricting inbound access to a web app from an entire VNet.

Full explanation →

422

MCQmedium

Your company has an application running on Azure Virtual Machines that needs to access secrets in Azure Key Vault. You want to restrict network access to the Key Vault so that only the virtual network/subnet containing the VMs can reach it. You also want to ensure that the solution works with the least management overhead. Which configuration should you use?

A.Configure Key Vault firewall with IP-based rules that allow the VM's public IP address.

B.Configure a Private Endpoint for the Key Vault in the same virtual network as the VMs.

C.Configure Key Vault firewall to allow access from the virtual network and subnet using service endpoints.

D.Use a shared access signature (SAS) to access Key Vault secrets.

AnswerC

Configuring Key Vault firewall to allow access from a specific virtual network and subnet using service endpoints is the most appropriate and secure solution for this scenario. Service endpoints extend the virtual network's identity to the Azure Key Vault service, allowing traffic to flow directly over the Azure backbone network rather than the public internet. This approach is straightforward to implement, ensuring that only resources within the designated subnet can access the Key Vault, thus providing robust network isolation.

Why this answer

Configuring Key Vault firewall with virtual network service endpoints allows you to restrict access to the Key Vault to a specific virtual network and subnet without exposing the VMs to the internet. This approach leverages Azure's backbone network for traffic, providing secure and direct connectivity with minimal management overhead, as service endpoints are automatically maintained by Azure.

Exam trap

The trap here is that candidates often confuse Private Endpoints with service endpoints, assuming Private Endpoints are always the best choice for network isolation, but service endpoints are simpler and have less management overhead when you only need to restrict access to a specific virtual network/subnet without requiring private IP connectivity.

How to eliminate wrong answers

Option A is wrong because using IP-based rules with the VM's public IP address exposes the VM to the internet and requires managing public IP changes, increasing management overhead and security risk. Option B is wrong because a Private Endpoint uses a private IP from the virtual network, which is more complex to set up and manage than service endpoints for this scenario, and it incurs additional costs for the private endpoint resource. Option D is wrong because shared access signatures (SAS) are used for granting delegated access to Azure Storage resources, not for accessing Key Vault secrets; Key Vault uses Azure AD authentication and access policies.

Full explanation →

423

MCQeasy

Your company uses Azure Key Vault to store secrets. You need to ensure that if a secret is deleted, it can be recovered within 30 days. Which Key Vault feature should you enable?

A.Soft-delete

B.Purge protection

C.RBAC (Role-Based Access Control)

D.Access policies

AnswerA

Soft-delete is the essential feature for recovering deleted secrets, keys, and certificates in Azure Key Vault. When enabled, it retains deleted items for a configurable retention period, typically 90 days by default, moving them to a 'soft-deleted' state. During this period, these items can be restored to their original state, preventing accidental or malicious permanent data loss and ensuring business continuity. This mechanism provides a crucial safety net for managing sensitive information within the vault.

Why this answer

Soft-delete is the correct feature because it allows you to recover a deleted secret within a configurable retention period (default 90 days, but can be set to as low as 1 day). When soft-delete is enabled, a deleted secret is marked as deleted but remains recoverable until the retention period expires. This directly meets the requirement to recover a secret within 30 days.

Exam trap

The trap here is that candidates often confuse purge protection with soft-delete, thinking that purge protection alone allows recovery, when in fact purge protection only prevents permanent deletion after soft-delete has already occurred.

How to eliminate wrong answers

Option B (Purge protection) is wrong because purge protection only prevents the permanent deletion of a soft-deleted secret until the retention period ends; it does not by itself enable recovery of a deleted secret. Option C (RBAC) is wrong because RBAC controls access permissions to Key Vault resources but has no effect on secret recovery after deletion. Option D (Access policies) is wrong because access policies define which users or applications can read, write, or delete secrets, but they do not provide any recovery capability for deleted secrets.

Full explanation →

424

MCQeasy

A company deploys a stateful application as a container in Azure Container Instances (ACI). They need persistent storage that can be shared across multiple container instances and retain data after container restarts. Which volume mount should they use?

A.emptyDir

B.Azure Files share

C.Host path

D.Secret volume

AnswerB

Azure Files share volumes provide durable, network-attached storage that persists independently of the container's lifecycle. This fully managed file share service supports SMB and NFS protocols, allowing multiple container instances or groups to concurrently read from and write to the same data. Its ability to provide shared, persistent storage that survives container restarts and can be accessed across different nodes makes it an ideal solution for stateful applications requiring high availability and data durability.

Why this answer

Azure Files shares provide fully managed SMB file shares in the cloud that can be mounted as volumes in Azure Container Instances. This allows multiple container instances to read and write to the same persistent storage concurrently, and data persists independently of container lifecycles, surviving restarts or deletions. The scenario requires shared, persistent storage across instances, which Azure Files uniquely supports among the given options.

Exam trap

The trap here is that candidates often confuse emptyDir (which is ephemeral and pod-scoped) with persistent storage, or assume host path works in ACI because it works in Kubernetes, but ACI does not expose host filesystem access.

How to eliminate wrong answers

Option A is wrong because emptyDir volumes are ephemeral and tied to a pod's lifecycle; data is lost when the container or pod is deleted, and it cannot be shared across separate container instances. Option C is wrong because host path volumes mount a directory from the underlying host node's filesystem, which is not supported in Azure Container Instances (ACI is a serverless container service without direct host node access) and would not provide shared access across multiple instances. Option D is wrong because secret volumes are used to inject sensitive data (e.g., certificates, keys) into containers as files, not for persistent or shared storage; they are read-only and ephemeral.

Full explanation →

425

MCQeasy

You need to ensure that secrets stored in Azure Key Vault are automatically rotated every 90 days. Which feature should you configure?

A.Set an access policy for the secret

B.Enable soft delete and purge protection

C.Set a secret expiration date

D.Use Key Vault secret rotation with Event Grid and Azure Functions

AnswerD

The recommended approach for automated secret rotation involves leveraging Azure Key Vault's ability to publish events to Azure Event Grid when a secret is nearing expiration or when a rotation policy is triggered. An Azure Function can then subscribe to these Event Grid events, execute custom logic to generate a new secret value, update the secret in Key Vault, and potentially update the consuming application's configuration. This event-driven architecture provides a robust and extensible solution for proactive secret management.

Why this answer

Azure Key Vault does not natively rotate secrets automatically. To achieve automatic rotation every 90 days, you must integrate Key Vault with Event Grid to detect secret expiration events and trigger an Azure Function that generates a new secret version and updates the expiration date. This pattern is the recommended solution for automated secret rotation.

Exam trap

The trap here is that candidates assume setting an expiration date (Option C) automatically triggers rotation, but Key Vault only marks the secret as expired—it does not create a new version or notify any service to rotate it.

How to eliminate wrong answers

Option A is wrong because an access policy controls who can read or manage secrets, not how or when secrets are rotated. Option B is wrong because soft delete and purge protection are data recovery features that prevent accidental or malicious deletion; they have no effect on secret lifecycle or rotation scheduling. Option C is wrong because setting a secret expiration date only marks the secret as expired after a specified time; it does not trigger any automatic renewal or rotation of the secret.

Full explanation →

426

MCQmedium

You have an Azure App Service web app that experiences high CPU usage during peak hours. You need to scale out automatically based on CPU load. Which scaling solution should you use?

A.Manual scaling

B.Traffic Manager

C.Autoscale with a CPU percentage rule

D.Scale sets autoscale

AnswerC

Azure Autoscale is the correct solution for dynamically adjusting the number of App Service instances based on performance metrics. By configuring an autoscale rule with a CPU percentage threshold, the system automatically scales out (adds instances) when the CPU utilization exceeds the defined limit, and scales in (removes instances) when it drops below a specified lower threshold. This ensures optimal performance and cost efficiency by matching resource capacity to demand.

Why this answer

Autoscale with a CPU percentage rule is the correct solution because Azure App Service supports built-in autoscaling that can automatically increase or decrease the number of instances based on a metric like CPU percentage. This allows the web app to handle peak-hour traffic by scaling out when CPU usage exceeds a defined threshold, ensuring performance without manual intervention.

Exam trap

The trap here is that candidates may confuse 'scale sets autoscale' (which is for VMs) with App Service autoscale, or think Traffic Manager can scale resources, when it only distributes traffic.

How to eliminate wrong answers

Option A is wrong because manual scaling requires human intervention to adjust instance counts, which cannot automatically respond to CPU load during peak hours. Option B is wrong because Traffic Manager is a DNS-based traffic load balancer that routes traffic across endpoints but does not scale the underlying compute resources based on CPU metrics. Option D is wrong because 'Scale sets autoscale' refers to Virtual Machine Scale Sets, which are used for scaling VMs, not for Azure App Service web apps; App Service has its own autoscale feature that does not require scale sets.

Full explanation →

427

MCQhard

You are designing a solution that uses Azure Event Hubs to ingest telemetry data. The data must be encrypted at rest and in transit. Additionally, you need to ensure that only authorized applications can publish messages to the event hub. Which combination of features should you use?

A.Use managed identities for applications and enable encryption at rest using customer-managed keys.

B.Use SAS tokens or managed identities for authentication, and rely on default encryption at rest and in transit.

C.Use Azure Private Link to connect applications to Event Hubs.

D.Enable Azure Firewall on the Event Hubs namespace and use IP filtering.

AnswerB

This option correctly identifies the standard and recommended security practices for Azure Event Hubs. Both Shared Access Signatures (SAS) and Managed Identities are valid and widely used mechanisms for authenticating applications to Event Hubs, providing robust authorization. Furthermore, Azure Event Hubs automatically encrypts data at rest using Microsoft-managed keys and encrypts all data in transit using Transport Layer Security (TLS), fulfilling essential encryption requirements without requiring additional configuration.

Why this answer

Azure Event Hubs automatically encrypts data at rest with Azure Storage Service Encryption (SSE) and in transit with TLS 1.2. For authorization, SAS tokens or managed identities provide the necessary application-level authentication to publish messages. This combination meets all stated requirements without additional configuration.

Exam trap

The trap here is that candidates often over-engineer the solution by selecting advanced features like customer-managed keys or Private Link, when the default encryption and simple authentication mechanisms already satisfy the stated requirements.

How to eliminate wrong answers

Option A is wrong because while managed identities can authenticate applications, customer-managed keys (CMK) are an optional encryption-at-rest feature that is not required to meet the 'encrypted at rest' requirement—default encryption already satisfies it. Option C is wrong because Azure Private Link only secures network connectivity by exposing the Event Hubs namespace to a virtual network; it does not handle encryption at rest or application-level authorization for publishing. Option D is wrong because Azure Firewall and IP filtering control network access at the namespace level but do not provide application-level authentication or encryption at rest; they are complementary security layers, not the primary solution for authorized publishing.

Full explanation →

428

Multi-Selecteasy

Which TWO Azure services can be used to securely store and retrieve secrets, such as API keys and connection strings, for use in cloud applications?

Select 2 answers

A.Azure Cosmos DB

B.Azure Key Vault

C.Azure Blob Storage

D.Azure App Configuration

E.Azure SQL Database

AnswersB, D

Dedicated secrets management service.

Why this answer

Azure Key Vault is a dedicated cloud service for securely storing and accessing secrets like API keys, connection strings, and certificates. It provides hardware security module (HSM)-backed encryption, access control via Azure RBAC and access policies, and integrates with Azure services and applications through REST APIs and SDKs.

Azure App Configuration can also be used to securely retrieve secrets. While it primarily stores application settings and feature flags, it supports referencing secrets stored in Azure Key Vault. This allows applications to retrieve secrets securely through App Configuration, leveraging Key Vault's robust security features without directly accessing Key Vault.

Exam trap

The trap is that candidates may think only Azure Key Vault can store secrets, but Azure App Configuration can also securely store and retrieve secrets by using Key Vault references. Recognizing that both services can be used for this purpose is key.

Full explanation →

429

MCQeasy

You are building a solution that needs to process large CSV files uploaded to Azure Blob Storage. Each file can be up to 1 GB. You want to minimize processing time and cost. Which approach should you recommend?

A.Use Azure Data Factory to copy the data from Blob Storage to Azure SQL Database and perform transformations.

B.Use Azure Logic Apps to trigger a function that parses the CSV and inserts into Cosmos DB.

C.Download the file to an Azure VM and use a custom script to parse and insert into a database.

D.Use Azure Stream Analytics to read the CSV from Blob Storage and output to a data warehouse.

AnswerA

Azure Data Factory (ADF) is purpose-built for orchestrating and automating large-scale data movement and transformation workflows, making it ideal for batch processing large CSV files. It offers managed integration runtimes, robust connectivity to various data stores like Blob Storage and Azure SQL Database, and powerful data flow capabilities for complex transformations without writing extensive code. ADF's scalable architecture ensures efficient and reliable ingestion and processing of substantial data volumes into a relational database.

Why this answer

Azure Data Factory (ADF) is the correct choice because it is a fully managed, serverless data integration service designed for high-scale data movement and transformation. ADF can directly read large CSV files from Blob Storage using Copy Activity with built-in parallelization and chunking, then transform the data using Mapping Data Flows or stored procedures in Azure SQL Database, all without provisioning VMs or managing infrastructure. This minimizes both processing time (via scale-out) and cost (pay-per-use, no idle compute).

Exam trap

The trap here is that candidates often choose Logic Apps or Stream Analytics because they are 'serverless' and 'low-code', but they fail to recognize that these services are optimized for small payloads or real-time streams, not for batch processing of multi-gigabyte files.

How to eliminate wrong answers

Option B is wrong because Azure Logic Apps is a workflow orchestration service, not a data processing engine; it would require pulling the entire 1 GB CSV into memory via a trigger, causing timeouts (default 2-min timeout) and high memory consumption, making it unsuitable for large files. Option C is wrong because downloading a 1 GB file to an Azure VM introduces network transfer latency, VM provisioning costs, and manual scaling overhead, which increases both time and cost compared to serverless alternatives. Option D is wrong because Azure Stream Analytics is designed for real-time streaming data (e.g., IoT events) and cannot efficiently process batch-oriented, large CSV files; it lacks native CSV parsing and batch transformation capabilities, leading to poor performance and higher cost.

Full explanation →

430

MCQmedium

Refer to the exhibit. You deploy an Azure Storage account using the ARM template snippet. A developer reports that they cannot connect to the storage account from their machine with IP 10.0.0.5, even though they have the proper RBAC role. What is the most likely reason?

A.The storage account is configured to bypass Azure Services, which blocks non-Azure clients.

B.The developer does not have the Storage Blob Data Contributor role.

C.The storage account firewall is configured to deny all traffic except from the 192.168.1.0/24 IP range.

D.The minimum TLS version is set to TLS 1.2, but the developer's client uses TLS 1.0.

AnswerC

Azure Storage account firewalls operate on a default-deny principle, meaning all network traffic is blocked unless explicitly allowed by a configured rule. If the storage account firewall is configured to permit traffic exclusively from the 192.168.1.0/24 IP range, any connection attempt originating from an IP address outside this specific range will be immediately rejected at the network perimeter. This prevents the developer's client from establishing a connection, as their IP address is not within the allowed subnet, resulting in a network access denied error.

Why this answer

The ARM template snippet configures a network rule that only allows traffic from the 192.168.1.0/24 IP range. Since the developer's machine has IP 10.0.0.5, it falls outside this allowed range, causing the connection to be blocked by the storage account firewall, regardless of RBAC permissions. RBAC controls authorization (who can access), but network rules control access (who can reach the endpoint), and the firewall denies all traffic not explicitly permitted.

Exam trap

The trap here is that candidates assume RBAC roles alone grant access, overlooking that Azure Storage firewalls enforce network-level restrictions that are evaluated before any authorization checks.

How to eliminate wrong answers

Option A is wrong because 'bypass Azure Services' is a setting that allows trusted Azure platform services to bypass the firewall, but it does not block non-Azure clients; it only permits specific Azure services. Option B is wrong because the developer already has the proper RBAC role (as stated), and RBAC roles like Storage Blob Data Contributor grant authorization but do not override network-level firewall rules. Option D is wrong because the ARM template snippet does not specify a minimum TLS version; even if it did, TLS 1.0 is not supported by Azure Storage (which requires TLS 1.2 by default), but the question states the developer cannot connect, and the most likely reason is the explicit IP restriction, not TLS version mismatch.

Full explanation →

431

MCQmedium

A developer writes an Azure Function that uses the Azure.Storage.Blobs SDK to upload a file to Blob Storage. The function runs locally but fails when deployed to Azure with a '403 Forbidden' error. What is the most likely cause?

A.The function app does not have the correct RBAC role on the storage account

B.The Azure.Storage.Blobs SDK version is deprecated

C.The function runtime version is incompatible

D.The storage account is behind a firewall and the function app's outbound IP is not whitelisted

AnswerA

Managed identity needs Storage Blob Data Contributor role to write blobs.

Why this answer

The 403 Forbidden error when an Azure Function runs in Azure but not locally typically indicates an authorization failure. By default, Azure Functions use managed identity to access storage accounts, and the function app's system-assigned managed identity must be granted the appropriate RBAC role (e.g., Storage Blob Data Contributor) on the storage account. Without this role, the SDK's request to Blob Storage is denied, resulting in a 403.

Exam trap

The trap here is that candidates often assume a 403 always means a network firewall issue (Option D), but Azure Functions in the Consumption plan use managed identity by default, and the most common cause is missing RBAC role assignment on the storage account, not IP whitelisting.

How to eliminate wrong answers

Option B is wrong because a deprecated SDK version would cause compilation or runtime errors (e.g., missing methods), not a 403 Forbidden HTTP status code from the storage service. Option C is wrong because the function runtime version incompatibility would manifest as startup or binding failures, not a 403 from Blob Storage. Option D is wrong because a firewall with IP whitelisting would produce a 403 only if the function app's outbound IP is not whitelisted; however, Azure Functions in the Consumption plan use dynamic outbound IPs, and the more common and likely cause is missing RBAC permissions, especially when using managed identity (the default in newer runtimes).

Full explanation →

432

MCQhard

You are developing a solution that uses Azure Container Apps. Your application is a microservice that needs to expose a gRPC endpoint. The service must scale to zero when idle. What should you do?

A.Use Azure Functions with a gRPC trigger.

B.Deploy the microservice to Azure Container Apps and configure a scale rule with minReplicas set to 0.

C.Deploy the microservice to Azure Kubernetes Service with a virtual node.

D.Deploy the microservice to Azure Container Instances with a scale rule.

AnswerB

Azure Container Apps is specifically designed for hosting microservices and supports gRPC ingress natively, allowing direct exposure of gRPC endpoints. Crucially, it enables configuring scale rules that include setting minReplicas to 0, which means the container app can scale down completely when idle, incurring no cost for compute resources. This combination of gRPC support and true scale-to-zero capability makes it an ideal solution for cost-efficient, event-driven microservices.

Why this answer

Azure Container Apps natively supports gRPC endpoints and can scale to zero by setting `minReplicas` to 0 in a scale rule. This configuration allows the microservice to run only when there are active requests, reducing costs during idle periods. The combination of gRPC support and dynamic scaling makes Container Apps the correct choice for this scenario.

Exam trap

The trap here is that candidates may assume Azure Functions can handle gRPC via custom handlers or that ACI supports autoscaling, but neither service provides native gRPC support or the scale-to-zero capability required for this specific workload.

How to eliminate wrong answers

Option A is wrong because Azure Functions does not have a native gRPC trigger; it supports HTTP, timer, and other triggers, but gRPC is not a supported binding, and Functions cannot scale to zero for gRPC workloads. Option C is wrong because Azure Kubernetes Service (AKS) with virtual nodes does not support scaling to zero; virtual nodes enable burst scaling but maintain a minimum number of pods, and AKS typically incurs cluster management overhead. Option D is wrong because Azure Container Instances (ACI) does not support scale rules or automatic scaling to zero; it is designed for single-instance containers with manual scaling or restart policies, not dynamic scale-to-zero behavior.

Full explanation →

433

Multi-Selectmedium

Which TWO actions can you take to improve the performance of an Azure App Service web app that makes calls to an external API? (Choose two.)

Select 2 answers

A.Use a connection pool to reuse connections to the API.

B.Send multiple requests in parallel to the API.

C.Scale out the App Service to more instances.

D.Use async/await patterns in the code to avoid blocking threads.

E.Implement caching of API responses using Azure Cache for Redis.

AnswersD, E

Async/await improves scalability and responsiveness.

Why this answer

Options D and E are correct. Caching responses with Azure Cache for Redis reduces redundant API calls, improving performance. Using async/await patterns prevents blocking threads, allowing the web app to handle more concurrent requests efficiently.

Option A (connection pooling) can help but is not as directly impactful for performance in this scenario. Option B (parallel requests) may increase load on the API without guaranteed performance gain. Option C (scaling out) increases capacity but does not improve per-request latency or reduce redundant calls.

Full explanation →

434

MCQeasy

You are developing a mobile app backend using Azure Functions. The app allows users to upload profile pictures. The pictures are stored in Azure Blob Storage and the metadata (user ID, blob URL, upload timestamp) is stored in Azure SQL Database. You need to implement a process that automatically generates a thumbnail for each uploaded picture and updates the metadata with the thumbnail URL. The thumbnail generation is CPU-intensive and may take up to 30 seconds per image. The solution should be serverless and cost-effective. Which combination of Azure services should you use?

A.Use an Azure VM with a scheduled task to poll for new blobs and generate thumbnails.

B.Use an Azure Queue Storage trigger to invoke an Azure Function that processes the image and updates Azure SQL Database.

C.Use an Azure Blob Storage trigger to invoke an Azure Function that generates the thumbnail and updates Azure SQL Database.

D.Use Azure Event Grid to trigger an Azure Logic App that generates the thumbnail and updates Azure SQL Database.

AnswerC

This is the most appropriate and efficient solution. An Azure Blob Storage trigger directly invokes an Azure Function whenever a new image file is uploaded, providing a serverless, event-driven architecture that scales automatically with demand. This approach minimizes operational overhead and costs, as the function only runs and incurs charges when actual image processing is required, perfectly aligning with mobile app backend needs.

Why this answer

Azure Blob Storage triggers are designed to invoke an Azure Function automatically when a new blob is created, which is ideal for this serverless, event-driven workflow. The function can generate the thumbnail (even with a 30-second CPU-intensive task, as Azure Functions support up to 10-minute execution on the Premium plan) and then update the Azure SQL Database with the thumbnail URL, all without managing infrastructure.

Exam trap

The trap here is that candidates may choose Option B (Queue trigger) thinking it provides better decoupling for long-running tasks, but the Blob Storage trigger is the direct and simpler event-driven solution, and the 30-second processing time is well within Azure Functions' limits when using the Premium plan.

How to eliminate wrong answers

Option A is wrong because using an Azure VM with a scheduled task is not serverless, requires manual scaling and cost for idle compute, and introduces unnecessary complexity for polling blobs instead of using event-driven triggers. Option B is wrong because an Azure Queue Storage trigger would require an additional step to enqueue a message after blob upload, adding latency and complexity, whereas a Blob Storage trigger directly reacts to the blob creation event. Option D is wrong because Azure Logic Apps are not optimized for CPU-intensive tasks like thumbnail generation (they have limited execution time and are better for orchestration), and they would incur higher costs per execution compared to Azure Functions for this workload.

Full explanation →

435

MCQhard

You are troubleshooting a containerized application running on Azure Kubernetes Service (AKS). The application logs indicate that it cannot connect to an Azure SQL Database using a managed identity. The pod is configured with a user-assigned managed identity. Which step is most likely missing?

A.The Azure SQL Database firewall is blocking the pod IP

B.The pod's service account is not linked to the managed identity

C.The managed identity is not in the same Microsoft Entra ID tenant as the AKS cluster

D.The AKS cluster does not have the Azure AD Pod Identity add-on enabled

AnswerD

"The AKS cluster does not have the Azure AD Pod Identity add-on enabled" is the correct answer. This add-on is essential because it deploys the necessary Kubernetes components, specifically the Managed Identity Controller (MIC) and Node Managed Identity (NMI) server, which facilitate the assignment of Azure managed identities to individual pods. Without these components, pods cannot intercept token requests or acquire the required Azure AD tokens from the assigned managed identity to authenticate with Azure resources like Azure SQL Database.

Why this answer

The AKS cluster requires the Azure AD Pod Identity add-on (or the newer Workload Identity) to enable pods to authenticate to Azure resources using managed identities. Without this add-on, the pod's user-assigned managed identity cannot be used to obtain tokens for connecting to Azure SQL Database, even if the identity is correctly assigned to the pod.

Exam trap

The trap here is that candidates often assume assigning a managed identity to a pod is sufficient, but they overlook the requirement for the AKS cluster to have the Azure AD Pod Identity add-on enabled to bridge the pod and the identity for token acquisition.

How to eliminate wrong answers

Option A is wrong because the pod's IP is not the issue; Azure SQL Database firewall rules block IP addresses, but managed identity authentication uses Azure AD tokens, not the pod's IP, so the firewall is not the missing step. Option B is wrong because the pod's service account does not need to be linked to the managed identity; instead, the pod is assigned the identity via Azure AD Pod Identity or Workload Identity, not through a service account binding. Option C is wrong because the managed identity must be in the same Microsoft Entra ID tenant as the AKS cluster for authentication to work; if it were in a different tenant, the token request would fail, but the question implies the identity is correctly assigned, so this is not the missing step.

Full explanation →

436

MCQmedium

A developer exposes several backend APIs through Azure API Management. Clients must be throttled by subscription to protect the backend. What should be configured?

A.Blob soft delete

B.Application Insights sampling

C.Private DNS zone only

D.API Management rate-limit or quota policy

AnswerD

APIM policies can enforce rate limits and quotas per subscription or caller.

Why this answer

Azure API Management provides built-in rate-limit and quota policies that allow you to throttle client requests based on the subscription key. This directly protects backend services from excessive traffic by enforcing per-subscription call rates and quotas, which aligns with the requirement to throttle clients by subscription.

Exam trap

The trap here is that candidates may confuse Application Insights sampling (a telemetry feature) with API throttling, or think Blob soft delete or DNS zones could somehow limit API calls, when only API Management policies directly enforce subscription-based rate limits.

How to eliminate wrong answers

Option A is wrong because Blob soft delete is a data protection feature for Azure Blob Storage that recovers accidentally deleted blobs; it has no role in API throttling or subscription-based rate limiting. Option B is wrong because Application Insights sampling reduces the volume of telemetry data collected for monitoring, not API request throttling; it controls data ingestion, not client access rates. Option C is wrong because a Private DNS zone only manages custom DNS resolution within a virtual network; it does not enforce any rate limits or quotas on API calls.

Full explanation →

437

MCQmedium

Your Azure Kubernetes Service (AKS) cluster experiences node failures. Which Azure service provides automated node repair?

A.Azure Sentinel

B.Microsoft Defender for Cloud

C.AKS node auto-repair

D.Azure Monitor

AnswerC

AKS node auto-repair is a built-in feature designed to automatically monitor and remediate unhealthy worker nodes within an Azure Kubernetes Service cluster. It proactively identifies issues such as unresponsive nodes, disk space problems, or failed kubelet processes. Upon detecting an unhealthy state, this feature attempts to restart the node or, if necessary, reimage it to restore its operational health without manual intervention. This directly addresses node health problems.

Why this answer

C is correct because AKS node auto-repair is a built-in feature that automatically detects unhealthy nodes (based on Node Conditions like 'NotReady' or 'DiskPressure') and initiates repair actions such as reimaging the node. This feature is specific to AKS and operates at the cluster level without requiring external services.

Exam trap

The trap here is that candidates may confuse Azure Monitor's alerting capabilities or Microsoft Defender for Cloud's security recommendations with actual automated remediation, but neither service performs node-level repair actions in AKS.

How to eliminate wrong answers

Option A is wrong because Azure Sentinel is a Security Information and Event Management (SIEM) service for threat detection and incident response, not for automated node repair in AKS. Option B is wrong because Microsoft Defender for Cloud provides security posture management and workload protection, including vulnerability assessments and threat alerts, but it does not perform automated node repair. Option D is wrong because Azure Monitor collects metrics, logs, and alerts for observability and diagnostics, but it does not execute repair actions on AKS nodes.

Full explanation →

438

Drag & Dropmedium

Arrange the steps to deploy an Azure App Service using Azure CLI in the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

To deploy an App Service, first create a resource group, then an App Service plan, then the web app, deploy code, and finally verify.

Full explanation →

439

MCQmedium

Your Azure App Service web app experiences slow response times during peak hours. You suspect the App Service plan is under-provisioned. You need to scale out the app automatically based on CPU usage. What should you configure?

A.Configure scheduled scaling in the app

B.Manually increase instance count

C.Configure scale up in the App Service plan

D.Configure autoscale rules in the App Service plan

AnswerD

Autoscale rules in an App Service plan enable the system to automatically adjust the number of instances (scale out or in) based on predefined performance metrics, such as CPU utilization, memory usage, or HTTP queue length. By configuring rules to scale out when metrics like CPU usage exceed a threshold, the web app can dynamically add more instances to distribute the load and improve response times. This ensures the application maintains optimal performance and availability even during unpredictable traffic spikes, without requiring manual intervention.

Why this answer

Autoscale rules in the App Service plan allow you to automatically scale out (increase instance count) based on metrics like CPU usage. This is the correct solution because it dynamically adjusts capacity in response to demand during peak hours without manual intervention.

Exam trap

The trap here is confusing 'scale up' (vertical scaling, changing plan tier) with 'scale out' (horizontal scaling, adding instances), and assuming scheduled scaling can react to real-time CPU spikes.

How to eliminate wrong answers

Option A is wrong because scheduled scaling is used for predictable load patterns (e.g., time-of-day), not for reactive scaling based on CPU usage. Option B is wrong because manually increasing the instance count is a one-time action and does not provide automatic scaling based on CPU metrics. Option C is wrong because scale up increases the size (tier) of the App Service plan (e.g., from S1 to S2), not the number of instances; it does not address horizontal scaling (scale out).

Full explanation →

440

MCQeasy

You are developing a solution that stores user-uploaded profile pictures. Users upload pictures that are then displayed on their profile page. After 30 days, if the user hasn't logged in, the system moves the picture to cold storage. You need to choose the initial access tier for the container to optimize cost and performance for frequently accessed pictures. Which tier should you use?

A.Hot

B.Cool

C.Archive

D.Premium

AnswerA

The Hot tier is specifically designed for frequently accessed data that requires low latency and high throughput, making it the optimal choice for user profile pictures. These images are typically retrieved every time a user logs in or views a profile, demanding immediate access. While its storage costs are higher than Cool or Archive, the Hot tier offers the lowest access costs and ensures a responsive user experience for dynamic content like profile pictures.

Why this answer

The Hot tier is the correct initial access tier because the profile pictures are frequently accessed immediately after upload (e.g., displayed on profile pages). The Hot tier is optimized for high-frequency read/write operations with the lowest latency, making it cost-effective for data that is accessed often. After 30 days of inactivity, the system moves the picture to cold storage, so the initial tier should prioritize performance for active data, not long-term archival cost savings.

Exam trap

The trap here is that candidates often choose Cool or Archive thinking they are 'cost-saving' upfront, but they overlook that the Hot tier is actually the most cost-effective for frequently accessed data because it avoids per-access fees and latency penalties, while lifecycle management handles the eventual move to cheaper storage.

How to eliminate wrong answers

Option B (Cool) is wrong because the Cool tier is designed for data that is infrequently accessed (e.g., once a month or less) and has higher access costs and latency compared to Hot, making it suboptimal for frequently accessed profile pictures. Option C (Archive) is wrong because the Archive tier is for data that is rarely accessed (e.g., once a year) and has the highest retrieval latency (up to 15 hours for rehydration), which is unacceptable for immediate display on a profile page. Option D (Premium) is wrong because the Premium tier is for block blobs with low-latency requirements (e.g., for Azure Virtual Desktop or high-performance computing) and incurs significantly higher storage costs, making it overkill and cost-inefficient for standard user-uploaded profile pictures.

Full explanation →

441

MCQhard

You are a developer at Contoso Ltd. The company has an existing .NET Core web application hosted on Azure App Service that allows users to upload images. The application currently stores images directly to Azure Blob Storage using connection strings stored in the Web.config file. The security team has mandated that all secrets must be stored in Azure Key Vault and rotated automatically. Additionally, the application must be able to access the Key Vault without storing any credentials in the application code or configuration files. The application uses Microsoft Entra ID for user authentication. You need to modify the application to meet these requirements with minimal changes to the application code. You have the following resources: an Azure Key Vault instance with the secrets (storage account connection string) already stored; a managed identity enabled for the App Service. You want to use the Key Vault references feature of Azure App Configuration or direct Key Vault access. Which approach should you take?

A.Set the connection string as an environment variable in the App Service using the Azure CLI and rely on the Key Vault backup.

B.Create an Azure App Configuration store, import the secrets from Key Vault, and change the application to use the App Configuration provider.

C.In the Azure portal, update the App Service application settings to reference the Key Vault secrets using the Key Vault references feature. Enable the system-assigned managed identity for the App Service and grant it Get and List permissions on the Key Vault.

D.Modify the application code to use the Azure Identity SDK to authenticate to Key Vault via managed identity and retrieve the connection string.

AnswerC

This is the recommended and most secure approach. Azure App Service's Key Vault references feature allows application settings to dynamically retrieve secrets from Key Vault at runtime without modifying application code. By enabling a system-assigned managed identity for the App Service and granting it 'Get' and 'List' permissions on the Key Vault, the App Service securely authenticates to Key Vault. This method ensures secrets are never exposed in application settings, supports automatic secret rotation, and adheres to the principle of least privilege.

Why this answer

It uses the Key Vault references feature in Azure App Service, which allows you to reference secrets stored in Key Vault directly from application settings without any code changes. By enabling the system-assigned managed identity and granting it Get and List permissions on the Key Vault, the App Service can authenticate to Key Vault without storing any credentials in code or configuration files. This approach meets the security team's mandate for automatic secret rotation (Key Vault references are resolved at runtime, so rotated secrets are automatically picked up) and requires minimal changes to the application code.

Exam trap

The trap here is that candidates often assume that using the Azure Identity SDK (Option D) is the only way to integrate with Key Vault, overlooking the built-in Key Vault references feature in App Service that requires zero code changes and automatically handles secret rotation.

How to eliminate wrong answers

Option A is wrong because setting the connection string as an environment variable in the App Service using the Azure CLI still stores the secret value in the environment, not in Key Vault, and the 'Key Vault backup' feature does not provide runtime secret resolution or rotation. Option B is wrong because it introduces an unnecessary dependency on Azure App Configuration, which requires additional setup and code changes (e.g., adding the App Configuration provider), violating the 'minimal changes to application code' requirement. Option D is wrong because modifying the application code to use the Azure Identity SDK to authenticate to Key Vault and retrieve the connection string directly requires code changes, which contradicts the requirement for minimal code changes; the Key Vault references feature achieves the same goal without any code modifications.

Full explanation →

442

Drag & Dropmedium

Arrange the steps to implement Azure AD authentication in an ASP.NET Core web app in the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

First register the app in Azure AD, then configure settings, add NuGet, configure middleware, and secure endpoints.

Full explanation →

443

MCQmedium

A company stores sensitive data in an Azure Storage account. They need to restrict access based on the client's IP address and require that clients use a valid SAS token. Which mechanism should they use?

A.Microsoft Entra ID authentication.

B.Shared Key.

C.SAS token with IP ACL.

D.Firewall and virtual networks.

AnswerC

A Shared Access Signature (SAS) token provides delegated access to Azure Storage resources with granular control over permissions, services, resource types, and validity period. Critically, a SAS token can include an `sip` (signed IP) parameter, which specifies an acceptable range of public IP addresses or a single IP address from which requests must originate. This ensures that even if the SAS token is intercepted, it can only be used by clients within the designated IP range, significantly enhancing security for specific, time-limited operations.

Why this answer

A SAS token with an IP ACL (access control list) allows you to restrict access to a specific client IP address or range of IP addresses while also requiring a valid SAS token for authentication. This meets both requirements: IP-based restriction and SAS token validation. The IP ACL is specified as part of the SAS token's signed IP (sip) parameter, which enforces that requests must originate from the allowed IP range.

Exam trap

The trap here is that candidates often confuse network-level IP restrictions (firewall/VNet) with SAS-level IP restrictions, not realizing that only a SAS token with an IP ACL can enforce both a valid token and a specific client IP address simultaneously.

How to eliminate wrong answers

Option A is wrong because Microsoft Entra ID authentication does not use SAS tokens; it relies on Azure AD identities and RBAC roles, which cannot enforce a client IP restriction at the SAS token level. Option B is wrong because Shared Key authentication uses the storage account key directly, which does not support IP-based restrictions and does not involve a SAS token. Option D is wrong because Firewall and virtual networks can restrict access by IP address, but they do not require a SAS token; they operate at the network layer and can be bypassed if the SAS token is not enforced.

Full explanation →

444

MCQeasy

An application uses Azure Application Insights for monitoring. You need to write a query to analyze the number of failed requests and exceptions over the past hour. Which query language should you use?

A.SQL

B.Kusto Query Language (KQL)

C.PowerShell

D.Azure CLI

AnswerB

Kusto Query Language (KQL) is the native and primary query language for Azure Monitor Logs and Application Insights. It is specifically designed for querying large volumes of structured, semi-structured, and unstructured data, making it ideal for analyzing application telemetry like requests, dependencies, exceptions, and traces. KQL provides powerful operators for filtering, aggregating, joining, and visualizing data, enabling developers to efficiently diagnose issues and understand application performance and usage patterns.

Why this answer

Azure Application Insights stores telemetry data in a Log Analytics workspace, which is queried using Kusto Query Language (KQL). KQL is the native query language for Azure Data Explorer and is specifically designed for time-series analysis, filtering, and aggregation of log data. To analyze failed requests and exceptions over the past hour, you would use KQL operators like `where`, `summarize`, and `bin` to filter by timestamp and count events.

Exam trap

The trap here is that candidates may confuse KQL with SQL due to superficial similarities in syntax (e.g., `where` clauses), but Azure Application Insights exclusively uses KQL, not SQL, for log queries.

How to eliminate wrong answers

Option A is wrong because SQL is not supported for querying Application Insights data; the underlying storage is a column-store optimized for KQL, not a relational database. Option C is wrong because PowerShell is a scripting language used for automation and resource management, not for querying telemetry data directly from Application Insights. Option D is wrong because Azure CLI is a command-line tool for managing Azure resources, not a query language for analyzing log data.

Full explanation →

445

Multi-Selectmedium

Which FOUR are valid ways to authenticate to Azure Blob Storage from an application? (Choose four.)

Select 4 answers

A.Use the storage account access key.

B.Use an OAuth2 token obtained from Microsoft Entra ID for a user.

C.Use a shared access signature (SAS) token.

D.Use a client certificate.

E.Use a managed identity assigned to an Azure resource.

AnswersA, B, C, E

The storage account access key is a valid authentication method, providing full access to the account. It is commonly used for administrative tasks or when fine-grained control is not required.

Why this answer

The storage account access key provides full administrative access to the storage account, including Blob Storage. It is a simple, shared-key authentication method using HMAC-SHA256 to sign requests. Option B is correct because OAuth2 tokens obtained from Microsoft Entra ID for a user are a supported authentication method for Azure Blob Storage, enabling fine-grained access control.

Option C is correct because a shared access signature (SAS) token provides delegated access to storage resources with specified permissions and expiry. Option E is correct because a managed identity assigned to an Azure resource (e.g., a VM or App Service) can be used to authenticate to Blob Storage without storing credentials. Option D is incorrect because client certificates are not a supported authentication method for direct access to Azure Blob Storage; they are used for device authentication or authenticating to Azure AD as a service principal.

Exam trap

Common mistake: Candidates often assume that only one of OAuth2 user token (B) and managed identity (E) is valid, but both are supported methods. Also, client certificates (D) are not directly supported for Blob Storage authentication.

Full explanation →

446

MCQmedium

You have an Azure Function app that uses Durable Functions. You notice that some orchestrations are taking longer than expected. You need to monitor the history of orchestration instances. What should you use?

A.Application Insights

B.Azure Monitor Metrics

C.Azure Storage Explorer

D.Durable Functions HTTP management APIs

AnswerD

The Durable Functions HTTP management APIs are specifically designed to query and manage the lifecycle of individual orchestration instances. These APIs provide comprehensive details, including the current runtime status (e.g., Running, Completed, Failed), input, output, and the complete execution history of activities and sub-orchestrations for a given instance ID. This direct access to the orchestration state machine makes them the authoritative source for detailed instance history and management.

Why this answer

D is correct because the Durable Functions HTTP management APIs provide direct access to the orchestration instance history, including status queries, raise events, and terminate operations. These APIs return the full execution history of an orchestration instance, allowing you to inspect each step and identify delays. This is the most targeted way to monitor the history of specific orchestration instances without additional configuration.

Exam trap

The trap here is that candidates often assume Application Insights is the default monitoring tool for all Azure Functions scenarios, but for Durable Functions instance-level history, the built-in HTTP management APIs are the direct and correct answer without requiring additional setup.

How to eliminate wrong answers

Option A is wrong because Application Insights is a general-purpose monitoring and diagnostics service that requires additional instrumentation and configuration to capture Durable Functions telemetry; it does not directly expose the orchestration instance history without custom queries. Option B is wrong because Azure Monitor Metrics provides aggregated performance metrics (e.g., execution count, duration) but does not offer per-instance history or detailed step-level data. Option C is wrong because Azure Storage Explorer can view the underlying storage tables and queues used by Durable Functions, but it does not provide a structured, queryable history of orchestration instances and requires manual navigation of raw storage artifacts.

Full explanation →

447

MCQeasy

You need to secure a web API that is called from a single-page application (SPA). The API uses Microsoft Entra ID for authentication. Which OAuth 2.0 flow should the SPA use?

A.Authorization code flow with PKCE

B.Resource owner password credentials flow

C.Client credentials flow

D.Implicit flow

AnswerA

The Authorization Code flow with PKCE (Proof Key for Code Exchange) is the recommended and most secure method for Single-Page Applications (SPAs) because it eliminates the need for a client secret, which SPAs cannot securely store. It involves a two-step process where the SPA first obtains an authorization code, then exchanges it for tokens at the identity provider's token endpoint. PKCE adds a dynamic secret (code verifier/challenge) to this exchange, preventing code interception attacks by ensuring only the original client can redeem the authorization code.

Why this answer

The authorization code flow with PKCE (Proof Key for Code Exchange) is the recommended OAuth 2.0 flow for single-page applications because it provides a secure way to obtain an access token without exposing the client secret, which cannot be stored confidentially in a browser. PKCE adds a cryptographic challenge to prevent authorization code interception attacks, making it the only flow that meets modern security standards for public clients like SPAs calling Microsoft Entra ID-protected APIs.

Exam trap

The trap here is that candidates may choose the Implicit flow (Option D) because it was historically the standard for SPAs, but Microsoft Entra ID and OAuth 2.0 BCP now deprecate it in favor of the authorization code flow with PKCE, which is the only secure option for public clients.

How to eliminate wrong answers

Option B (Resource owner password credentials flow) is wrong because it requires the user to provide their username and password directly to the SPA, which violates the principle of least privilege and is not recommended for interactive web applications; it also does not support multi-factor authentication or conditional access policies in Entra ID. Option C (Client credentials flow) is wrong because it is designed for server-to-server (daemon) applications that authenticate without a user context, not for SPAs that need to act on behalf of a signed-in user. Option D (Implicit flow) is wrong because it was historically used for SPAs but is now deprecated by OAuth 2.0 Security Best Current Practice (BCP) due to security vulnerabilities, such as access token leakage in the browser history and lack of token binding; Microsoft Entra ID recommends the authorization code flow with PKCE instead.

Full explanation →

448

MCQhard

You are designing a solution that uses Azure Container Instances (ACI) to run a batch job. The job must run only once a day and should not incur costs when idle. Which configuration should you use?

A.Use Azure Kubernetes Service with a node pool that scales to zero

B.Deploy a container group with a restart policy of Always

C.Use a scheduled job that creates a container group with restart policy Never and delete after completion

D.Use Azure Container Apps with scale-to-zero minimum replicas

AnswerC

This approach is optimal for cost efficiency. A scheduled job can programmatically create an Azure Container Instance (ACI) container group, which offers per-second billing. Setting the restart policy to Never ensures the container stops and releases all compute resources immediately upon successful completion, while explicitly deleting the container group after its run guarantees no lingering charges, making it ideal for one-off, batch-like tasks.

Why this answer

Azure Container Instances (ACI) supports a restart policy of 'Never' for one-off batch jobs, and you can orchestrate the creation and deletion of the container group using a scheduled job (e.g., Azure Logic Apps, Azure Functions, or a cron-based trigger). This ensures the container runs exactly once per day and incurs no cost when idle, as the container group is deleted after completion.

Exam trap

The trap here is that candidates may confuse the 'restart policy' with cost management, assuming 'Always' or 'OnFailure' are acceptable, or they may overcomplicate the solution by choosing AKS or Container Apps, which introduce unnecessary complexity and cost for a simple scheduled batch job.

How to eliminate wrong answers

Option A is wrong because Azure Kubernetes Service (AKS) with a node pool that scales to zero still incurs costs for the control plane and requires more complex orchestration than needed for a simple daily batch job; AKS is overkill and not the simplest solution for a single container. Option B is wrong because a restart policy of 'Always' would cause the container to restart continuously after completion, incurring ongoing costs and not meeting the requirement to run only once a day. Option D is wrong because Azure Container Apps with scale-to-zero minimum replicas still incurs costs for the underlying infrastructure (e.g., the environment and networking) and is designed for HTTP-triggered workloads, not scheduled batch jobs; it also does not natively support a 'run once and delete' pattern without additional orchestration.

Full explanation →

449

MCQmedium

You are deploying a microservice that needs to read secrets (e.g., connection strings) from Azure Key Vault. The service runs on Azure Kubernetes Service (AKS). You want to minimize code changes and automatically rotate secrets. Which approach should you use?

A.Use the Azure Key Vault SDK in the application code to fetch secrets.

B.Store secrets as environment variables in the container image.

C.Use the Azure Key Vault Provider for Secrets Store CSI Driver on AKS.

D.Use Azure App Configuration with Key Vault references.

AnswerC

The Azure Key Vault Provider for Secrets Store CSI Driver on AKS offers a secure and Kubernetes-native method to access secrets by mounting them directly into pods as files within a volume or injecting them as environment variables. This solution leverages Managed Identities for secure access to Key Vault and supports automatic secret rotation and refreshing without requiring any application code changes or pod restarts. It effectively decouples secret management from the application, enhancing security and operational agility.

Why this answer

The Azure Key Vault Provider for Secrets Store CSI Driver mounts secrets as volumes or environment variables in AKS pods without requiring application code changes. It automatically rotates secrets by syncing with Key Vault at a configurable polling interval, minimizing code changes and enabling seamless secret rotation.

Exam trap

The trap here is that candidates often choose Option A (SDK) because it's a common pattern, but the question specifically asks to minimize code changes and automatically rotate secrets, which the CSI driver achieves without any code modifications.

How to eliminate wrong answers

Option A is wrong because using the Azure Key Vault SDK requires explicit code changes to fetch secrets, increasing development effort and not automatically handling rotation without additional logic. Option B is wrong because storing secrets as environment variables in the container image is insecure (secrets are baked into the image) and does not support automatic rotation. Option D is wrong because Azure App Configuration with Key Vault references still requires application code to use the App Configuration SDK, and while it supports rotation, it does not mount secrets directly into the pod without code changes.

Full explanation →

450

MCQeasy

You are deploying a new version of an ASP.NET Core web application to Azure App Service. You want to test the new version with a subset of users before making it available to everyone. You also need to be able to switch back instantly if issues are found. Which App Service feature should you use?

A.Create a separate App Service plan and deploy the new version there.

B.Use Azure DevOps deployment pipelines with deployment gates.

C.Use Azure Traffic Manager to route traffic between the old and new versions.

D.Use deployment slots with swapping.

AnswerD

Deployment slots allow you to deploy to a staging slot, test it, and then swap with the production slot. You can also route a percentage of traffic to the staging slot for A/B testing. Swapping back is immediate and provides a fast rollback.

Why this answer

Deployment slots in Azure App Service allow you to deploy a new version of your application to a staging slot, then gradually route a subset of user traffic to it using slot-specific routing rules (e.g., cookie-based affinity). If issues arise, you can instantly revert by swapping the slots back, which requires no redeployment and preserves the previous version's warm instances.

Exam trap

The trap here is that candidates confuse Azure Traffic Manager (DNS-level routing) with deployment slots (App Service–level routing), not realizing that Traffic Manager cannot provide instant rollback or cookie-based traffic splitting within a single App Service instance.

How to eliminate wrong answers

Option A is wrong because creating a separate App Service plan does not provide built-in traffic splitting or instant rollback; you would need additional load-balancing logic and manual DNS changes, which are slower and more complex. Option B is wrong because Azure DevOps deployment gates control when a release proceeds (e.g., based on monitoring), but they do not natively route a subset of live traffic to a new version or support instant rollback without redeployment. Option C is wrong because Azure Traffic Manager operates at the DNS level, routing traffic between entire App Service instances (not slots within the same app), and it cannot provide instant rollback (DNS propagation delays) or cookie-based session affinity for a subset of users.

Full explanation →

Microsoft Azure Developer Associate AZ-204 (AZ-204) — Questions 376–450