Microsoft Azure Developer Associate AZ-204 AZ-204 Questions 676–750 | Page 10/12

676

MCQmedium

You have an Azure CDN profile that caches content from a storage account. Users in Europe report that images load slowly. You need to improve performance for European users. What should you do?

A.Enable compression on the CDN

B.Enable prefetching on the CDN

C.Configure caching rules to cache longer

D.Add an additional CDN endpoint with a European origin

AnswerD

Adding an additional CDN endpoint with an origin server physically located in Europe is the most direct and effective method to reduce geographic latency for users in that region. This strategy ensures that content is served from a data center much closer to European users, minimizing the physical distance data must travel between the client, the CDN edge node, and the origin, thereby directly addressing and significantly reducing the round-trip time and overall latency.

Why this answer

Adding an additional CDN endpoint with a European origin (e.g., an Azure Storage account in a European region) reduces latency by serving content from a geographically closer point of presence (PoP). Azure CDN uses a global network of edge servers, but if the origin server is far from the users, the first-hop latency from the edge to the origin can still be high. By placing an origin in Europe, the CDN can fetch content from a nearby origin, minimizing the distance data must travel and improving load times for European users.

Exam trap

The trap here is that candidates often assume caching or compression alone can solve geographic latency, but the real bottleneck is the origin's physical distance from the users, which requires a geographically closer origin to minimize first-hop latency.

How to eliminate wrong answers

Option A is wrong because enabling compression reduces the size of the transferred data but does not address the root cause of high latency due to geographic distance between the origin and European users. Option B is wrong because prefetching (pre-loading content to the edge) can improve cache hit ratios but does not reduce the latency of the initial fetch from a distant origin; it only helps if content is already cached. Option C is wrong because configuring caching rules to cache longer increases the time content stays in the edge cache, but if the cache is cold or content is not popular, European users still experience slow first-time loads due to the distant origin.

Full explanation →

677

Multi-Selecteasy

You need to implement a solution for storing and retrieving large amounts of unstructured data (e.g., images, videos, backups) in Azure, with high durability and availability. The solution must allow access from anywhere via HTTP/HTTPS and support both public and private access. Which TWO Azure storage services should you consider?

Select 2 answers

A.Azure Table Storage

B.Azure Data Lake Storage Gen2

C.Azure Queue Storage

D.Azure Blob Storage

E.Azure Files

AnswersB, D

Azure Data Lake Storage Gen2 is the optimal choice for storing and retrieving large unstructured data, especially in big data analytics scenarios. Built upon Azure Blob Storage, it adds a hierarchical namespace and HDFS-compatible access, enabling petabyte-scale data lakes with high throughput and low latency. This makes it ideal for analytical workloads requiring POSIX-compliant file system semantics and integration with services like Azure Synapse Analytics and Azure Databricks.

Why this answer

Azure Blob Storage is purpose-built for storing large amounts of unstructured data such as images, videos, and backups, offering high durability (99.9999999999% with RA-GRS) and availability. It supports access via HTTP/HTTPS from anywhere, and provides both public (anonymous) and private (SAS tokens, RBAC) access controls, making it the primary choice for this scenario.

Exam trap

The trap here is that candidates may confuse Azure Data Lake Storage Gen2 as a separate service, but it is actually built on top of Blob Storage, so both B and D are correct because they represent the same underlying technology for unstructured data.

Full explanation →

678

MCQeasy

You are building a solution that processes images uploaded to Azure Blob Storage. Each image must be analyzed by Azure AI Vision (Computer Vision). You need to trigger the analysis automatically when a new blob is created. Which Azure service should you use?

A.Azure Event Grid

B.Azure Logic Apps

C.Azure Functions

D.Azure WebJobs

AnswerC

Azure Functions is a serverless compute service that enables developers to run small pieces of event-driven code, known as "functions," without managing infrastructure. It offers native integration with Azure Blob Storage, allowing a function to be automatically triggered whenever a new image file is uploaded to a specified container. This makes Azure Functions an ideal and highly scalable choice for executing custom image processing logic, such as resizing, watermarking, or applying machine learning models, directly in response to the upload event.

Why this answer

Azure Functions is the correct choice because it provides a serverless compute service that can be triggered directly by Azure Event Grid when a new blob is created. This allows you to run custom code (e.g., calling Azure AI Vision APIs) in response to the blob storage event without managing infrastructure. The integration is native and efficient, with Event Grid delivering the event to the function via an HTTP trigger or Event Grid trigger binding.

Exam trap

The trap here is that candidates often confuse Azure Event Grid as a standalone solution for executing code, when in fact it is only an event router that requires a subscriber (like Azure Functions) to perform the actual processing.

How to eliminate wrong answers

Option A is wrong because Azure Event Grid is an event routing service, not a compute service; it cannot run the analysis code itself—it only delivers the event to a subscriber like Azure Functions. Option B is wrong because Azure Logic Apps is a workflow orchestration service that can trigger on blob creation, but it is less suitable for custom code execution and incurs higher latency and cost compared to a direct Azure Functions trigger; it also requires a connector or API call to invoke Azure AI Vision, adding complexity. Option D is wrong because Azure WebJobs is a legacy feature of Azure App Service that runs in the same context as a web app, requiring an always-on App Service plan and manual event integration, whereas the question demands a modern, event-driven serverless solution.

Full explanation →

679

MCQhard

You are developing an Azure Functions app that processes orders. Each order triggers a function that writes to Azure Cosmos DB. You notice occasional throttling (429 errors) from Cosmos DB during peak hours. The function app uses the Consumption plan. What is the most cost-effective way to reduce throttling?

A.Increase the provisioned throughput (RU/s) of the Cosmos DB container.

B.Upgrade the function app to the Premium plan for dedicated instances.

C.Increase the function app's instance count by scaling out.

D.Implement retry logic with exponential backoff in the function code.

AnswerD

Implementing retry logic with exponential backoff is a highly effective and recommended pattern for handling transient faults, including throttling, in distributed systems. When a downstream service like Cosmos DB temporarily throttles a request, the function can automatically retry the operation after progressively longer delays. This approach allows the throttled service time to recover, reduces the immediate load, and ensures eventual success without incurring additional infrastructure costs, making the function more resilient.

Why this answer

Implementing retry logic with exponential backoff is the most cost-effective way to handle transient 429 errors from Cosmos DB. The Azure Cosmos DB SDK already includes built-in retry policies, but custom retry logic in the function code can be tuned to match the workload, allowing the function to wait and retry during peak throttling without incurring additional costs from scaling or increasing throughput.

Exam trap

The trap here is that candidates often assume scaling the function app (Option C) or increasing Cosmos DB throughput (Option A) are the only ways to handle throttling, but they overlook that retry logic is a zero-cost, built-in mechanism that directly addresses the transient nature of 429 errors in a Consumption plan environment.

How to eliminate wrong answers

Option A is wrong because increasing provisioned throughput (RU/s) directly increases monthly costs, and it does not address the root cause of throttling during peak hours—it simply raises the ceiling, which is not cost-effective for sporadic bursts. Option B is wrong because upgrading to the Premium plan adds fixed costs for dedicated instances and always-on benefits, which are unnecessary when the Consumption plan already scales automatically; the throttling is on the Cosmos DB side, not the function app's compute capacity. Option C is wrong because scaling out the function app increases the number of concurrent function instances, which can actually increase the request rate to Cosmos DB and worsen throttling, not reduce it.

Full explanation →

680

MCQmedium

A high-traffic API sends approximately 80,000 telemetry events per second to Application Insights. Monthly ingestion costs are too high. The team wants to reduce data volume by roughly 80 percent while still seeing representative samples of all request types. What should the developer configure?

A.Enable adaptive sampling in the Application Insights SDK and set a target events-per-second limit

B.Configure ingestion sampling in the Azure portal to retain 20 percent of incoming telemetry

C.Increase the TelemetryClient flush interval from 30 seconds to 5 minutes to batch events

D.Filter all events with HTTP status code 200 from the telemetry pipeline before sending

AnswerA

Adaptive sampling runs in the SDK. It monitors the outgoing telemetry rate and automatically raises or lowers the sample percentage to stay near the target rate. All operation types are sampled proportionally, so statistical trends remain meaningful even at 20 percent of raw volume. Data is reduced before transmission, lowering both network and ingestion costs.

Why this answer

Adaptive sampling in the Application Insights SDK automatically adjusts the volume of telemetry sent to the service, targeting a specified rate of events per second. By setting a target that reduces the original 80,000 events/sec to roughly 20%, the SDK will intelligently sample all request types proportionally, preserving representative data while cutting costs.

Exam trap

The trap here is that candidates confuse ingestion sampling (a portal-level fixed filter) with adaptive sampling (an SDK-level dynamic filter), assuming any sampling in the portal will suffice, but only adaptive sampling can meet the dual goals of volume reduction and representativeness across all request types.

How to eliminate wrong answers

Option B is wrong because ingestion sampling in the Azure portal is a fixed-rate filter applied after telemetry is already sent, which does not reduce network and SDK overhead, and it cannot adapt to traffic spikes or maintain representativeness across all request types. Option C is wrong because increasing the flush interval only batches events into larger payloads, reducing the number of HTTP calls but not the total number of events ingested, so it does not reduce data volume or cost. Option D is wrong because filtering all HTTP 200 status codes would discard successful requests entirely, losing critical health and performance data and violating the requirement to see representative samples of all request types.

Full explanation →

681

MCQhard

You are using Azure Cognitive Search to index documents stored in Azure Blob Storage. The indexer is failing with the error 'Data source credentials are invalid.' You have verified that the connection string for the storage account is correct. What is the most likely cause?

A.The Cognitive Search service is in a different region than the storage account.

B.The Cognitive Search service's admin key is missing.

C.The indexer configuration is missing the storage account key.

D.The storage account is behind a firewall and the Cognitive Search service IP is not allowed.

AnswerD

Azure Storage accounts can be secured with network firewalls that restrict access to specific virtual networks or IP addresses. If the storage account has a firewall enabled and the outbound IP address of the Azure Cognitive Search service (or its associated VNet if integrated) is not explicitly added to the allowed list, the connection attempt will be blocked. This results in an access denied error, as the search service is prevented from establishing a network connection to the storage account.

Why this answer

When a storage account is protected by a firewall, Azure Cognitive Search's indexer must be granted explicit network access. Even if the connection string is correct, the indexer's outbound requests will be blocked unless the storage account's firewall rules include the IP address or subnet of the Cognitive Search service. This is a common misconfiguration that results in 'Data source credentials are invalid' errors despite valid credentials.

Exam trap

The trap here is that candidates assume a valid connection string guarantees access, overlooking that network-level restrictions (firewalls, service endpoints, or private endpoints) can block the indexer's traffic even with correct credentials.

How to eliminate wrong answers

Option A is wrong because Azure Cognitive Search and Azure Blob Storage can be in different regions; cross-region indexing is fully supported and does not cause credential validation errors. Option B is wrong because the admin key is used for managing the search service itself, not for authenticating to an external data source; the indexer uses the storage account connection string, not the search service admin key. Option C is wrong because the storage account key is embedded within the connection string; if the connection string is verified as correct, the key is already present and the indexer configuration does not require a separate key field.

Full explanation →

682

MCQeasy

You are developing a solution that needs to retrieve secrets from Azure Key Vault. The solution will run as an Azure App Service managed identity. Which authentication method should you use?

A.SharedAccessSignatureCredential

B.InteractiveBrowserCredential

C.DefaultAzureCredential

D.ClientSecretCredential

AnswerC

DefaultAzureCredential offers a robust and flexible authentication strategy by attempting to authenticate using a chain of credential types in a predefined order. When deployed in Azure, it automatically prioritizes and leverages Managed Identities (system-assigned or user-assigned) associated with the hosting resource (e.g., Azure App Service, VM, Function App), eliminating the need for explicit credential management. For local development, it intelligently falls back to environment variables, Azure CLI, or Visual Studio credentials, providing a seamless experience across different environments without code changes.

Why this answer

DefaultAzureCredential is the correct choice because it automatically chains multiple authentication sources, including managed identity, environment variables, and Visual Studio credentials. When running in an Azure App Service with a managed identity enabled, DefaultAzureCredential will first attempt to authenticate using the managed identity endpoint, making it the most seamless and recommended approach for this scenario.

Exam trap

The trap here is that candidates often choose ClientSecretCredential because they think a secret is required, but they overlook that DefaultAzureCredential automatically handles managed identity authentication without needing to store any credentials.

How to eliminate wrong answers

Option A is wrong because SharedAccessSignatureCredential is used for authenticating to Azure Storage services (e.g., Blob, Queue) using a shared access signature token, not for authenticating to Azure Key Vault. Option B is wrong because InteractiveBrowserCredential requires user interaction via a browser to complete the authentication flow, which is unsuitable for a headless, automated App Service managed identity. Option D is wrong because ClientSecretCredential requires a client secret (password) to be stored and managed, which defeats the purpose of using a managed identity and introduces a security risk.

Full explanation →

683

MCQhard

A company is building a microservices application on Azure Container Instances. Each microservice needs to authenticate to Azure Key Vault to retrieve secrets. They want to avoid storing any credentials in the container images or environment variables. What should they do?

A.Use Docker secrets mounted as volumes.

B.Enable managed identity for the container group and grant it access to Key Vault.

C.Use a shared access signature (SAS) token to access Key Vault.

D.Store the Key Vault URI and a client secret in environment variables.

AnswerB

Enabling a managed identity for the Azure Container Instances (ACI) container group provisions an automatically managed identity within Azure Active Directory (Azure AD). This identity can then be granted specific role-based access control (RBAC) permissions to an Azure Key Vault, allowing the containerized application to securely retrieve secrets, keys, or certificates. This method eliminates the need for hardcoded credentials, connection strings, or client secrets within the application code or environment variables, significantly enhancing security by preventing credential exposure and simplifying credential rotation.

Why this answer

Azure Container Instances supports managed identities, allowing the container group to authenticate to Azure Key Vault without any credentials stored in the image or environment variables. By enabling a system-assigned or user-assigned managed identity on the container group and granting that identity the appropriate Key Vault access policy (e.g., 'Get' secret permission), the application can acquire an Azure AD token from the Instance Metadata Service (IMDS) endpoint and use it to retrieve secrets securely.

Exam trap

The trap here is that candidates may confuse Docker secrets (which still require credential injection at runtime) with Azure managed identities (which eliminate the need for any stored credentials), or they may incorrectly think SAS tokens can be used for Key Vault authentication, when SAS tokens are strictly for Azure Storage.

How to eliminate wrong answers

Option A is wrong because Docker secrets mounted as volumes still require the secrets to be stored in the container image or passed at runtime, which contradicts the requirement to avoid storing any credentials in the container images or environment variables. Option C is wrong because a shared access signature (SAS) token is used for delegating access to Azure Storage resources, not for authenticating to Azure Key Vault; Key Vault uses Azure AD authentication and access policies. Option D is wrong because storing the Key Vault URI and a client secret in environment variables directly violates the requirement to avoid storing credentials in environment variables, and it introduces a security risk by exposing the client secret.

Full explanation →

684

MCQmedium

An app uses Azure Event Grid to publish events. The events must be delivered to an Azure Function that processes them. Which Event Grid event delivery model should be used?

A.Pull delivery

B.Push delivery

C.Batch delivery

D.Poll delivery

AnswerB

Azure Event Grid exclusively employs a push delivery model for event distribution. With push delivery, Event Grid automatically sends events to configured subscriber endpoints as soon as they occur, without the subscriber needing to initiate a request. This server-initiated approach is fundamental to Event Grid's real-time, reactive architecture, enabling immediate invocation of services like Azure Functions, Logic Apps, or webhooks in response to state changes or actions within Azure resources or custom applications.

Why this answer

Azure Event Grid uses a push delivery model to send events to subscribers like Azure Functions. When an event occurs, Event Grid automatically forwards (pushes) the event to the configured endpoint via HTTP POST requests. This ensures near-real-time processing without the subscriber needing to poll for new events.

Exam trap

The trap here is that candidates confuse Event Grid's push model with the pull-based consumption patterns of other Azure messaging services (like Event Hubs or Service Bus), leading them to incorrectly select pull or poll delivery.

How to eliminate wrong answers

Option A is wrong because pull delivery is not a model supported by Event Grid; Event Grid always pushes events to subscribers, and pull-based consumption is used by services like Azure Event Hubs or Kafka. Option C is wrong because batch delivery is a configuration option within push delivery (allowing multiple events per HTTP request), not a separate delivery model. Option D is wrong because poll delivery is not a term used in Event Grid; polling implies the subscriber repeatedly checks for new events, which is the opposite of Event Grid's push-based architecture.

Full explanation →

685

Multi-Selecthard

You are developing a daemon application that runs on an on-premises server and must call a protected web API hosted in Azure. The API is secured with Microsoft Entra ID. The daemon cannot use a user sign-in and must authenticate as itself. You need to choose the appropriate authentication flow and configuration. Which two actions should you perform? (Choose two.)

Select 2 answers

A.Use the OAuth 2.0 client credentials flow.

B.Use the OAuth 2.0 authorization code flow with PKCE.

C.Configure the application registration with a client secret or certificate.

D.Grant delegated permissions to the API and request them at runtime.

E.Use the OAuth 2.0 implicit grant flow to obtain tokens directly.

AnswersA, C

The client credentials flow is designed for non-interactive, app-only authentication where the application authenticates as itself using its own credentials. It allows the daemon to obtain a token from Microsoft Entra ID without a user context. This is the correct flow for a daemon calling a protected API with application permissions.

Why this answer

A daemon with no user context must use the OAuth 2.0 client credentials flow, which authenticates the application itself. This flow requires a credential such as a client secret or certificate configured in the app registration. Together, these two actions allow the daemon to obtain an access token from Microsoft Entra ID and call the protected API using application permissions.

Exam trap

The trap here is mixing up interactive flows like authorization code with PKCE or implicit grant with app-only flows, when a daemon without a user must use client credentials.

Full explanation →

686

MCQmedium

An Azure App Service application has availability failures. The developer needs distributed tracing across requests and dependencies. What should be enabled?

A.Application Insights with dependency tracking

B.Storage account static website logs

C.Azure Policy compliance scan

D.Cost Management budgets only

AnswerA

Application Insights automatically collects telemetry including requests, exceptions, and traces for live applications. Its dependency tracking feature is crucial for diagnosing availability failures in an Azure App Service because it visualizes calls to external services like databases, other APIs, or storage accounts. This allows developers to pinpoint if a slowdown or failure originates within the App Service itself or from an unresponsive downstream dependency, providing a clear path to resolution and improving overall application reliability.

Why this answer

Application Insights with dependency tracking is the correct choice because it provides distributed tracing across requests and dependencies in an Azure App Service application. It automatically collects telemetry data, including end-to-end transaction details, and maps dependencies like SQL databases, HTTP calls, and Azure services, enabling developers to diagnose availability failures by correlating traces across components.

Exam trap

The trap here is that candidates may confuse general monitoring tools (like logs or compliance) with the specific need for distributed tracing, overlooking that only Application Insights with dependency tracking provides the correlation and dependency mapping required for diagnosing availability failures across requests and dependencies.

How to eliminate wrong answers

Option B is wrong because Storage account static website logs only capture HTTP request logs for static content hosted in Azure Storage, not distributed tracing across application dependencies or requests. Option C is wrong because Azure Policy compliance scan evaluates resource configurations against policies for governance and compliance, not for monitoring application performance or tracing distributed requests. Option D is wrong because Cost Management budgets only track and alert on spending, providing no telemetry or tracing capabilities for application availability or dependencies.

Full explanation →

687

MCQeasy

You are deploying a background processing job that reads messages from an Azure Storage Queue. The job must run on the same compute resources as the main web application and must not require additional deployment or monitoring overhead. Which solution should you use?

A.Deploy an Azure Function with a Queue trigger on the Consumption plan.

B.Add an Azure WebJob to the App Service that hosts the main application.

C.Create a separate Azure Container Instance to run a continuous job.

D.Use Azure Logic Apps with a recurrence trigger to poll the queue.

AnswerB

Azure WebJobs are designed to run background tasks directly within an existing Azure App Service instance, sharing the same App Service Plan's compute, memory, and network resources. This tight integration means the WebJob scales automatically with the web app's instances and incurs no additional compute costs beyond the App Service Plan itself, simplifying management and cost tracking by leveraging existing infrastructure.

Why this answer

Azure WebJobs run in the same App Service plan as the main web application, sharing compute resources without requiring separate deployment or monitoring. A WebJob with a continuous trigger can read from an Azure Storage Queue using the QueueTrigger attribute, meeting the requirement of no additional overhead.

Exam trap

The trap here is that candidates often choose Azure Functions for queue processing without considering the requirement to share compute resources with the main web application, overlooking that WebJobs are the native background processing solution within App Service.

How to eliminate wrong answers

Option A is wrong because an Azure Function on the Consumption plan runs on separate, serverless compute resources, not on the same resources as the main web application, and introduces additional deployment and monitoring overhead. Option C is wrong because a separate Azure Container Instance requires its own compute resources, deployment pipeline, and monitoring, contradicting the requirement to run on the same resources as the main app. Option D is wrong because Azure Logic Apps with a recurrence trigger is a separate, managed service that runs independently of the web application's compute resources, adding deployment and monitoring overhead.

Full explanation →

688

MCQeasy

You need to deploy a containerized application to Azure Container Instances (ACI) with a public IP address and a DNS name label. Which YAML property should you configure for the DNS name?

A.dnsNameLabel

B.containerGroupName

C.ipAddress

D.ports

AnswerA

The "dnsNameLabel" property is the correct configuration element used to assign a public, human-readable DNS name to an Azure Container Instance (ACI) container group. When specified, Azure automatically registers a DNS record in the format `dnsNameLabel.region.azurecontainer.io`, enabling external clients to access the containerized application via a stable, memorable FQDN rather than just an IP address. This is crucial for public internet accessibility.

Why this answer

The `dnsNameLabel` property in the Azure Container Instances YAML definition is used to assign a custom DNS prefix to the container group's public IP address. When combined with the Azure region's default domain suffix (e.g., `eastus.azurecontainer.io`), this creates a fully qualified domain name (FQDN) like `<dnsNameLabel>.eastus.azurecontainer.io`, allowing clients to resolve the container group via DNS without needing the raw IP address.

Exam trap

The trap here is that candidates often confuse `dnsNameLabel` with `containerGroupName` or `ipAddress`, mistakenly thinking the container group name or the IP address property itself controls the DNS label, when in fact `dnsNameLabel` is a nested property under `ipAddress` in the YAML schema.

How to eliminate wrong answers

Option B is wrong because `containerGroupName` is the logical name of the container group within Azure Resource Manager, not a DNS-related property; it does not influence the DNS label or FQDN. Option C is wrong because `ipAddress` defines the type (e.g., Public or Private) and the assignment of the IP address itself, but the DNS name label is a separate sub-property under `ipAddress` (specifically `ipAddress.dnsNameLabel`). Option D is wrong because `ports` specifies the container ports to expose (e.g., 80, 443) and their protocol (TCP/UDP), but it has no role in configuring the DNS name label.

Full explanation →

689

MCQeasy

The team is writing an Azure Function that needs to retrieve secrets from Azure Key Vault at runtime. The security policy prohibits storing client secrets, connection strings, or certificates in application settings or source code. What is the recommended approach?

A.Enable a system-assigned managed identity on the Function App and grant it Key Vault Secrets User (or Get/List access policy) permission on the vault

B.Create an App Registration, generate a client secret, store the secret in an Application Setting, and authenticate using ClientSecretCredential

C.Generate a Key Vault SAS token and embed it in the function's connection string setting

D.Use the Key Vault REST API with the vault's access key embedded in the code

AnswerA

The managed identity removes all credential management from the developer. DefaultAzureCredential automatically detects the managed identity context and requests tokens from the Azure Instance Metadata Service. No secret is ever stored anywhere the developer can access or accidentally expose.

Why this answer

A system-assigned managed identity provides a secure, credential-free way for an Azure Function to authenticate to Key Vault. Azure automatically manages the identity's lifecycle and tokens, eliminating the need to store any secrets in application settings or code. The Function App uses the managed identity to obtain an Azure AD token, which it presents to Key Vault to retrieve secrets, fully complying with the security policy.

Exam trap

The trap here is that candidates may think a client secret or SAS token is acceptable if stored in an Application Setting, but the policy explicitly prohibits storing any secrets in settings or code, making managed identity the only compliant option.

How to eliminate wrong answers

Option B is wrong because it requires storing a client secret (the App Registration's secret) in an Application Setting, which directly violates the security policy that prohibits storing client secrets in application settings or source code. Option C is wrong because Key Vault does not support SAS tokens; SAS tokens are used for Azure Storage, not Key Vault, and embedding any token in a connection string violates the policy. Option D is wrong because Key Vault does not have an 'access key'; it uses Azure AD authentication, and embedding any credential in code violates the policy.

Full explanation →

690

MCQmedium

You are designing a solution to store and serve large media files (500 MB to 2 GB) to a global audience. The files must be accessible via HTTPS with low latency. Which Azure Storage option should you use?

A.Azure Blob Storage with Azure CDN

B.Azure Queue Storage

C.Azure Files with SMB protocol

D.Azure Table Storage

AnswerA

Azure Blob Storage is highly optimized for storing massive amounts of unstructured data, including large media files, offering excellent scalability, durability, and cost-effectiveness. When combined with Azure CDN, it provides a robust solution for serving content globally by caching media at edge locations closer to users. This significantly reduces latency and improves throughput, ensuring a superior user experience for media consumption worldwide by minimizing the distance data travels.

Why this answer

Azure Blob Storage is optimized for storing large, unstructured data like media files, and integrating it with Azure CDN caches content at edge nodes worldwide, reducing latency for global users. HTTPS access is natively supported, and CDN ensures low-latency delivery by serving files from the nearest point of presence (PoP).

Exam trap

The trap here is that candidates may confuse Azure Files (which supports SMB and REST) as a viable option for global media delivery, but it lacks built-in CDN integration and is not designed for low-latency HTTPS serving to a global audience.

How to eliminate wrong answers

Option B is wrong because Azure Queue Storage is designed for asynchronous message passing between application components, not for storing or serving large files. Option C is wrong because Azure Files with SMB protocol is intended for file shares accessed via SMB (port 445) from virtual machines or on-premises systems, not optimized for global HTTPS delivery of large media files. Option D is wrong because Azure Table Storage is a NoSQL key-value store for structured data, not suitable for large binary objects like media files.

Full explanation →

691

MCQhard

Your application runs on Azure Kubernetes Service (AKS). It needs to access Azure Key Vault secrets. You want to avoid using a service principal. Which solution should you implement?

A.Mount secrets as a ConfigMap from Key Vault

B.Create a service principal and assign it to the AKS cluster

C.Deploy the Secrets Store CSI Driver with workload identity

D.Use a Helm chart to inject secrets

AnswerC

Deploying the Secrets Store CSI Driver with Azure Workload Identity is the recommended and most secure approach for AKS pods to access secrets stored in Azure Key Vault. This solution allows pods to authenticate to Azure Key Vault using an Azure Active Directory managed identity, eliminating the need for any Kubernetes Secrets or service principal credentials. The driver then projects the secrets directly into the pod's filesystem as a mounted volume, ensuring they are never exposed as environment variables or stored insecurely within Kubernetes.

Why this answer

The Secrets Store CSI Driver with workload identity allows your AKS pods to securely access Azure Key Vault secrets without managing a separate service principal. Workload identity uses Azure AD pod-managed identities or federated identity credentials to authenticate directly to Key Vault, eliminating the need for explicit service principal credentials.

Exam trap

The trap here is that candidates may confuse Helm charts or ConfigMaps as valid secret injection methods, overlooking that they lack native secure integration with Azure Key Vault and still require explicit authentication credentials.

How to eliminate wrong answers

Option A is wrong because mounting secrets as a ConfigMap from Key Vault is not a native AKS feature; ConfigMaps are designed for non-sensitive data and storing secrets in a ConfigMap would expose them in plaintext, defeating security. Option B is wrong because the question explicitly states you want to avoid using a service principal, and creating one directly contradicts that requirement. Option D is wrong because Helm charts are a packaging and deployment tool, not a mechanism for secure secret injection; they would still require a service principal or other authentication method to access Key Vault.

Full explanation →

692

MCQmedium

You are designing a solution to store large amounts of structured data that is accessed frequently and requires low-latency reads. The data must be globally distributed and support automatic failover. Which Azure storage solution should you recommend?

A.Azure Table Storage with geo-replication.

B.Azure Cosmos DB with multi-region writes and automatic failover.

C.Azure SQL Database with active geo-replication and failover groups.

D.Azure Blob Storage with read-access geo-redundant storage (RA-GRS).

AnswerB

Azure Cosmos DB is a globally distributed, multi-model database service designed for high availability and low-latency access worldwide. Its multi-region write capability allows applications to write data to any configured region, with Cosmos DB handling data replication and consistency across all regions. Combined with automatic failover, this ensures continuous availability and resilience against regional outages, making it ideal for globally distributed structured data solutions requiring stringent SLAs.

Why this answer

Azure Cosmos DB with multi-region writes and automatic failover is the correct choice because it provides globally distributed, low-latency reads and writes with automatic failover at the database level. It supports multiple consistency models and guarantees single-digit millisecond read latencies, making it ideal for frequently accessed structured data that requires global distribution and high availability.

Exam trap

The trap here is that candidates often confuse Azure Table Storage (which is a NoSQL key-value store) with Cosmos DB's Table API, but Table Storage lacks the global distribution, automatic failover, and low-latency guarantees that Cosmos DB provides, leading them to choose Option A incorrectly.

How to eliminate wrong answers

Option A is wrong because Azure Table Storage with geo-replication offers only eventual consistency and higher latency compared to Cosmos DB, and it does not support automatic failover or multi-region writes natively. Option C is wrong because Azure SQL Database with active geo-replication and failover groups is designed for relational data and provides strong consistency, but it does not offer the same low-latency global distribution and multi-region write capabilities as Cosmos DB; it also requires manual failover configuration in some scenarios. Option D is wrong because Azure Blob Storage with read-access geo-redundant storage (RA-GRS) is optimized for unstructured blob data, not structured data, and it only supports read access in the secondary region during failover, not automatic failover for writes.

Full explanation →

693

MCQmedium

You are building an Azure Logic App that must connect to a third-party CRM system using a custom API. The API requires an API key in the header of every request. You need to securely store the API key and reference it in the Logic App. Which approach should you use?

A.Store the API key in the Azure Logic App's definition file.

B.Use a parameter and a connection reference in the Logic App.

C.Store the API key in Azure Key Vault and reference it with a dynamic expression.

D.Hardcode the API key in the HTTP action.

AnswerC

Azure Key Vault is the industry-standard service for securely storing and managing secrets, keys, and certificates. By storing the API key in Key Vault, it benefits from encryption at rest, robust access policies (Azure RBAC), and auditing. Logic Apps can then securely retrieve this secret at runtime using a dynamic expression like `@keyVault('secretName')` or `@keyVault('secretUri')`, ensuring the secret is never exposed in the Logic App's definition, source control, or logs.

Why this answer

Azure Key Vault provides a secure, centralized store for secrets like API keys, and Logic Apps can reference these secrets at runtime using a dynamic expression (e.g., `@Microsoft.KeyVault(SecretUri=...)`). This avoids exposing the key in plaintext within the Logic App definition or configuration, aligning with Azure security best practices for managed identities and secret management.

Exam trap

The trap here is that candidates may confuse 'parameter and connection reference' (Option B) as secure because it separates the value from the definition, but it still stores the key in plaintext in the connection resource, whereas Key Vault is the only option that provides encryption and access control via Azure RBAC.

How to eliminate wrong answers

Option A is wrong because storing the API key directly in the Logic App's definition file (JSON workflow) exposes it in plaintext within the source code and deployment artifacts, violating security best practices. Option B is wrong because while parameters and connection references can abstract values, they still store the API key in plaintext within the Logic App's configuration or connection resource, not providing encryption at rest or access control. Option D is wrong because hardcoding the API key in the HTTP action embeds the secret directly in the workflow definition, making it visible to anyone with read access to the Logic App and impossible to rotate without modifying the workflow.

Full explanation →

694

MCQeasy

A developer is building an application that needs to store and retrieve large binary files (e.g., images, videos). The application runs on Azure Virtual Machines. Which Azure service provides the most cost-effective storage for these files?

A.Azure SQL Database

B.Azure Cosmos DB

C.Azure Files

D.Azure Blob Storage

AnswerD

Azure Blob Storage is Microsoft's object storage solution, specifically designed for storing massive amounts of unstructured data, including large binary files like images, videos, backups, and data lakes. It offers high scalability, durability, and cost-effectiveness through various access tiers (Hot, Cool, Archive), making it the optimal choice for storing and serving large binary files directly via HTTP/S. Its architecture is purpose-built for efficient handling of blobs, providing excellent performance and pricing for this workload.

Why this answer

Azure Blob Storage is designed specifically for storing massive amounts of unstructured data, such as images and videos, and offers the lowest cost per gigabyte for large binary files compared to other Azure storage options. It supports scalable, durable, and highly available storage with tiered pricing (Hot, Cool, Archive) to optimize costs based on access patterns.

Exam trap

The trap here is that candidates may confuse Azure Files (a managed file share) with Blob Storage, but Azure Files is designed for SMB-based file sharing and is not the most cost-effective option for storing large binary files at scale.

How to eliminate wrong answers

Option A is wrong because Azure SQL Database is a relational database service optimized for structured transactional data, not for storing large binary files, and it incurs higher costs per GB due to its compute and storage architecture. Option B is wrong because Azure Cosmos DB is a NoSQL database designed for globally distributed, low-latency access to structured or semi-structured data, and its storage cost is significantly higher than Blob Storage for large binary files. Option C is wrong because Azure Files provides fully managed file shares using the SMB protocol, which is suitable for shared file access but is more expensive per GB than Blob Storage and not optimized for storing massive binary objects like videos.

Full explanation →

695

MCQeasy

You need to monitor the CPU utilization of an Azure VM in real-time and set up an alert when it exceeds 90%. Which Azure Monitor feature should you use?

A.Log Analytics Workspace

B.Metrics Explorer

C.Application Insights

D.Azure Monitor for VMs

AnswerB

Metrics Explorer, an integral part of Azure Monitor, is the dedicated tool for visualizing and analyzing platform metrics emitted by Azure resources, including VM CPU utilization. It provides near real-time data with minimal latency, enabling users to interactively chart metrics, apply aggregations, and directly create metric alerts based on specific thresholds. This capability directly addresses the requirement for real-time monitoring and setting alerts on VM CPU utilization with high responsiveness.

Why this answer

Metrics Explorer is the correct Azure Monitor feature for real-time monitoring of CPU utilization on an Azure VM because it provides near real-time metric collection (typically every 1 minute) and supports alerting based on threshold conditions. It allows you to chart performance counters like Percentage CPU and configure metric alerts that trigger when the value exceeds 90%.

Exam trap

The trap here is that candidates often confuse Azure Monitor for VMs (which provides a dashboard view) with the actual alerting mechanism, or they mistakenly think Log Analytics is needed for metric alerts when Metrics Explorer handles them directly.

How to eliminate wrong answers

Option A is wrong because Log Analytics Workspace is designed for collecting and querying log data (e.g., Windows Event Logs, Syslog) using KQL, not for real-time metric monitoring or threshold-based alerts on CPU utilization. Option C is wrong because Application Insights is an Application Performance Management (APM) service focused on monitoring live web applications, not infrastructure-level metrics like VM CPU utilization. Option D is wrong because Azure Monitor for VMs (now VM Insights) provides a pre-built experience with performance charts and dependency mapping, but it relies on underlying Metrics Explorer for alerting and is not the direct feature for setting a metric alert on CPU utilization.

Full explanation →

696

MCQeasy

Your company runs a web application on Azure App Service that uses a custom domain. The application must be accessible only via HTTPS. You have already uploaded an SSL certificate for the custom domain. However, users can still access the site via HTTP. You need to enforce HTTPS redirection. What should you do?

A.Set the 'Minimum TLS Version' to 1.2.

B.Add a rewrite rule in the web.config file to redirect HTTP to HTTPS.

C.Configure the App Service to require client certificates.

D.Enable the 'HTTPS Only' setting in the App Service's TLS/SSL settings blade.

AnswerD

Enabling the 'HTTPS Only' setting in the App Service's TLS/SSL settings blade is the recommended and most efficient method for enforcing HTTPS. This platform-level configuration automatically redirects all incoming HTTP requests to their HTTPS equivalents before they even reach the application code. This ensures that all traffic is encrypted, simplifies application development by removing the need for in-app redirection logic, and provides a robust, managed solution directly from the Azure infrastructure.

Why this answer

The 'HTTPS Only' setting in the App Service's TLS/SSL settings blade enforces that all incoming requests are redirected from HTTP to HTTPS at the platform level, before any application code runs. Since you have already uploaded an SSL certificate, enabling this setting ensures that users cannot access the site via HTTP, meeting the requirement without modifying application code.

Exam trap

The trap here is that candidates may think a web.config rewrite rule (Option B) is sufficient, but Azure explicitly recommends the platform-level 'HTTPS Only' setting because it is simpler, more reliable, and works regardless of the application stack (e.g., .NET, Node.js, Python).

How to eliminate wrong answers

Option A is wrong because setting 'Minimum TLS Version' to 1.2 only enforces that incoming HTTPS connections use TLS 1.2 or higher; it does not redirect HTTP traffic to HTTPS. Option B is wrong because while a rewrite rule in web.config can redirect HTTP to HTTPS, it is an application-level solution that may not cover all scenarios (e.g., requests that bypass the rewrite module) and is less reliable than the platform-level 'HTTPS Only' setting. Option C is wrong because requiring client certificates is for mutual TLS authentication, not for enforcing HTTPS redirection.

Full explanation →

697

MCQmedium

You are building an Azure Logic App that needs to call a third-party REST API. The API requires an API key to be passed in the 'X-API-Key' header. You have stored the API key as a secret in Azure Key Vault. The Logic App uses a managed identity that has read access to the Key Vault secret. You want to retrieve the API key securely at runtime and include it in the HTTP request. Which approach should you use?

A.Use the 'Get secret' action from the Azure Key Vault connector, configured to authenticate with a managed identity. Then pass the output to the 'HTTP' action's header as 'X-API-Key'.

B.Create an API connection for the external API, providing the API key in the connection parameters. Then use that connection in the Logic App.

C.Store the API key directly in the Logic App definition's 'constants' section and reference it in the HTTP action.

D.Use the 'HTTP' action with 'Managed Identity' authentication type, and configure the external API to accept Microsoft Entra ID tokens.

AnswerA

This is the correct and most secure approach for handling API keys in Azure Logic Apps. Azure Key Vault is a dedicated service for securely storing secrets, and a Logic App's managed identity provides an automatically managed identity in Microsoft Entra ID. By granting the Logic App's managed identity 'Get' permissions on the specific secret in Key Vault, the 'Get secret' action can retrieve the API key at runtime. This dynamically retrieved value is then passed into the 'HTTP' action's header (e.g., 'X-API-Key'), ensuring the sensitive key is never hardcoded or exposed within the Logic App's definition or deployment artifacts.

Why this answer

It uses the Azure Key Vault connector's 'Get secret' action with managed identity authentication to securely retrieve the API key at runtime. The output is then passed directly into the HTTP action's 'X-API-Key' header, ensuring the secret is never exposed in the Logic App definition or logs. This approach follows the principle of least privilege and avoids hardcoding secrets.

Exam trap

The trap here is that candidates may confuse managed identity authentication on the HTTP action (which sends an Entra ID token) with using a managed identity to authenticate to Key Vault, leading them to select option D, which is technically incorrect for an API key scenario.

How to eliminate wrong answers

Option B is wrong because creating an API connection stores the API key in the connection definition, which is persisted and can be exposed if the connection is shared or exported; it also bypasses the runtime retrieval from Key Vault. Option C is wrong because storing the API key directly in the Logic App definition's 'constants' section hardcodes the secret into the workflow, violating security best practices and exposing it in source control or deployment artifacts. Option D is wrong because the 'HTTP' action with 'Managed Identity' authentication type sends a Microsoft Entra ID token, not an API key; the external API would need to support OAuth 2.0 token validation, which is not the case here—it expects a static API key in the 'X-API-Key' header.

Full explanation →

698

MCQeasy

You need to consume an Azure Cognitive Services Text Analytics API from a Python application. The API requires a subscription key. Where should you store the key to ensure security?

A.Store the key in a text file in the application directory.

B.Store the key in an environment variable on the hosting machine.

C.Use Azure AD authentication instead of a key.

D.Hardcode the key in the Python source code.

AnswerB

Storing the key in an environment variable on the hosting machine is a robust and recommended practice for managing secrets. Environment variables are loaded into the application's process at runtime, keeping the secret out of the source code and deployed files. On Azure App Service or virtual machines, these variables can be securely configured and managed by the platform, often encrypted at rest, significantly reducing the risk of unauthorized access or accidental leakage.

Why this answer

Storing the subscription key in an environment variable on the hosting machine keeps it out of source code and configuration files, reducing the risk of accidental exposure. Environment variables are a standard security best practice for secrets in cloud applications, and Azure Cognitive Services APIs require key-based authentication unless Azure AD is explicitly configured.

Exam trap

The trap here is that candidates may choose Option C (Azure AD authentication) thinking it eliminates the need for a key entirely, but the Text Analytics API does not support Azure AD out-of-the-box without additional configuration, and the question explicitly states the API requires a subscription key.

How to eliminate wrong answers

Option A is wrong because storing the key in a text file in the application directory makes it part of the deployment package, easily accessible if the file system is compromised or if the code is shared via version control. Option C is wrong because Azure AD authentication is not supported by default for the Text Analytics API; it requires additional configuration (e.g., managed identity) and is not a drop-in replacement for the subscription key in this context. Option D is wrong because hardcoding the key in Python source code exposes it to anyone with access to the codebase, including version control history, and violates the principle of separating secrets from code.

Full explanation →

699

MCQhard

Northwind Traders is building a microservices architecture on Azure Kubernetes Service (AKS). One service needs to read messages from an Azure Service Bus queue and write them to an Azure SQL database. The solution must use managed identities for authentication. The AKS cluster is integrated with Microsoft Entra ID. The development team wants to avoid managing service principals and secrets. The team has chosen to use the Azure Identity SDK for authentication. The service will run as a pod in AKS. Which approach should the team use to authenticate to Service Bus and Azure SQL Database?

A.Generate a self-signed certificate, upload it to AKS, and use ClientCertificateCredential in the code.

B.Deploy Azure AD Pod Identity (or Workload Identity) to assign a user-assigned managed identity to the pod. Use DefaultAzureCredential in the code. Grant the identity 'Listen' on Service Bus and 'Connect' on SQL Database.

C.Store Service Bus connection string and SQL connection string in Azure Key Vault. Use Key Vault SDK to retrieve them at runtime.

D.Create a service principal and store its client secret in a Kubernetes secret. Use ClientSecretCredential in the code. Assign the service principal permissions to Service Bus and SQL.

AnswerB

This is the most secure and recommended approach for microservices in AKS. Deploying Azure AD Pod Identity (or its successor, Workload Identity) allows assigning a user-assigned managed identity directly to the Kubernetes pod, eliminating the need for hardcoded credentials or secrets. DefaultAzureCredential then automatically discovers and uses this identity for authentication to Azure services like Service Bus and SQL Database, while granting specific permissions ('Listen', 'Connect') adheres to the principle of least privilege.

Why this answer

Azure AD Pod Identity (or Workload Identity) allows you to assign a user-assigned managed identity to a pod, eliminating the need to manage service principals or secrets. The DefaultAzureCredential from the Azure Identity SDK automatically uses the pod's managed identity to authenticate to Azure services. Granting the identity 'Listen' on Service Bus and 'Connect' on SQL Database provides the minimum required permissions for the service to read messages and write to the database.

Exam trap

The trap here is that candidates may confuse using Azure Key Vault for secret storage (Option C) with using managed identities for authentication, but the question explicitly requires managed identities for authentication, not just for accessing secrets.

How to eliminate wrong answers

Option A is wrong because generating a self-signed certificate and using ClientCertificateCredential still requires managing certificate lifecycle and distribution, which contradicts the requirement to avoid managing secrets and service principals. Option C is wrong because storing connection strings in Key Vault and retrieving them at runtime does not use managed identities for authentication to Service Bus and SQL Database; it still relies on connection strings, which are secrets. Option D is wrong because creating a service principal and storing its client secret in a Kubernetes secret reintroduces secret management and violates the requirement to avoid managing service principals and secrets.

Full explanation →

700

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? The design must avoid adding custom operational scripts.

A.Blob soft delete

B.Application Insights sampling

C.Private DNS zone only

D.API Management rate-limit or quota policy

AnswerD

Azure API Management (APIM) policies, specifically the `rate-limit` and `quota` policies, are designed precisely to control and manage the flow of API traffic. These policies allow developers to enforce limits on the number of API calls (rate limit) or the total bandwidth consumed (quota) within a specified time period, per subscription, per user, or per IP address. By applying these policies at various scopes, APIM can effectively throttle client requests, prevent abuse, ensure fair usage, and protect backend services from overload.

Why this answer

Azure API Management provides built-in rate-limit and quota policies that enforce throttling at the subscription level without requiring custom code. These policies allow you to define call rates (e.g., requests per second) or quotas (e.g., requests per month) per subscription key, directly protecting backend services from overuse.

Exam trap

The trap here is that candidates may confuse monitoring features (Application Insights sampling) or unrelated Azure services (Blob soft delete, Private DNS) with API throttling mechanisms, overlooking the purpose-built rate-limit and quota policies in API Management.

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, not a mechanism for throttling API clients. Option B is wrong because Application Insights sampling reduces telemetry volume for monitoring, not API request throttling. Option C is wrong because a Private DNS zone only resolves custom domain names within a virtual network and has no role in rate limiting or quota enforcement.

Full explanation →

701

MCQmedium

An application stores customer invoices in Azure Blob Storage. Deleted blobs must be recoverable for 14 days. What should be enabled? The design must avoid adding custom operational scripts.

A.Blob soft delete with a 14-day retention period

B.Archive access tier

C.Static website hosting

D.Immutable blob legal hold

AnswerA

Blob soft delete retains deleted blobs for a specified retention period, letting them be restored natively without scripts. Setting 14 days matches the recoverability requirement exactly, satisfying the constraint that no custom operational tooling be introduced. Microsoft Entra ID permissions govern restore operations.

Why this answer

Blob soft delete protects against accidental deletion by retaining deleted blobs for a specified retention period. Enabling it with a 14-day retention period allows recovery of deleted invoices within that window without custom scripts, meeting the requirement exactly.

Exam trap

The trap here is that candidates might confuse soft delete with versioning or immutable storage, but soft delete is the only option that provides a configurable retention period for recovering deleted blobs without custom code.

How to eliminate wrong answers

Option B is wrong because the Archive access tier is for cost-effective storage of infrequently accessed data, not for recovering deleted blobs. Option C is wrong because static website hosting enables serving static content from a container, not blob deletion recovery. Option D is wrong because an immutable blob legal hold prevents modification or deletion of blobs for legal purposes, but it does not provide a time-limited recovery window for already deleted blobs.

Full explanation →

702

MCQeasy

You need to provide temporary access to a file in Azure Blob Storage for a duration of one hour. The solution must not require authentication. What should you generate?

A.Storage account key.

B.Enable anonymous public read access on the container.

C.A user delegation key.

D.A shared access signature (SAS) with read permission and an expiration time of one hour.

AnswerD

A Shared Access Signature (SAS) is the ideal solution for providing temporary, delegated access to specific Azure Storage resources, such as a single blob. By configuring it with read permission and a one-hour expiration time, you grant precisely the required access without exposing your storage account key or making the resource permanently public. The SAS token provides a secure, time-limited URI that can be shared with the intended recipient, fulfilling all requirements.

Why this answer

A shared access signature (SAS) with read permission and a one-hour expiration provides time-limited, delegated access to a specific blob without requiring authentication. The SAS token is appended to the URL and grants the specified permissions for the defined duration, meeting the requirement of temporary access without authentication.

Exam trap

The trap here is that candidates often confuse a SAS with a storage account key or user delegation key, mistakenly thinking those provide temporary access without authentication, when in fact they are secrets used to generate SAS tokens or require authentication themselves.

How to eliminate wrong answers

Option A is wrong because a storage account key provides full administrative access to the entire storage account and never expires, which violates the requirement for temporary access and no authentication. Option B is wrong because enabling anonymous public read access on the container makes the blob permanently accessible to anyone without any time limit, failing the one-hour duration requirement. Option C is wrong because a user delegation key is used to sign a SAS with Azure AD credentials, but it still requires authentication to obtain and does not directly provide access without authentication.

Full explanation →

703

MCQmedium

You are migrating an on-premises .NET Framework app to Azure. The app uses Windows authentication and requires persistent storage. You want to minimize rework. Which Azure compute service should you choose?

A.Azure Spring Apps

B.Azure Functions

C.Azure Container Instances

D.Azure App Service on Windows

AnswerD

Azure App Service on Windows is an ideal platform for migrating existing .NET Framework web applications, offering a fully managed environment that natively supports IIS and the full .NET Framework runtime. It provides seamless integration with services like Azure Files for persistent storage, allowing applications to retain their file system dependencies without significant code changes. Furthermore, App Service on Windows inherently supports Windows authentication, which is crucial for many enterprise .NET Framework applications, making it a direct and efficient lift-and-shift target.

Why this answer

Azure App Service on Windows (D) supports Windows authentication natively via its built-in integration with Azure Active Directory and on-premises Active Directory through Azure AD Domain Services or hybrid identity setups. It also provides persistent storage options like Azure Files or blob storage attached to the web app, minimizing rework by allowing the existing .NET Framework app to run with minimal code changes in a Platform-as-a-Service (PaaS) environment.

Exam trap

The trap here is that candidates often choose Azure Functions or Container Instances for their 'modern' appeal, overlooking the specific requirement for Windows authentication and minimal rework, which Azure App Service on Windows uniquely satisfies without forcing a rewrite or containerization.

How to eliminate wrong answers

Option A is wrong because Azure Spring Apps is designed for Java Spring Boot microservices, not for .NET Framework apps, and does not support Windows authentication natively. Option B is wrong because Azure Functions is a serverless compute service optimized for event-driven, stateless workloads; it lacks native support for Windows authentication and persistent storage without significant rework (e.g., using external storage accounts). Option C is wrong because Azure Container Instances runs containers on Linux or Windows but requires containerizing the app, which introduces rework, and does not provide built-in Windows authentication or persistent storage without manual configuration.

Full explanation →

704

MCQhard

Your application uses Azure Service Bus topics. You need to ensure that messages are processed in the order they were sent within a session. What must you configure?

A.Enable duplicate detection.

B.Enable partitioning on the topic.

C.Enable sessions on the topic and set the SessionId property on messages.

D.Set the MessageId property to a GUID.

AnswerC

Enabling sessions on an Azure Service Bus topic and subsequently setting the SessionId property on messages is the correct mechanism to ensure ordered delivery and processing of related messages. When sessions are active, all messages sharing the same SessionId are guaranteed to be delivered to a single receiver in the exact First-In, First-Out (FIFO) order in which they were sent. This is essential for scenarios requiring sequential processing of a message stream, such as processing a series of steps for a single customer order.

Why this answer

Azure Service Bus sessions provide strict message ordering and exactly-once processing within a session. By enabling sessions on the topic and setting the SessionId property on each message, all messages with the same SessionId are processed in FIFO order, ensuring they are received in the exact sequence they were sent.

Exam trap

The trap here is that candidates often confuse duplicate detection (MessageId) with session-based ordering (SessionId), or assume partitioning (which improves throughput) also guarantees order, when in fact it can break ordering across partitions.

How to eliminate wrong answers

Option A is wrong because duplicate detection prevents duplicate messages from being accepted within a specified time window, but it does not enforce ordering. Option B is wrong because partitioning distributes messages across multiple message brokers for scalability, which can break ordering guarantees. Option D is wrong because the MessageId property is used for duplicate detection, not for maintaining message order within a session.

Full explanation →

705

MCQeasy

A company deploys a web application to Azure App Service. They want to deploy a new version of the app with zero downtime and the ability to quickly roll back if needed. Which deployment feature should they use?

A.Auto-scaling

B.Deployment slots

C.Traffic Manager

D.Application Insights

AnswerB

Deployment slots in Azure App Service provide distinct environments for different versions of your application, such as staging and production. They allow you to deploy a new version to a non-production slot, warm it up, and then instantly swap it with the production slot, effectively achieving zero-downtime deployments. If issues arise post-swap, an immediate rollback to the previous production version is possible by swapping back, making them ideal for safe, continuous delivery.

Why this answer

Deployment slots are separate, live environments within Azure App Service that allow you to stage a new version of your app, perform validation, and then swap it into production with zero downtime. The swap operation ensures all traffic is redirected instantly, and if issues arise, you can immediately swap back to the previous slot for a quick rollback.

Exam trap

The trap here is that candidates often confuse Traffic Manager (a global load balancer) with deployment slots, thinking DNS-level routing provides the same zero-downtime swap within a single App Service, but Traffic Manager cannot swap application versions or configurations within the same app.

How to eliminate wrong answers

Option A is wrong because auto-scaling adjusts the number of instances based on load, not the version of the application being deployed; it does not provide zero-downtime deployment or rollback capabilities. Option C is wrong because Traffic Manager is a DNS-based traffic routing service that distributes traffic across different regions or endpoints, not a feature for deploying new versions of an app within a single App Service instance with zero downtime and rollback. Option D is wrong because Application Insights is a monitoring and diagnostics service that tracks application performance and usage, not a deployment mechanism.

Full explanation →

706

MCQmedium

You need to upload a large file (10 GB) to Azure Blob Storage with the ability to pause and resume the upload. Which approach should you use?

A.Use a single Put Blob operation

B.Use the Azure Portal to upload the file

C.Use AzCopy with the /SyncCopy parameter

D.Use the Azure Storage SDK to upload block blobs in parallel

AnswerD

The Azure Storage SDK provides the most robust and efficient method for uploading large files like 10 GB to block blobs. It automatically handles breaking the large file into smaller blocks, uploading these blocks in parallel using Put Block operations, and then committing them with a Put Block List operation. This approach enables resumable uploads, significantly improves performance by utilizing available bandwidth, and ensures reliability for very large files by managing individual block transfers.

Why this answer

Uploading a large file (10 GB) to Azure Blob Storage with pause/resume capability requires breaking the file into blocks and uploading them in parallel using the Azure Storage SDK. The SDK supports block blob operations, allowing you to track progress, retry failed blocks, and resume from the last committed block. A single Put Blob operation cannot handle files larger than 5 GB, and neither the Azure Portal nor AzCopy with /SyncCopy provides programmatic pause/resume control.

Exam trap

The trap here is that candidates often confuse AzCopy's resume capability with the need for programmatic control, but the question specifically requires the ability to pause and resume programmatically, which only the SDK provides through block-level management.

How to eliminate wrong answers

Option A is wrong because a single Put Blob operation has a maximum size limit of 5 GB for a single upload, so it cannot handle a 10 GB file. Option B is wrong because the Azure Portal has a file size limit of approximately 1 GB for direct uploads and does not support pause/resume functionality. Option C is wrong because AzCopy's /SyncCopy parameter is used for copying blobs between storage locations, not for uploading files with pause/resume; AzCopy does support resume for uploads via its own mechanism, but /SyncCopy is specifically for incremental copy, not upload control.

Full explanation →

707

MCQmedium

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

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

B.Deploy directly to production during business hours

C.Disable health checks

D.Restart the App Service plan before each deployment

AnswerA

Deploying to a staging slot allows the new version of the document rendering job to be thoroughly tested and validated in an environment identical to production, without affecting live users. Once health checks pass and functional tests confirm stability, an atomic slot swap seamlessly redirects traffic to the pre-warmed staging slot. This process minimizes downtime, provides a quick rollback option, and ensures a robust, validated deployment before impacting production traffic.

Why this answer

Deploying to a staging slot allows the new version of the app to be fully initialized and validated via health checks before traffic is routed to it. The swap operation in Azure App Service moves the production traffic to the staging slot without any downtime, as the slots share the same front-end and the swap is atomic. This directly addresses the 502 errors caused by incomplete deployments and ensures zero-downtime release with validation.

Exam trap

The trap here is that candidates may think disabling health checks or restarting the plan solves intermittent errors, but the real issue is the lack of a safe staging environment for validation, which deployment slots directly provide.

How to eliminate wrong answers

Option B is wrong because deploying directly to production during business hours does not provide any validation before traffic hits the new code, and it risks exposing users to 502 errors if the deployment is incomplete or unhealthy. Option C is wrong because disabling health checks removes the ability to detect that the new deployment is returning 502 errors, which would allow unhealthy instances to serve traffic and worsen the issue. Option D is wrong because restarting the App Service plan before each deployment does not provide a staging environment for validation, and it causes downtime for all apps in the plan, contradicting the zero-downtime requirement.

Full explanation →

708

MCQhard

A team develops an Azure Functions app that processes IoT telemetry. They notice cold start latency is impacting performance. The function uses the Consumption plan. Which action reduces cold starts most effectively?

A.Use Durable Functions for long-running workflows

B.Change to Premium plan with pre-warmed instances

C.Increase the function timeout to maximum

D.Use a dedicated App Service plan

AnswerB

The Azure Functions Premium plan is specifically engineered to eliminate cold starts by providing pre-warmed instances. This plan continuously keeps a specified number of instances active and ready to process requests, ensuring that new invocations do not incur the latency associated with starting up a new host or loading function code. It offers enhanced performance, VNet connectivity, and predictable scaling, making it ideal for latency-sensitive applications like IoT processing.

Why this answer

The Consumption plan for Azure Functions can cause cold start latency because the function app is deallocated after a period of inactivity. Changing to the Premium plan with pre-warmed instances keeps a specified number of instances always running and ready to handle requests, eliminating the cold start delay for those instances. This is the most effective action among the options to reduce cold starts.

Exam trap

The trap here is that candidates often confuse the function timeout setting (which controls execution duration) with the cold start issue, or they think that Durable Functions inherently solve performance problems, when in fact they are for workflow orchestration and do not address cold starts.

How to eliminate wrong answers

Option A is wrong because Durable Functions are designed for orchestrating long-running workflows and stateful processes, not for reducing cold start latency; they actually run on the same underlying plan and can themselves experience cold starts. Option C is wrong because increasing the function timeout (up to 10 minutes for the Consumption plan) only affects how long a function can run before being terminated, not the initial startup delay of a cold instance. Option D is wrong because while a dedicated App Service plan does eliminate cold starts by keeping the app always running, it is not the most effective choice compared to the Premium plan with pre-warmed instances, as the Premium plan offers the same benefit with additional features like virtual network integration and unlimited execution duration, and is specifically designed for this scenario.

Full explanation →

709

MCQmedium

You need to grant a user the ability to read and write blobs in a specific container for 24 hours. The solution must use delegated access without exposing the storage account key. What should you use?

A.Storage account access key

B.Account shared access signature (SAS)

C.Service shared access signature (SAS)

D.User delegation shared access signature (SAS)

AnswerD

A User delegation SAS is the most secure and recommended method for granting delegated access to Azure Storage resources, as it is signed with an Azure AD credential. This SAS token allows permissions to be granted based on Azure RBAC roles assigned to the user or service principal, ensuring adherence to the principle of least privilege. It eliminates the need to distribute or manage storage account keys, significantly enhancing security for user-specific access to blobs.

Why this answer

A user delegation SAS is secured with Azure AD credentials and is the only SAS type that uses delegated authorization without exposing the storage account key. It allows you to grant granular, time-limited access (e.g., 24 hours) to a specific container for read and write operations, meeting the requirement exactly.

Exam trap

The trap here is that candidates often confuse a service SAS (which is scoped to a single service like Blob) with a user delegation SAS, but the key differentiator is that a user delegation SAS uses Azure AD for signing, not the account key.

How to eliminate wrong answers

Option A is wrong because using the storage account access key directly exposes the key, violating the requirement to avoid exposing it. Option B is wrong because an account SAS is signed with the storage account key, which also exposes the key and is not delegated. Option C is wrong because a service SAS is also signed with the storage account key, not with Azure AD credentials, and thus does not provide delegated access.

Full explanation →

710

Multi-Selectmedium

You are developing a solution that uses Azure Functions to process events from Azure Event Grid. The function must handle events reliably. Which TWO options should you implement?

Select 2 answers

A.Use Durable Functions for orchestration.

B.Enable retry policy on the Event Grid subscription.

C.Implement manual checkpointing in the function code.

D.Configure a dead-letter destination for undelivered events.

E.Use a queue trigger instead of an Event Grid trigger.

AnswersB, D

Enabling a retry policy on the Event Grid subscription is a fundamental mechanism for handling transient failures when delivering events to the Azure Function. This policy automatically reattempts delivery to the endpoint if the function returns an HTTP error (e.g., 4xx or 5xx), ensuring that temporary issues like network glitches or service unavailability do not result in lost events. Configuring appropriate retry attempts and backoff intervals significantly enhances the reliability of event processing.

Why this answer

Event Grid subscriptions support automatic retry policies that can be configured to retry event delivery on transient failures, ensuring reliable processing. Option D is correct because a dead-letter destination (e.g., a storage blob) captures events that cannot be delivered after exhausting retries, preventing data loss and enabling later analysis.

Exam trap

The trap here is that candidates often confuse Event Grid's built-in retry and dead-lettering with Durable Functions or manual checkpointing, assuming they need to implement custom reliability mechanisms when Azure already provides them natively.

Full explanation →

711

MCQmedium

Refer to the exhibit. A developer runs this Azure CLI command to set an app setting for a web app. What is the impact on the web app?

A.The command fails because the password is provided in plaintext.

B.The setting is available immediately without restart.

C.The web app restarts to apply the new setting.

D.The setting is stored in a local configuration file.

AnswerC

When an application setting is modified for an Azure App Service, the platform automatically triggers a restart of the web app instance(s). This restart is crucial because it ensures that the updated configuration, which is exposed to the application as environment variables, is properly loaded into the application's runtime process. Without this restart, the running application would continue to use the old, cached environment variables, preventing the new setting from being applied.

Why this answer

When you use the Azure CLI command `az webapp config appsettings set` to modify an app setting for a web app, Azure App Service automatically triggers a restart of the web app to apply the new setting. This is because app settings are injected into the application's environment at startup, and changes require a fresh process to pick them up. Option C correctly identifies this behavior.

Exam trap

The trap here is that candidates may assume app settings are hot-reloaded without a restart (like in some local development frameworks), but Azure App Service requires a restart to apply environment-level configuration changes.

How to eliminate wrong answers

Option A is wrong because the Azure CLI command accepts plaintext passwords in the command line; while not a security best practice, it does not cause the command to fail. Option B is wrong because app settings are not applied immediately without restart; the web app must restart to reload the environment variables. Option D is wrong because app settings are stored in Azure App Service's configuration store, not in a local configuration file on the web app instance.

Full explanation →

712

MCQeasy

A background worker retrieves a message from Azure Queue Storage and begins processing. The processing logic takes longer than the configured visibility timeout. Before the worker finishes, the timeout expires. What happens to the message?

A.The message becomes visible again in the queue and another worker can dequeue it

B.The message is permanently deleted because the worker already dequeued it

C.The message moves to a dead-letter queue after the visibility timeout expires

D.Processing continues uninterrupted; the visibility timeout applies only to the initial retrieval window

AnswerA

This is the core at-least-once delivery guarantee. The visibility timeout is a lease, not a lock. When the lease expires, the queue re-exposes the message. To prevent double-processing, the worker should call UpdateMessage to extend the timeout, or ensure processing is idempotent.

Why this answer

When the visibility timeout expires, the message becomes visible again in the queue because Azure Queue Storage uses a lease-based mechanism. The worker that dequeued the message loses its exclusive visibility lease, allowing another worker to dequeue and process the same message. This ensures at-least-once delivery semantics, preventing message loss if a worker fails or takes too long.

Exam trap

The trap here is that candidates assume the dequeue operation permanently locks or deletes the message, but Azure Queue Storage only hides it temporarily, and the worker must explicitly delete it to prevent reprocessing.

How to eliminate wrong answers

Option B is wrong because Azure Queue Storage does not permanently delete a message after dequeue; it only hides it for the visibility timeout period, and the message must be explicitly deleted by the worker after successful processing. Option C is wrong because messages are moved to a dead-letter queue only when they exceed the maximum dequeue count (e.g., after being dequeued but not deleted multiple times), not simply upon visibility timeout expiry. Option D is wrong because the visibility timeout applies to the entire processing window; if the worker does not update or delete the message before the timeout, the message becomes visible again, and processing can be interrupted by another worker dequeuing it.

Full explanation →

713

MCQmedium

A developer is implementing least-privilege storage access. 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.Disable authentication for the target resource

C.Store a client secret in source control

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

AnswerD

Enabling managed identity for an Azure-hosted application provides an automatically managed identity in Azure Active Directory (Azure AD), allowing the application to authenticate to Azure services securely without needing to store or manage any credentials in code or configuration. By then granting only the necessary, least-privilege access to the target resource via Azure RBAC, the application adheres to security best practices, minimizing the attack surface and simplifying credential management.

Why this answer

Azure Managed Identity provides an automatically managed identity in Azure AD that allows the App Service to authenticate to any service supporting Azure AD authentication without storing any credentials. By granting the managed identity only the specific permissions required (least-privilege) on the target storage resource (e.g., Storage Blob Data Reader), the application avoids stored credentials and eliminates the need for custom operational scripts. This aligns with the principle of zero standing credentials and is the recommended approach for Azure App Service.

Exam trap

The trap here is that candidates may think storing a client secret in source control (Option C) is acceptable if the repository is private, but the question explicitly requires avoiding stored credentials, and any secret in source control is a security risk that violates the principle of credentialless access.

How to eliminate wrong answers

Option A is wrong because using a shared administrator account violates least-privilege (grants excessive permissions) and requires storing credentials, which contradicts the requirement to avoid stored credentials. Option B is wrong because disabling authentication for the target resource removes all access control, exposing the resource to unauthorized access and violating security best practices. Option C is wrong because storing a client secret in source control introduces a security risk (credential leak) and requires managing a secret, which does not avoid stored credentials and adds operational overhead.

Full explanation →

714

MCQhard

Refer to the exhibit. You run this KQL query in Azure Resource Graph Explorer. The query returns no results. What is the most likely reason?

A.The 'contains' operator is case-sensitive.

B.The query must specify a subscription filter.

C.The 'where' clause must use '== ' instead of '=='.

D.The resource type is incorrect; it should be 'microsoft.insights/components' in lowercase.

AnswerD

Azure Resource Graph queries demand precise casing for resource types to ensure accurate identification and retrieval of resources. The correct and canonical resource type for Application Insights components is 'microsoft.insights/components', which is entirely in lowercase. If the query specifies a resource type with any deviation in casing, such as 'Microsoft.Insights/Components' or 'microsoft.insights/Components', it will fail to match any existing resources, resulting in an empty query output. This strict case-sensitivity is fundamental for correct resource targeting in ARG.

Why this answer

The KQL query uses the resource type 'Microsoft.Insights/Components' with mixed case, but Azure Resource Graph Explorer requires resource types to be specified in all lowercase. The correct type is 'microsoft.insights/components'. When the case does not match, the query returns no results because Azure Resource Graph performs a case-sensitive match on the 'type' property.

Exam trap

The trap here is that candidates often assume Azure resource types are case-insensitive in queries, but Azure Resource Graph enforces exact lowercase matching for the 'type' property, leading to empty results when mixed case is used.

How to eliminate wrong answers

Option A is wrong because the 'contains' operator in KQL is case-insensitive by default, so case sensitivity is not the issue here. Option B is wrong because Azure Resource Graph queries do not require a subscription filter; they can run across all accessible subscriptions without explicit filtering. Option C is wrong because the '==' operator is the correct equality operator in KQL; the syntax '== ' (with a trailing space) is not valid and would cause a syntax error, not a silent empty result.

Full explanation →

715

MCQmedium

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

A.Deployment slots

B.Backup and restore

C.App Service access restrictions

D.Always On only

AnswerA

Azure App Service deployment slots are live apps with their own hostnames, providing distinct environments for different versions of your application. They enable staging new code, performing quality assurance, and warming up instances before swapping them into production. This mechanism facilitates zero-downtime deployments and allows for easy rollbacks by swapping back to a previous slot.

Why this answer

Deployment slots are the correct Azure App Service feature for staging and production environments with traffic swapping. They allow you to deploy a new version to a staging slot, warm it up (e.g., by sending requests or using auto-swap with warm-up), and then swap the slot's traffic with the production slot, ensuring zero-downtime deployment and validation before going live.

Exam trap

The trap here is that candidates might confuse 'Always On' with keeping the app warm for swapping, but Always On only prevents idle shutdown and does not provide separate environments or traffic management.

How to eliminate wrong answers

Option B (Backup and restore) is wrong because it is designed for disaster recovery and data preservation, not for staging or traffic swapping between environments. Option C (App Service access restrictions) is wrong because it controls inbound network access via IP rules or service endpoints, not environment separation or deployment swapping. Option D (Always On only) is wrong because it keeps the app loaded to prevent cold starts, but it does not provide separate environments or the ability to warm up a new version before swapping traffic.

Full explanation →

716

Multi-Selecteasy

Which TWO actions can help you reduce latency for a globally distributed web application? (Choose two.)

Select 2 answers

A.Use Azure Application Gateway with Web Application Firewall

B.Scale up the App Service plan to a higher tier

C.Use Azure Traffic Manager with performance routing

D.Enable multi-region writes on Azure Cosmos DB

E.Use Azure Front Door to route traffic to the nearest region

AnswersC, E

Azure Traffic Manager is a DNS-based traffic load balancer that distributes incoming user requests across multiple Azure regions or external endpoints. When configured with performance routing, it intelligently directs users to the endpoint with the lowest latency, typically by resolving the DNS query to the closest available Azure region based on the user's DNS resolver location. This approach effectively minimizes the network round-trip time for users accessing a globally distributed application, significantly reducing perceived latency.

Why this answer

Azure Traffic Manager with performance routing directs user traffic to the closest endpoint based on the lowest network latency, reducing response times for globally distributed users. Option E is correct because Azure Front Door uses anycast and global edge points of presence (PoPs) to route traffic to the nearest region, providing both latency reduction and application acceleration.

Exam trap

The trap here is that candidates confuse regional services like Application Gateway with global traffic management solutions, or mistakenly think scaling up or multi-region writes alone reduce latency without a routing mechanism.

Full explanation →

717

MCQhard

Your application uses Azure Blob Storage to store images. You need to automatically move blobs older than 30 days to the Cool tier and delete blobs older than 365 days. What should you implement?

A.Azure Automation runbook on a schedule

B.Azure Logic Apps with recurrence trigger

C.Azure Blob Storage lifecycle management policy

D.Azure Event Grid subscription with blob created event

AnswerC

Azure Blob Storage lifecycle management policies provide a native, declarative, and cost-effective way to automatically transition blobs to cooler access tiers (e.g., Hot to Cool, Cool to Archive) or delete them after a specified period. These policies are configured directly on the storage account and apply rules based on blob age, last modified time, or other conditions, eliminating the need for custom code or external services. This ensures optimal storage costs by moving less frequently accessed data to cheaper tiers.

Why this answer

Azure Blob Storage lifecycle management policies allow you to define rules that automatically transition blobs to cooler tiers (e.g., Cool) after a specified number of days and delete them after a different number of days. This is the native, cost-effective, and fully managed solution for automating tier transitions and deletions based on blob age, without requiring external compute or orchestration services.

Exam trap

The trap here is that candidates often over-engineer the solution by choosing Azure Automation or Logic Apps for scheduled tasks, not realizing that Azure Blob Storage has a built-in, serverless lifecycle management feature that directly handles age-based tiering and deletion without any external compute or orchestration.

How to eliminate wrong answers

Option A is wrong because Azure Automation runbooks require a dedicated Azure Automation account, incur additional costs, and introduce unnecessary complexity and latency for a task that is natively supported by Blob Storage lifecycle management. Option B is wrong because Azure Logic Apps with a recurrence trigger would need custom code to enumerate blobs, check their age, and perform tier changes or deletions, which is inefficient, error-prone, and not the recommended approach for storage-level automation. Option D is wrong because an Event Grid subscription with a blob created event only triggers on new blob creation, not on the passage of time, and cannot enforce age-based lifecycle rules for existing blobs.

Full explanation →

718

MCQeasy

A company uses Azure Logic Apps to automate business processes. They need to call an external REST API that requires OAuth 2.0 client credentials grant. Which connector should they use with minimal configuration?

A.HTTP connector

B.HTTP + Swagger connector

C.Azure Functions connector

D.Custom connector

AnswerA

The HTTP connector in Azure Logic Apps is the most direct and efficient way to interact with any REST API, especially when specific authentication methods like OAuth 2.0 client credentials are required. It provides built-in support for various authentication types, including Microsoft Entra ID (OAuth), allowing for straightforward configuration of client ID, client secret, and resource URI without needing to manually manage token acquisition or refresh logic. This makes it ideal for securely calling external APIs that protect their endpoints with standard OAuth 2.0 flows.

Why this answer

The HTTP connector in Azure Logic Apps supports OAuth 2.0 client credentials grant natively with minimal configuration. You can directly set the authentication type to 'Active Directory OAuth' and provide the tenant ID, client ID, client secret, and audience/resource URI. This avoids the need for custom code or additional connectors.

Exam trap

The trap here is that candidates often overthink and choose a custom connector or Swagger-based option, not realizing the built-in HTTP connector already supports OAuth 2.0 client credentials with minimal setup.

How to eliminate wrong answers

Option B (HTTP + Swagger connector) is wrong because it is used when you have an OpenAPI (Swagger) definition to import, adding unnecessary overhead for a simple OAuth 2.0 call. Option C (Azure Functions connector) is wrong because it is designed to invoke Azure Functions, not to call external REST APIs with OAuth 2.0 client credentials. Option D (Custom connector) is wrong because it requires creating a custom API connector with a Swagger definition, which involves more configuration than the built-in HTTP connector's direct OAuth support.

Full explanation →

719

MCQmedium

Your company uses Azure Key Vault to manage encryption keys for data at rest in Azure Storage. You need to ensure that the storage account uses a customer-managed key (CMK) stored in Key Vault. Additionally, you need to periodically rotate the key automatically. Which configuration should you implement?

A.Create a key in Key Vault, assign the storage account's managed identity access to that key, and configure a Key Vault rotation policy to automatically rotate the key regularly

B.Enable soft-delete and purge protection on the Key Vault to allow key recovery during rotation

C.Use Azure Key Vault's default key (system-managed) and rely on built-in rotation

D.Manually rotate the key every 90 days by generating a new version and updating the storage account

AnswerA

This option correctly outlines the steps for implementing customer-managed keys with automatic rotation. Creating a key in Key Vault establishes customer ownership, while assigning the storage account's managed identity provides secure, credential-less access to the key. Crucially, configuring a Key Vault key rotation policy automates the generation of new key versions according to a defined schedule, ensuring compliance with the 'automatically rotate' requirement without manual intervention.

Why this answer

It combines the three essential elements for using a customer-managed key (CMK) with automatic rotation in Azure Key Vault. First, you must create a key in Key Vault (not use the default system-managed key). Second, the storage account's managed identity must be granted 'Get', 'Unwrap Key', and 'Wrap Key' permissions on that key so it can encrypt/decrypt the storage account's root key.

Third, you configure a Key Vault rotation policy (using the Azure Key Vault key rotation feature) to automatically create new key versions on a schedule (e.g., every 90 days), which the storage account automatically picks up without manual intervention.

Exam trap

The trap here is that candidates often confuse enabling soft-delete/purge protection (which is required for CMK but does not enable rotation) with the actual rotation policy configuration, or they assume that system-managed keys can be used when the question explicitly requires a customer-managed key.

How to eliminate wrong answers

Option B is wrong because soft-delete and purge protection are prerequisites for Key Vault (especially when using CMK with Azure Storage) but they do not enable automatic rotation; they only protect against accidental or malicious key deletion. Option C is wrong because Azure Key Vault's default key is a system-managed key (Microsoft-managed), not a customer-managed key; the question explicitly requires a CMK, and system-managed keys cannot be rotated on a custom schedule. Option D is wrong because manual rotation every 90 days does not meet the requirement for automatic rotation; it also introduces operational overhead and risk of human error, and the storage account must be updated each time a new key version is created.

Full explanation →

720

MCQeasy

A developer is building an app that uses Azure Cognitive Services Text Analytics. The app needs to detect the language of text input. Which Azure SDK method should be called?

A.DetectLanguage

B.ExtractKeyPhrases

C.AnalyzeSentiment

D.RecognizeEntities

AnswerA

The DetectLanguage operation within Azure AI Language (formerly Text Analytics) is specifically designed to identify the primary language of a given input text. It analyzes the linguistic patterns and vocabulary to return a standardized language code, such as 'en' for English or 'es' for Spanish, along with a confidence score. This functionality is crucial for applications that need to process multilingual content or route text to language-specific models for further analysis.

Why this answer

The correct method is `DetectLanguage` because the Azure Cognitive Services Text Analytics API provides a dedicated operation for identifying the language of input text. This method returns the detected language along with a confidence score, making it the appropriate choice for the requirement of detecting language from text input.

Exam trap

The trap here is that candidates may confuse the purpose of Text Analytics methods, mistakenly selecting `ExtractKeyPhrases` or `AnalyzeSentiment` because they assume language detection is part of those operations, rather than recognizing it as a separate, dedicated API method.

How to eliminate wrong answers

Option B (ExtractKeyPhrases) is wrong because it is used to extract key phrases from text, not to detect the language. Option C (AnalyzeSentiment) is wrong because it analyzes the sentiment (positive, negative, neutral) of text, not the language. Option D (RecognizeEntities) is wrong because it identifies and categorizes entities (e.g., people, places, organizations) in text, not the language.

Full explanation →

721

MCQhard

You have an Azure Storage account configured as shown in the exhibit. You need to ensure that all traffic to the storage account uses HTTPS. Which Azure CLI command should you run next?

A.az storage account create --name mystorageaccount --resource-group myResourceGroup --https-only true

B.az storage account update --name mystorageaccount --resource-group myResourceGroup --secure-transfer-required true

C.az storage account update --name mystorageaccount --resource-group myResourceGroup --enable-https-traffic-only true

D.az storage account update --name mystorageaccount --resource-group myResourceGroup --https-only true

AnswerD

This command is correct because `az storage account update` is the appropriate command to modify an existing Azure Storage account. The `--https-only true` parameter is the precise and officially recognized flag in the Azure CLI for enforcing that all requests to the storage account must use HTTPS. This action successfully disables unencrypted HTTP access, ensuring all data in transit to and from the storage account is encrypted, aligning with robust security practices.

Why this answer

The `az storage account update` command with the `--https-only true` parameter enforces HTTPS for all traffic to the storage account by setting the `supportsHttpsTrafficOnly` property to true. This is the specific Azure CLI parameter that controls this setting, and it must be applied after account creation. The command directly meets the requirement to ensure all traffic uses HTTPS.

Exam trap

The trap here is that candidates often confuse the `--https-only` parameter with `--secure-transfer-required` or `--enable-https-traffic-only`, which are not valid Azure CLI parameters for the `az storage account update` command, leading them to choose incorrect options that sound plausible but do not exist in the CLI syntax.

How to eliminate wrong answers

Option A is wrong because `az storage account create` is used to create a new storage account, not to update an existing one, and the `--https-only` parameter is not valid for the create command (the correct create parameter is `--https-only` but it's not supported; the create command uses `--enable-https-traffic-only`). Option B is wrong because `--secure-transfer-required` is not a valid parameter for `az storage account update`; this property is set via the Azure portal or ARM template but not directly via this CLI parameter. Option C is wrong because `--enable-https-traffic-only` is not a valid parameter for `az storage account update`; the correct parameter is `--https-only`.

Full explanation →

722

MCQhard

You need to upload large files (up to 100 GB) to Azure Blob Storage from a web application. The upload must be resilient to network failures and support pausing/resuming. Which approach should you use?

A.Upload the blob as a single PUT operation.

B.Use block blob with multiple blocks and parallel upload.

C.Use append blob.

D.Use AzCopy from the server.

AnswerB

Using block blobs with multiple blocks and parallel upload is the correct and recommended approach for uploading large files like 100 GB. This method involves breaking the large file into smaller, manageable blocks, which are then uploaded independently and potentially in parallel using `Put Block` operations. Once all blocks are successfully uploaded, a `Put Block List` operation commits them in the correct sequence to form the complete blob, providing robust resumability, retry capabilities, and significantly improved upload performance for very large files.

Why this answer

Block blobs support uploading large files (up to ~4.75 TB) by splitting the file into multiple blocks, uploading them in parallel for speed, and committing the block list atomically. This approach provides resilience to network failures (individual blocks can be retried) and supports pausing/resuming by tracking which blocks have been uploaded.

Exam trap

The trap here is that candidates confuse append blobs with block blobs, thinking append blobs support arbitrary uploads, but append blobs only allow data to be added to the end and cannot be used for random-access or parallel uploads.

How to eliminate wrong answers

Option A is wrong because a single PUT operation is limited to 5 GB (or 256 MB for page blobs), cannot handle 100 GB files, and provides no resilience or pause/resume capability. Option C is wrong because append blobs are designed for append-only operations (e.g., logging), not for uploading large files; they do not support parallel uploads or efficient pause/resume. Option D is wrong because AzCopy is a command-line tool meant for server-side or scripted transfers, not for direct use from a web application; it cannot be integrated into a web app's client-side upload flow.

Full explanation →

723

MCQmedium

You manage an API in Azure API Management. The API response varies depending on the caller's subscription key. You need to cache responses per subscription key to reduce backend load. Which policy configuration should you use?

A.Set cache key to include the subscription key

B.Use a global cache with no variation

C.Disable caching and rely on the backend

D.Use rate limiting policy

AnswerA

When API responses vary based on the caller's identity, such as a subscription, including the subscription key (e.g., using @(context.Subscription.Id)) in the cache key ensures that each unique subscriber receives their specific cached data. This policy prevents data leakage between subscriptions while still leveraging Azure API Management's caching capabilities to reduce backend load and improve response times for individual subscribers. It effectively creates isolated cache entries per subscription, providing personalized caching.

Why this answer

Azure API Management's caching policy allows you to customize the cache key using the `@(context.Subscription.Id)` expression. By setting the cache key to include the subscription key, each caller's responses are cached separately based on their unique subscription, ensuring that variations in the API response per subscription key are preserved while reducing backend load.

Exam trap

The trap here is that candidates might confuse caching policies with rate limiting or assume that a single global cache is sufficient, overlooking the need to differentiate cache entries per caller identity when the API response varies by subscription key.

How to eliminate wrong answers

Option B is wrong because using a global cache with no variation would cache a single response for all callers, ignoring the fact that the API response varies per subscription key, leading to incorrect responses for most callers. Option C is wrong because disabling caching and relying on the backend would not reduce backend load, which is the primary requirement; it would force every request to hit the backend, defeating the purpose of caching. Option D is wrong because rate limiting policy controls the number of requests a caller can make, not the caching of responses; it does not address the need to cache responses per subscription key.

Full explanation →

724

Multi-Selectmedium

Which TWO of the following are valid ways to authenticate to Azure Blob Storage from an application? (Choose two.)

Select 2 answers

A.Microsoft account (personal) OAuth token

B.SQL Server authentication

C.Storage account access key

D.Shared access signature (SAS) token

E.Azure Cosmos DB primary key

AnswersC, D

A storage account access key is a symmetric key that grants full administrative access to all data within the storage account. There are two such keys (key1 and key2) per account, allowing for key rotation without service interruption. When used, the key is included in the request header to sign the request, and the storage service validates this signature, granting complete control over blobs, files, queues, and tables.

Why this answer

Option C (Storage account access key) is correct because Azure Blob Storage supports authorization using the storage account's access keys, which are shared secrets that grant full access to the storage account and can be used by an application to sign requests. Option D (Shared access signature (SAS) token) is also correct because a SAS is a URI that grants restricted, time-limited access rights to Blob Storage resources, and applications can authenticate by presenting this token. Option A is not valid because personal Microsoft account OAuth tokens are not an authentication mechanism for Blob Storage data-plane access; Azure AD (work/school) identities are used instead.

Option B is incorrect because SQL Server authentication applies to Azure SQL Database, not Blob Storage. Option E is incorrect because Azure Cosmos DB primary keys authenticate to Cosmos DB, not Blob Storage.

Exam trap

The trap here is that candidates may confuse Azure AD authentication (which uses OAuth 2.0 tokens) with personal Microsoft account OAuth tokens, or mistakenly think Cosmos DB keys or SQL Server credentials can be reused across Azure services, when each service has its own distinct authentication mechanism.

Full explanation →

725

MCQmedium

You are developing an ASP.NET Core web API that is hosted on Azure App Service. The API needs to read secrets from Azure Key Vault at startup. You want to avoid storing any credentials in the application code or configuration. Which approach should you use?

A.Use the Key Vault SDK with a client ID and client secret stored in App Service application settings.

B.Enable the system-assigned managed identity for the App Service and configure Key Vault access policies to allow that identity.

C.Use Microsoft Entra ID application roles to assign the App Service a role that allows reading secrets.

D.Store the Key Vault URL and a connection string with the secret in the application's app.config file.

AnswerB

System-assigned managed identity lets App Service authenticate to Key Vault without any stored secret, satisfying the no-credentials constraint. Microsoft Entra ID issues the token automatically, and a Key Vault access policy grants that identity secret read permissions, so the API retrieves secrets at startup credential-free.

Why this answer

Enabling a system-assigned managed identity for the App Service allows it to authenticate to Azure Key Vault without any credentials stored in code or configuration. The managed identity is automatically managed by Azure AD (now Microsoft Entra ID) and can be granted access to Key Vault secrets via access policies, eliminating the need for client IDs, client secrets, or connection strings.

Exam trap

The trap here is that candidates often think storing credentials in App Service application settings is acceptable because they are 'not in code,' but the question explicitly requires avoiding any stored credentials, making managed identity the only secure, credential-free approach.

How to eliminate wrong answers

Option A is wrong because storing a client ID and client secret in App Service application settings still requires credentials in configuration, violating the requirement to avoid storing any credentials. Option C is wrong because Microsoft Entra ID application roles are used for application-level permissions and RBAC, not for granting an App Service identity direct access to Key Vault secrets; Key Vault uses access policies or RBAC roles like 'Key Vault Secrets User' for managed identities. Option D is wrong because storing the Key Vault URL and a connection string with the secret in app.config places credentials in the application code/configuration, directly contradicting the requirement.

Full explanation →

726

Multi-Selecthard

Which THREE features of Azure API Management help enforce security policies for APIs? (Choose three.)

Select 3 answers

A.rate-limit policy

B.xml-to-json policy

C.cache-lookup policy

D.validate-jwt policy

E.IP filtering policy

AnswersA, D, E

The `rate-limit` policy is a critical security feature in Azure API Management designed to prevent API abuse, Denial of Service (DoS) attacks, and brute-force attempts. It enforces a maximum number of API calls a client or subscription can make within a specified time window, ensuring fair usage and protecting backend services from being overwhelmed by excessive requests. By controlling the request volume, this policy helps maintain API availability and stability, which are fundamental aspects of overall API security.

Why this answer

The rate-limit policy (A) is correct because it enforces security by throttling API calls to prevent abuse and denial-of-service attacks, limiting the number of requests within a specified time window per subscription or key. This protects backend services from being overwhelmed by excessive traffic, a core security requirement for API management.

Exam trap

The trap here is that candidates may confuse transformation or caching policies (like xml-to-json or cache-lookup) with security policies, but Azure API Management clearly categorizes security policies as those that control access, authenticate, or throttle traffic, not those that modify data or improve performance.

Full explanation →

727

MCQmedium

A checkout API uses Azure Functions with HTTP triggers. The developer wants to reject unauthenticated calls before function code executes. Which feature should be configured?

A.Deployment slots

B.App Service Authentication / Easy Auth with Microsoft Entra ID

C.Application Insights sampling

D.Function timeout

AnswerB

Configuring App Service Authentication with Microsoft Entra ID validates tokens at the platform's reverse proxy, so unauthenticated requests are rejected with 401 before the function's code ever runs. This satisfies the stem's requirement to block calls pre-execution, unlike in-code token validation, which only occurs once the function has already been invoked.

Why this answer

App Service Authentication (Easy Auth) with Microsoft Entra ID allows the developer to reject unauthenticated calls before the function code executes by configuring the authentication provider at the App Service platform level. This ensures that the HTTP trigger function only receives requests with valid tokens, without requiring custom authorization logic in the function code.

Exam trap

The trap here is that candidates might think authentication must be handled inside the function code (e.g., using custom middleware or token validation), but Azure Functions provides a built-in platform-level authentication feature (Easy Auth) that rejects unauthenticated calls before execution.

How to eliminate wrong answers

Option A is wrong because deployment slots are used for staging, swapping, and testing different versions of the app, not for authentication or rejecting unauthenticated calls. Option C is wrong because Application Insights sampling controls the volume of telemetry data collected, not authentication or request filtering. Option D is wrong because function timeout controls the maximum execution duration for a function, not the ability to reject unauthenticated requests before code runs.

Full explanation →

728

MCQeasy

You are monitoring an Azure web application with Application Insights. You notice a sudden increase in the number of failed requests. You want to be notified automatically when such anomalies occur, without manually setting static thresholds. Which Application Insights feature should you use?

A.Create a metric alert on the 'failed requests' metric with a static threshold.

B.Enable Smart Detection for failure anomalies.

C.Use Log Analytics to run a query every 5 minutes and trigger an action.

D.Create an availability test that periodically pings the application.

AnswerB

Enabling Smart Detection for failure anomalies is the most effective solution as it leverages machine learning to automatically analyze application telemetry and establish dynamic baselines for normal behavior. It proactively identifies sudden, statistically significant deviations from these baselines, such as an unexpected spike in failed requests, without requiring manual configuration of thresholds. This intelligent analysis provides timely and relevant alerts, minimizing alert fatigue and focusing on true operational issues.

Why this answer

Smart Detection for failure anomalies in Application Insights uses machine learning to automatically detect unusual patterns in failed request rates without requiring manual threshold configuration. This feature is specifically designed to notify you of anomalies based on historical behavior, making it the correct choice for the scenario described.

Exam trap

The trap here is that candidates often confuse metric alerts with static thresholds as the only way to get notified, overlooking the machine learning-based Smart Detection feature that is purpose-built for anomaly detection without manual thresholds.

How to eliminate wrong answers

Option A is wrong because creating a metric alert with a static threshold requires manual configuration and does not adapt to changing traffic patterns, which contradicts the requirement to avoid setting static thresholds. Option C is wrong because using Log Analytics to run a query every 5 minutes is a custom, manual approach that lacks the built-in anomaly detection capabilities of Smart Detection and requires additional setup for scheduling and action groups. Option D is wrong because an availability test periodically pings the application to check endpoint availability, not to detect anomalies in failed request rates; it is designed for availability monitoring, not for analyzing historical failure patterns.

Full explanation →

729

MCQmedium

Your Azure Logic Apps workflow fails intermittently with timeout errors. What should you do to improve reliability?

A.Configure retry policies for failed actions

B.Increase the action timeout to maximum

C.Reduce the number of parallel branches

D.Use Azure API Management in front of Logic Apps

AnswerA

Configuring retry policies directly addresses intermittent timeouts by instructing the Logic App to automatically re-attempt failed actions after a specified delay. This mechanism is crucial for handling transient faults, such as temporary network issues or service unavailability, without requiring manual intervention. Logic Apps offer built-in retry policies like default, exponential interval, and fixed interval, allowing developers to tailor the retry behavior to the specific characteristics of the external service or API being called, significantly enhancing workflow reliability.

Why this answer

Intermittent timeout errors in Azure Logic Apps indicate that some actions are taking longer than the default timeout to complete. Configuring retry policies for failed actions allows the workflow to automatically reattempt the operation, which can resolve transient failures due to network congestion or temporary service unavailability. This directly improves reliability by handling intermittent timeouts without manual intervention.

Exam trap

The trap here is that candidates often confuse increasing the timeout as a reliability fix, when in fact it only postpones the failure, whereas retry policies actively handle transient errors by reattempting the operation.

How to eliminate wrong answers

Option B is wrong because increasing the action timeout to its maximum (e.g., 120 seconds for HTTP actions) only delays the failure; it does not address the root cause of intermittent timeouts and can lead to longer workflow execution times. Option C is wrong because reducing the number of parallel branches may decrease concurrency but does not prevent individual actions from timing out; it can even reduce throughput without resolving timeout issues. Option D is wrong because Azure API Management is a gateway for managing APIs, not a tool for handling timeout errors within Logic Apps; it adds latency and complexity without fixing action-level timeouts.

Full explanation →

730

Multi-Selectmedium

Which TWO authentication methods can be used to connect an Azure App Service to an Azure SQL Database without storing connection strings in code or configuration files?

Select 2 answers

A.Client certificate installed on the App Service

B.Storage account access key

C.SQL Server authentication (username and password)

D.System-assigned managed identity

E.User-assigned managed identity

AnswersD, E

A system-assigned managed identity is automatically created and managed by Azure for a specific Azure resource, such as an App Service, and its lifecycle is tied directly to that resource. This identity registers with Azure Active Directory and enables the App Service to authenticate to other Azure AD-enabled services, like Azure SQL Database, without requiring any credentials to be stored in code or configuration. It provides a secure, passwordless authentication mechanism, simplifying credential management and enhancing security posture.

Why this answer

System-assigned managed identity (D) is correct because it creates an identity directly in Microsoft Entra ID tied to the App Service instance, allowing the app to request a token for Azure SQL Database via the managed identity endpoint and authenticate without any stored credentials. User-assigned managed identity (E) is also correct because it is a standalone Entra ID identity that can be assigned to the App Service and granted access to the SQL Database, likewise eliminating connection strings with secrets. Both work because Azure SQL Database supports Microsoft Entra authentication, and the App Service can obtain tokens through its managed identity without embedding credentials in code or configuration.

A client certificate (A) is not the mechanism used for App Service-to-SQL authentication and would still require certificate management rather than identity-based token auth. A storage account access key (B) is unrelated to SQL Database authentication and applies to Azure Storage. SQL Server authentication (C) requires a username and password, which is exactly the credential-storing approach the scenario wants to avoid.

Exam trap

The trap here is that candidates often confuse client certificates or storage access keys as valid SQL Database authentication methods, but Azure SQL Database only supports Azure AD authentication (including managed identities) and SQL authentication, not certificate-based or key-based authentication.

Full explanation →

731

MCQmedium

An application stores large media files (up to 5 GB) that are frequently appended to but rarely read sequentially. Which Azure Blob Storage type should be used to optimize writes and cost?

A.Block blob

B.Append blob

C.Page blob

D.Archive blob

AnswerB

Append blobs are specifically engineered for scenarios that require efficient, sequential write operations, making them ideal for logging, auditing, or, in this case, frequently appended media files. Each new write operation adds data to the end of the blob in an atomic manner, ensuring data integrity without modifying existing blocks. This design provides high performance for continuous data streams and supports files up to 195 GB, easily accommodating the 5 GB requirement.

Why this answer

Append blobs are optimized for append operations, making them ideal for scenarios like logging or storing media files that are frequently appended to. They support high-throughput writes without the overhead of managing block lists, and they are cost-effective for sequential append workloads compared to block blobs, which require explicit block management and are better suited for random read/write patterns.

Exam trap

The trap here is that candidates often choose block blobs because they are the default and most familiar type for large files, overlooking that append blobs are specifically designed for frequent append operations and offer better write performance and cost efficiency for that pattern.

How to eliminate wrong answers

Option A is wrong because block blobs are designed for efficient upload of large files by splitting them into blocks, but they are not optimized for frequent append operations; each append requires managing block IDs and committing a block list, which adds overhead and is less efficient than append blobs. Option C is wrong because page blobs are optimized for random read/write operations on fixed-size pages (512 bytes), typically used for virtual machine disks (VHDs), not for append-heavy workloads with large media files. Option D is wrong because archive blob is a tier (not a blob type) for infrequently accessed data with retrieval latency of hours, and it does not support frequent append operations; it is meant for cold storage, not active writes.

Full explanation →

732

MCQmedium

The internal API team is deploying a containerized .NET API that receives sporadic requests — sometimes none for hours, then bursts of activity. Cost is a priority. The team wants the container to stop running when idle and start automatically when a request arrives, with no server management overhead. Which Azure service is the best fit?

A.Azure Container Apps with scale-to-zero enabled on the HTTP ingress

B.Azure Kubernetes Service with the cluster autoscaler set to a minimum node count of zero

C.Azure App Service on a B1 (Basic) plan with Always On disabled

D.Azure Virtual Machine Scale Sets with scheduled scaling to zero instances overnight

AnswerA

Container Apps scales to zero replicas when idle. The first request after an idle period incurs a cold-start delay (typically seconds) while a replica starts. Subsequent requests in the burst are served by the running replica. Billing is consumption-based — zero replicas means zero compute cost during idle periods.

Why this answer

Azure Container Apps with scale-to-zero enabled on the HTTP ingress is the best fit because it allows the container to scale down to zero replicas when idle, automatically stopping the container to save costs, and scales back up to handle incoming HTTP requests with no server management overhead. This serverless platform abstracts Kubernetes infrastructure, meeting the team's requirement for minimal operational burden and cost efficiency.

Exam trap

The trap here is that candidates often confuse 'scale to zero' with 'autoscaling to a minimum of zero nodes' in AKS, but AKS cannot scale to zero nodes due to system pod requirements, whereas Azure Container Apps supports scale-to-zero at the replica level without managing nodes.

How to eliminate wrong answers

Option B is wrong because Azure Kubernetes Service (AKS) with the cluster autoscaler set to a minimum node count of zero is not supported; AKS requires at least one node to run system pods, and scaling to zero nodes would break cluster functionality. Option C is wrong because Azure App Service on a B1 (Basic) plan with Always On disabled still incurs costs for the reserved instance and cannot scale to zero; the plan is always running, and idle behavior only stops the app process, not the underlying VM. Option D is wrong because Azure Virtual Machine Scale Sets with scheduled scaling to zero instances overnight does not provide automatic, request-driven scaling; it relies on a fixed schedule and cannot react to sporadic bursts, plus VMs incur costs even when deallocated if the underlying resources are not released.

Full explanation →

733

MCQhard

You are building a solution that processes orders from multiple regions. Orders must be processed in the order they are received, but processing can take up to 5 minutes. You need to ensure exactly-once processing and minimize latency. Which Azure service and configuration should you use?

A.Azure Service Bus Queue with sessions enabled

B.Azure Event Hubs with consumer groups

C.Azure Service Bus Queue with duplicate detection enabled

D.Azure Queue Storage with poison messages

AnswerA

Azure Service Bus Queues with sessions enabled provide a robust mechanism for processing related messages in a guaranteed FIFO order. Sessions group messages by a SessionId, ensuring that all messages belonging to a specific session are delivered to a single receiver and processed sequentially. This capability is crucial for scenarios like order processing, where the sequence of operations for a single order must be maintained, and it facilitates achieving effective exactly-once processing within that session context.

Why this answer

Azure Service Bus Queue with sessions enabled ensures FIFO (first-in-first-out) ordering and exactly-once processing by grouping related messages into sessions. Sessions guarantee that messages within a session are processed in order, and the lock mechanism prevents duplicate processing even if processing takes up to 5 minutes. This minimizes latency by avoiding the overhead of duplicate detection or consumer group coordination.

Exam trap

The trap here is that candidates often confuse 'duplicate detection' with 'ordering,' but duplicate detection only prevents duplicate message IDs within a time window and does not guarantee FIFO order, while sessions are required for ordered processing.

How to eliminate wrong answers

Option B is wrong because Azure Event Hubs with consumer groups is designed for high-throughput event ingestion and does not guarantee FIFO ordering or exactly-once processing; it supports at-least-once delivery and requires checkpointing for ordering. Option C is wrong because Azure Service Bus Queue with duplicate detection enabled prevents duplicate messages based on a time window but does not enforce message ordering, so messages could be processed out of order. Option D is wrong because Azure Queue Storage with poison messages does not provide FIFO ordering or exactly-once processing; it offers at-least-once delivery and requires manual handling of poison messages, which can lead to duplicates and reordering.

Full explanation →

734

Multi-Selectmedium

You are developing an application that uses Azure Table Storage to store customer data. You need to query the table to retrieve all entities where the PartitionKey is 'Customers' and the RowKey starts with 'A'. You also want to minimize the amount of data transferred. Which two actions should you perform? (Choose two.)

Select 2 answers

A.Use a query filter that specifies both PartitionKey eq 'Customers' and RowKey ge 'A' and RowKey lt 'B'.

B.Use a continuation token to paginate through the results.

C.Retrieve all entities in the 'Customers' partition and filter on the client side.

D.Project only the properties you need by using the Select clause in the query.

E.Set the table's access tier to Cool to reduce storage costs.

AnswersA, D

Azure Table Storage supports filtering on PartitionKey and RowKey. To retrieve entities where RowKey starts with 'A', you can use a range query: RowKey ge 'A' and RowKey lt 'B'. This is efficient because it leverages the sorted index on RowKey within a partition. Combining with PartitionKey eq 'Customers' restricts the query to a single partition, which is the fastest way to query Table Storage. This approach minimizes data transfer by filtering at the service side and only returning matching entities.

Why this answer

To minimize data transfer when querying Table Storage, you should filter on both PartitionKey and RowKey using a range query for the prefix, and project only the needed properties. This reduces the number of entities returned and the size of each entity. Client-side filtering and pagination do not reduce total data transfer, and access tiers are not applicable to Table Storage.

Exam trap

The trap here is assuming that Table Storage supports access tiers like Blob Storage, or that client-side filtering is acceptable for minimizing data transfer.

Full explanation →

735

Multi-Selecthard

A company deploys a containerized application on Azure Kubernetes Service (AKS). They need to ensure high availability and disaster recovery across regions. Which THREE actions should they take?

Select 3 answers

A.Use Azure Front Door for global load balancing

B.Configure Pod Disruption Budgets

C.Use Azure Traffic Manager to route traffic

D.Deploy AKS clusters in multiple regions

E.Enable Cluster Autoscaler

AnswersA, C, D

While Azure Front Door provides global load balancing and web application firewall capabilities, its primary role is optimizing global routing for web traffic and accelerating content delivery. It's not designed as a primary disaster recovery mechanism for backend Kubernetes clusters, especially for non-HTTP/S traffic or complex failover scenarios beyond simple endpoint health checks. Its focus is on edge acceleration and WAF, not orchestrating multi-region Kubernetes failover.

Why this answer

Option D is correct because deploying AKS clusters in multiple Azure regions is the foundational step for cross-region high availability and disaster recovery, ensuring the workload survives a regional outage. Option A is correct because Azure Front Door provides global HTTP/HTTPS load balancing with anycast, health probes, and failover across regional AKS endpoints, improving availability and latency for the containerized application. Option C is correct because Azure Traffic Manager is a DNS-based global traffic router that can distribute and fail over traffic between AKS clusters in different regions using priority, weighted, or performance routing methods.

Option B is not correct here because Pod Disruption Budgets only protect pod availability during voluntary disruptions such as node drains within a single cluster, not cross-region DR. Option E is not correct because Cluster Autoscaler only scales node pools within a cluster based on resource demand and does not provide regional redundancy or disaster recovery.

Exam trap

The trap here is that candidates often confuse Cluster Autoscaler (which only scales nodes within a region) with cross-region disaster recovery solutions, overlooking that true high availability across regions requires deploying multiple AKS clusters and using a global traffic router like Azure Traffic Manager.

Full explanation →

736

MCQeasy

You are developing a background job that runs every hour to process data. You choose Azure Functions with a timer trigger. What is the correct format for the cron expression to run at the start of every hour?

A.0 * * * * *

B.* 0 * * * *

C.0 0 * * * *

D.0 0 0 * * *

AnswerC

This cron expression precisely defines a schedule for a job to run at the very beginning of every hour. By setting both the second and minute fields to "0", it ensures the trigger occurs exactly at the 0th second of the 0th minute of any given hour. The wildcard "*" in the hour, day of month, month, and day of week fields ensures this execution pattern repeats consistently, once per hour, every hour of every day.

Why this answer

In Azure Functions timer triggers, the cron expression uses six fields: {second} {minute} {hour} {day} {month} {day-of-week}. To run at the start of every hour (i.e., at minute 0 and second 0 of every hour), the expression must be '0 0 * * * *'. Option C correctly sets second to 0, minute to 0, and hour to '*' (every hour), with the remaining fields as '*' (every day, every month, every day-of-week).

Exam trap

The trap here is that candidates often confuse the six-field Azure Functions cron format with the standard five-field UNIX cron format, leading them to pick '0 * * * * *' (which runs every minute) or '* 0 * * * *' (which runs every second during minute 0).

How to eliminate wrong answers

Option A is wrong because '0 * * * * *' runs at second 0 of every minute (i.e., once per minute), not at the start of every hour. Option B is wrong because '* 0 * * * *' runs every second during minute 0 of every hour (i.e., 60 times at the start of the hour), not once at the start. Option D is wrong because '0 0 0 * * *' runs at midnight (00:00:00) every day, not at the start of every hour.

Full explanation →

737

MCQmedium

You have an Azure App Service web app that experiences fluctuating traffic. During peak hours, the CPU usage reaches 90% and response times increase. You want to automatically scale out the number of instances when CPU usage exceeds 75% and scale in when it drops below 25%. The scaling should be gradual to avoid thrashing. Which configuration should you use?

A.Enable 'Always On' and configure manual scale based on scheduled times.

B.Configure autoscale rules on the App Service plan scale-out setting, using CPU percentage as the metric with appropriate thresholds and cool-down periods.

C.Use Azure Functions with the Consumption Plan to handle the web app logic.

D.Deploy the web app to Azure Container Instances and use the scale-on-CPU feature.

AnswerB

Autoscale rules on the App Service plan add or remove instances based on CPU percentage, with thresholds of 75% out and 25% in plus cool-down periods preventing rapid oscillation. This satisfies the fluctuating-traffic and gradual-scaling constraints, since scale-out and scale-in are metric-driven rather than manual.

Why this answer

Azure App Service autoscale rules allow you to scale out (increase instance count) when CPU percentage exceeds 75% and scale in (decrease instance count) when it drops below 25%, with configurable cool-down periods (e.g., 5–10 minutes) to prevent thrashing. This directly addresses the fluctuating traffic pattern and gradual scaling requirement using the App Service plan's scale-out blade.

Exam trap

The trap here is that candidates confuse 'Always On' (which keeps the app warm) with autoscaling, or mistakenly think Azure Functions or Container Instances are drop-in replacements for App Service autoscale, ignoring the specific requirements for gradual, metric-based scaling with cool-down periods.

How to eliminate wrong answers

Option A is wrong because 'Always On' prevents the app from being unloaded after idle periods but does not provide any autoscaling capability; manual scale based on scheduled times cannot react to real-time CPU fluctuations. Option C is wrong because Azure Functions with the Consumption Plan is designed for event-driven, stateless workloads, not for hosting a full web app with persistent connections or complex routing; it lacks the autoscale granularity and CPU-based rules required here. Option D is wrong because Azure Container Instances scale-on-CPU feature is limited to container groups and does not integrate with App Service web app deployment; it also lacks the gradual scale-in/out cool-down periods needed to avoid thrashing.

Full explanation →

738

MCQmedium

You are developing a .NET 8 application that stores customer data in Azure Blob Storage. The application uses the Azure.Storage.Blobs SDK. You need to ensure that the blob containers are created only if they do not already exist. Which method should you call?

A.ExistsAsync

B.DeleteIfExistsAsync

C.CreateIfNotExistsAsync

D.CreateAsync

AnswerC

The `CreateIfNotExistsAsync` method provides an idempotent and robust mechanism for ensuring an Azure Blob Storage container is available. It intelligently first checks if a container with the specified name already exists in the storage account. If the container is not found, it then proceeds to create it. This approach prevents `RequestFailedException` errors that would occur if attempting to create an already existing container, making it ideal for reliably provisioning resources without complex conditional logic.

Why this answer

The `CreateIfNotExistsAsync` method is the correct choice because it atomically checks for the existence of the blob container and creates it only if it does not already exist, returning a Boolean indicating whether creation occurred. This aligns with the requirement to avoid errors when the container already exists, without requiring a separate existence check.

Exam trap

The trap here is that candidates often confuse `CreateIfNotExistsAsync` with `CreateAsync`, assuming that `CreateAsync` will silently succeed if the container exists, when in fact it throws an exception on conflict, leading to unhandled errors in production code.

How to eliminate wrong answers

Option A is wrong because `ExistsAsync` only checks whether the container exists and returns a Boolean; it does not create the container, so it fails to meet the creation requirement. Option B is wrong because `DeleteIfExistsAsync` deletes the container if it exists, which is the opposite of what is needed and would remove existing data. Option D is wrong because `CreateAsync` throws a `StorageRequestFailedException` (HTTP 409 Conflict) if the container already exists, requiring additional error handling to avoid failures.

Full explanation →

739

MCQeasy

You are building a serverless image-processing solution using Azure Functions. The function must automatically run whenever a new image is uploaded to a blob container and must scale out to handle high upload volumes. Which trigger and hosting plan should you use?

A.Timer trigger with Consumption plan

B.Blob trigger with Consumption plan

C.HTTP trigger with Premium plan

D.Queue trigger with App Service plan

AnswerB

The Blob trigger is specifically designed to activate an Azure Function whenever a new or updated blob is detected in a specified Azure Storage container. This directly addresses the requirement for processing images upon upload. Coupled with the Consumption plan, the function automatically scales out to handle fluctuating volumes of image uploads, executing only when triggered and incurring costs solely based on execution time and memory usage, making it highly efficient and cost-effective for serverless workloads.

Why this answer

The Blob trigger is designed to automatically execute a function when a blob is created or updated in Azure Blob Storage, making it the correct choice for an image-processing solution that must run on new uploads. The Consumption plan provides automatic scaling to handle high upload volumes by allocating resources on demand, which aligns with the serverless, event-driven requirement.

Exam trap

The trap here is that candidates may confuse the Blob trigger with other triggers (like Timer or Queue) that can indirectly process blobs, but only the Blob trigger directly and automatically responds to blob creation events without additional infrastructure.

How to eliminate wrong answers

Option A is wrong because a Timer trigger runs on a fixed schedule, not in response to blob uploads, so it cannot automatically process new images as they arrive. Option C is wrong because an HTTP trigger requires an explicit HTTP request to invoke the function, which is not suitable for an automatic, event-driven workflow triggered by storage events. Option D is wrong because a Queue trigger processes messages from a queue, not blob uploads directly, and the App Service plan does not provide the same automatic, fine-grained scaling as the Consumption plan for event-driven workloads.

Full explanation →

740

MCQeasy

You are developing an Azure Functions app that uses Durable Functions to orchestrate a long-running workflow. The workflow involves calling multiple external APIs. You need to ensure that the orchestration can survive a function app restart. Which feature should you use?

A.Use the default checkpointing and replay mechanism.

B.Log orchestration state to Application Insights.

C.Implement retry policies on the activity functions.

D.Set a high timeout on the orchestration.

AnswerA

Durable Functions inherently provides state persistence and reliability through its default checkpointing and replay mechanism. It automatically saves the orchestration's execution history to a storage provider (typically Azure Storage) after each await point. In the event of an app restart or host failure, the Durable Task Framework replays this stored history to reconstruct the orchestration's state exactly as it was before the interruption, ensuring seamless continuation. This built-in functionality is fundamental to Durable Functions' "durable" nature.

Why this answer

Durable Functions inherently use a checkpointing and replay mechanism to persist the orchestration state to a storage backend (Azure Storage queues, tables, and blobs). This ensures that after a function app restart, the orchestrator function can replay from the last checkpoint, restoring the exact execution context and continuing the workflow without data loss.

Exam trap

The trap here is that candidates confuse logging (Application Insights) with state persistence, or assume retry policies or timeouts are sufficient for durability, when only the built-in checkpointing and replay mechanism guarantees survival across restarts.

How to eliminate wrong answers

Option B is wrong because logging orchestration state to Application Insights is for monitoring and diagnostics, not for persisting the execution state required to survive a restart; it does not provide the replay capability needed for durability. Option C is wrong because implementing retry policies on activity functions handles transient failures of individual API calls, but does not preserve the overall orchestration state across a function app restart. Option D is wrong because setting a high timeout on the orchestration only extends the maximum execution duration, but does not provide any mechanism to recover the orchestration state after a restart.

Full explanation →

741

MCQhard

Refer to the exhibit. An administrator runs this Azure CLI command. What is the result?

A.Assigns the Contributor role to a service principal at the resource group scope

B.Assigns a managed identity to the resource group

C.Assigns the Reader role to a user at the subscription scope

D.Assigns the Reader role to a service principal at the resource group scope

AnswerD

The `az role assignment create` command, when used with an assignee identifier (like a service principal's object ID), correctly targets a service principal, which is an identity used by applications or services. The `--role "Reader"` parameter accurately specifies that read-only access is being granted. Furthermore, the `--resource-group "myResourceGroup"` parameter correctly sets the scope of this access to a specific resource group, precisely matching the command's intended functionality.

Why this answer

The Azure CLI command `az role assignment create --assignee <object-id> --role Reader --resource-group <rg-name>` assigns the Reader role to a service principal (identified by its object ID) at the specified resource group scope. The Reader role grants read-only access to resources within that resource group, which matches the command's parameters and the expected outcome.

Exam trap

The trap here is that candidates may confuse the `--assignee` parameter with a user principal name (UPN) or fail to recognize that the object ID in the command refers to a service principal, leading them to incorrectly select Option C (user at subscription scope) or Option A (Contributor role).

How to eliminate wrong answers

Option A is wrong because the command specifies the `--role Reader` parameter, not `Contributor`, so it does not assign the Contributor role. Option B is wrong because the command uses `az role assignment create` to assign a role to a principal, not to assign a managed identity to a resource group (which would require different commands like `az vm identity assign` or `az identity create`). Option C is wrong because the command includes `--resource-group` to scope the assignment to a resource group, not to the subscription level (which would omit the `--resource-group` parameter).

Full explanation →

742

MCQmedium

You are developing an Azure Function that processes messages from an Azure Service Bus queue. The function uses a Service Bus queue trigger and runs on a Consumption Plan. The queue receives a high volume of messages in bursts. You need to ensure that the function scales out to handle the load but does not exceed 10 concurrent instances. Which configuration should you apply?

A.Set the 'maxConcurrentCalls' property to 10 in the host.json file.

B.Set the 'functionAppScaleLimit' application setting to 10 in the function app.

C.Set the 'maxMessageBatchSize' property to 10 in the host.json file.

D.Restrict the Service Bus queue to have a maximum concurrency of 10 at the namespace level.

AnswerB

The functionAppScaleLimit application setting caps the maximum number of instances a Function App scales out to, so setting it to 10 preserves Consumption Plan burst scaling while enforcing the stated ceiling of 10 concurrent instances.

Why this answer

The 'functionAppScaleLimit' application setting controls the maximum number of instances for a function app running on the Consumption plan. Setting it to 10 ensures the app does not scale beyond 10 instances. The 'maxConcurrentCalls' property only limits per-instance concurrency.

Exam trap

The trap is confusing per-instance concurrency settings (like 'maxConcurrentCalls' in host.json) with the function app's instance-level scale limit ('functionAppScaleLimit'). The question specifically asks to cap the number of concurrent instances.

How to eliminate wrong answers

Option A is wrong because 'maxConcurrentCalls' in host.json controls the number of messages processed concurrently within a single function instance, not the number of instances; setting it to 10 limits per-instance parallelism but does not cap the total number of instances, which can still scale out beyond 10. Option C is wrong because 'maxMessageBatchSize' defines the maximum number of messages retrieved in a single batch from the Service Bus queue, not the number of concurrent instances; it affects throughput per invocation, not scaling limits. Option D is wrong because Azure Service Bus does not have a 'maximum concurrency' setting at the namespace level that limits function app instances; concurrency is managed at the client/trigger level, and namespace-level throttling is not a configurable property for this purpose.

Full explanation →

743

MCQeasy

Fabrikam Inc. has an Azure Function app that processes image uploads. Each time a blob is added to a container in Azure Blob Storage, the function is triggered. The function resizes the image and stores the result in another container. Currently, the function uses an Azure Storage account connection string stored in application settings. The security team requires that no connection strings or access keys be stored in application settings. The function must use managed identity to access the storage account. The storage account is in the same subscription. Which action should the team take?

A.Generate a SAS token for the storage account and store it in Key Vault. Retrieve the SAS token at runtime and use it to create the BlobServiceClient.

B.Create a user-assigned managed identity, assign it to the Function app, and grant it 'Storage Blob Data Contributor' role. Store the client ID in app settings. Use ManagedIdentityCredential with the client ID in code.

C.Keep the connection string in app settings but encrypt it using Azure Key Vault. Use Key Vault references to retrieve it.

D.Enable system-assigned managed identity on the Function app. Assign the 'Storage Blob Data Contributor' role to the managed identity on the storage account. Remove the connection string from application settings. Update the code to use DefaultAzureCredential to authenticate to Blob Storage.

AnswerD

This option correctly implements the recommended secure pattern for Azure services. Enabling a system-assigned managed identity provides the Function app with an automatically managed identity in Azure Active Directory, eliminating the need for any secrets or connection strings. Assigning the 'Storage Blob Data Contributor' role via RBAC grants only the necessary permissions to the storage account. Finally, `DefaultAzureCredential` in the code automatically detects and uses this managed identity for authentication, ensuring a robust, secret-less, and least-privilege access model.

Why this answer

It uses a system-assigned managed identity, which is automatically tied to the Function app's lifecycle, and assigns the 'Storage Blob Data Contributor' role to that identity on the storage account. This eliminates the need for any connection strings or access keys in application settings. The code then uses DefaultAzureCredential, which automatically discovers and uses the managed identity when running in Azure, providing secure, passwordless authentication to Azure Blob Storage.

Exam trap

The trap here is that candidates often overcomplicate the solution by choosing user-assigned managed identities or Key Vault integrations, when the simplest and most secure approach for a single-resource scenario is to use a system-assigned managed identity with DefaultAzureCredential, which requires zero stored secrets or identifiers in application settings.

How to eliminate wrong answers

Option A is wrong because generating a SAS token and storing it in Key Vault still requires managing a secret (the SAS token) and does not eliminate the need for a connection string or access key; it merely moves the secret to Key Vault, violating the requirement to not store any connection strings or access keys. Option B is wrong because while a user-assigned managed identity can work, it requires storing the client ID in app settings and explicitly passing it to ManagedIdentityCredential, which adds unnecessary complexity and still stores an identifier in settings; the simpler and more secure approach is to use a system-assigned managed identity with DefaultAzureCredential, which requires no stored identifiers. Option C is wrong because it keeps the connection string in app settings (even if encrypted via Key Vault references), which still stores a connection string or access key, directly violating the security team's requirement that no connection strings or access keys be stored in application settings.

Full explanation →

744

MCQmedium

You are designing a solution to ingest billions of small IoT sensor messages (each ~500 bytes). Messages arrive at high velocity and must be retained for 90 days. You need to query the data efficiently by device ID and timestamp. You want to minimize storage cost and write latency. Which Azure Storage solution should you use?

A.Azure Blob Storage with JSON logs

B.Azure Queue Storage

C.Azure Table Storage

D.Azure File Storage

AnswerC

Table Storage is optimized for storing large numbers of structured entities. Using device ID as partition key and timestamp as row key allows efficient point queries and range queries, with low write latency and cost.

Why this answer

Azure Table Storage is ideal for this scenario because it provides a cost-effective, schema-less NoSQL store that supports high-volume ingestion of billions of small messages with low write latency. Its partition key (device ID) and row key (timestamp) design enables efficient point queries by device and time range, while the 90-day retention aligns with Table Storage's lifecycle management capabilities.

Exam trap

The trap here is that candidates often choose Azure Blob Storage (Option A) because it's commonly used for log storage, but they overlook that querying billions of small blobs by device ID and timestamp is inefficient without additional indexing services like Azure Data Lake or Cosmos DB, whereas Table Storage provides native, low-latency querying via its composite key structure.

How to eliminate wrong answers

Option A is wrong because Azure Blob Storage with JSON logs incurs higher storage costs per GB compared to Table Storage, and querying billions of small JSON blobs by device ID and timestamp would require expensive full-scan operations or external indexing (e.g., Azure Data Lake), not efficient native querying. Option B is wrong because Azure Queue Storage is a message queuing service for decoupling components, not a persistent storage solution for querying historical data; messages are typically deleted after processing and cannot be efficiently queried by device ID and timestamp. Option D is wrong because Azure File Storage provides SMB file shares for shared file access, not a queryable data store; it lacks native indexing for device ID and timestamp queries and is not optimized for high-velocity ingestion of billions of small messages.

Full explanation →

745

MCQmedium

External partners are given Shared Access Signatures to upload product images to a specific Blob Storage container named 'images'. A partner reports accidentally uploading files to the 'contracts' container, which should not be accessible. What is the most likely configuration mistake?

A.The SAS was generated at the storage account level, granting write access that applies to multiple containers rather than being scoped to the 'images' container only

B.The SAS expiry time is too long, giving partners time to discover and access other containers

C.The partner used a storage account key instead of the provided SAS token

D.The SAS was signed with a stored access policy that did not name the correct container

AnswerA

An account SAS with sr=c (container) permission and no container restriction grants access to all containers. A container SAS is generated with a specific container name in the signed resource URI (e.g., https://account.blob.core.windows.net/images?sig=...), making it impossible for the holder to use the SAS against any other container.

Why this answer

A SAS generated at the storage account level grants permissions across all containers within that account. When the SAS URI includes only the account endpoint (e.g., https://<account>.blob.core.windows.net/) and a set of permissions (like write), the token can be used to access any container, including 'contracts'. To restrict access to a single container, the SAS must be scoped to the container resource URI (e.g., https://<account>.blob.core.windows.net/images) and the signed resource type must be 'c' (container) or 'b' (blob), not 's' (service).

Exam trap

The trap here is that candidates often confuse the scope of a SAS (account-level vs. resource-level) with other SAS properties like expiry time or stored access policies, leading them to incorrectly attribute the security breach to token lifetime or policy misconfiguration rather than the fundamental lack of resource-level scoping.

How to eliminate wrong answers

Option B is wrong because a long expiry time does not enable access to other containers; it only extends the window of validity for the token, but the token's scope (which containers it can access) is determined by the resource URI and signed resource type, not the expiry. Option C is wrong because using a storage account key would grant full administrative access to the entire storage account, not just the 'images' container, but the scenario states the partner was given a SAS token, so using the key would be a different authentication method, not a configuration mistake by the developer. Option D is wrong because a stored access policy defines permissions and expiry for a specific container; if the policy did not name the correct container, the SAS would be invalid or scoped to a different container, but it would not grant access to the 'contracts' container unless the policy itself was misconfigured to allow access to multiple containers, which is not the typical behavior of a stored access policy.

Full explanation →

746

MCQeasy

You are deploying a web app on Azure App Service that stores secrets in Azure Key Vault. The app uses managed identity to access Key Vault. During testing, you get a 403 Forbidden error when the app tries to read a secret. What is the most likely cause?

A.The managed identity is not assigned to the app.

B.The Key Vault has soft-delete enabled.

C.The Key Vault access policy does not grant the managed identity the 'Get' permission for secrets.

D.The Key Vault firewall is set to allow only selected networks.

AnswerC

When an Azure App Service app, authenticated via a managed identity, attempts to retrieve a secret from Key Vault, the Key Vault's access policy is consulted for authorization. If the managed identity is not explicitly granted the 'Get' permission for secrets within that Key Vault's access policy, the request will be denied. This specific denial of a permitted action, despite successful authentication, directly results in an HTTP 403 Forbidden status code.

Why this answer

The 403 Forbidden error indicates that the request was authenticated but not authorized. Since the app uses managed identity to access Key Vault, the most likely cause is that the Key Vault access policy does not grant the managed identity the 'Get' permission for secrets. Without this specific permission, the identity can authenticate but cannot retrieve secret values, resulting in a 403 response.

Exam trap

The trap here is that candidates confuse authentication (401) with authorization (403) and may incorrectly assume the managed identity is not assigned (Option A) when the actual issue is a missing access policy permission (Option C).

How to eliminate wrong answers

Option A is wrong because if the managed identity were not assigned to the app, the error would typically be a 401 Unauthorized (authentication failure), not a 403 Forbidden (authorization failure). Option B is wrong because soft-delete is a data protection feature that allows recovery of deleted vaults and objects; it does not affect access permissions or cause a 403 error during secret retrieval. Option D is wrong because if the Key Vault firewall were blocking the request, the error would be a 403 but with a network-related message (e.g., 'Access denied due to IP restrictions'), and the app's outbound IP would need to be explicitly allowed; however, the most common and direct cause for a 403 when using managed identity is a missing access policy permission.

Full explanation →

747

MCQmedium

An e-commerce application emits a high volume of telemetry data to Azure Application Insights. You need to reduce the cost of data ingestion while preserving statistical accuracy for performance metrics. Which sampling technique should you use?

A.Adaptive sampling

B.Fixed-rate sampling with a 1% rate

C.Ingestion sampling

D.Head-based sampling

AnswerA

Adaptive sampling in Application Insights automatically adjusts the sampling rate based on the volume of telemetry and a target maximum data ingestion rate. This dynamic adjustment ensures that a representative sample of data is collected during both low and high traffic periods, preventing excessive costs while maintaining sufficient data for accurate diagnostics and performance analysis. It intelligently reduces the sampling rate during spikes and increases it during lulls to meet the configured daily cap, preserving statistical validity.

Why this answer

Adaptive sampling is the correct choice because it automatically adjusts the sampling rate based on the volume of telemetry data, ensuring that during low-traffic periods all data is retained for statistical accuracy, while during high-traffic periods it reduces the rate to control costs. This technique is specifically designed for high-volume scenarios like e-commerce telemetry, where preserving statistical accuracy for performance metrics (e.g., request durations, failure rates) is critical, and it avoids the manual tuning required by fixed-rate sampling.

Exam trap

The trap here is that candidates often confuse adaptive sampling with fixed-rate sampling, assuming a constant low rate (like 1%) is always cheaper, but they miss that adaptive sampling preserves accuracy by retaining all data during low-volume periods and only reduces during spikes.

How to eliminate wrong answers

Option B is wrong because fixed-rate sampling with a 1% rate applies a constant sampling percentage regardless of traffic volume, which can lead to under-sampling during low-traffic periods (losing statistical accuracy) or over-sampling during high-traffic periods (not reducing costs effectively). Option C is wrong because ingestion sampling occurs at the Application Insights ingestion endpoint after telemetry is sent, meaning you still pay for the data transmitted to the endpoint, and it does not reduce network bandwidth or SDK-side processing costs. Option D is wrong because head-based sampling (e.g., fixed-rate sampling at the SDK level) samples telemetry before any processing, which can break end-to-end transaction correlation if not all components use the same sampling rate, and it does not adapt to changing traffic patterns.

Full explanation →

748

MCQmedium

You are developing a solution that needs to consume an external SOAP web service. Which approach should you use to integrate it into a modern .NET Core application?

A.Use gRPC client to call the service.

B.Use HttpClient to send raw HTTP requests with SOAP envelope.

C.Use the WCF Client (System.ServiceModel) to generate a proxy and call the SOAP service.

D.Use Azure Logic Apps with a SOAP connector.

AnswerC

The WCF (Windows Communication Foundation) client libraries, part of `System.ServiceModel`, are the standard and most robust way to consume SOAP-based web services in .NET. By using tools like `dotnet-svcutil` to generate a proxy class from the service's WSDL (Web Services Description Language), developers gain a strongly-typed interface. This proxy handles the intricate details of SOAP message construction, serialization, deserialization, and transport automatically, significantly simplifying interaction with the service and reducing development effort.

Why this answer

System.ServiceModel (WCF Client) provides built-in support for SOAP protocols, including WS-* standards, message security, and automatic proxy generation from WSDL. In modern .NET Core (and .NET 5+), the WCF client libraries are available via the System.ServiceModel.Http NuGet package, making it the most appropriate and feature-complete way to consume a SOAP service in a .NET Core application.

Exam trap

The trap here is that candidates assume HttpClient is sufficient for SOAP because it can send XML, but they overlook the complexity of SOAP standards (WS-Addressing, security, MTOM) that the WCF client handles automatically, making raw HTTP requests a fragile and non-production-ready approach.

How to eliminate wrong answers

Option A is wrong because gRPC is a binary, HTTP/2-based RPC framework that does not support SOAP envelopes or XML-based messaging; it is designed for high-performance, contract-first communication using Protocol Buffers, not for interoperating with legacy SOAP services. Option B is wrong because while HttpClient can technically send raw HTTP requests with a SOAP envelope, this approach requires manually constructing XML, handling WS-Addressing headers, managing security tokens, and parsing responses—essentially reimplementing the entire SOAP stack, which is error-prone and not recommended for production use. Option D is wrong because Azure Logic Apps with a SOAP connector is an integration platform-as-a-service (iPaaS) solution that runs outside the application process, adding network latency, cost, and operational complexity; it is not a code-level integration approach for a .NET Core application.

Full explanation →

749

MCQhard

A company uses Azure Event Hubs to ingest telemetry data from IoT devices. The data is processed by a stream analytics job that outputs to Azure Data Lake Storage Gen2. The developer needs to ensure that the stream analytics job can authenticate to Event Hubs without storing connection strings in code. Which authentication method should the developer use?

A.Use a connection string with the Event Hubs namespace

B.Use a client certificate

C.Use a Shared Access Signature (SAS) token

D.Use Managed Identity

AnswerD

Managed Identity for Azure resources provides an automatically managed identity in Azure Active Directory (Azure AD) for Azure services. This eliminates the need for developers to manage credentials, as Azure handles the authentication process securely behind the scenes. The service instance authenticates with Azure AD, which then grants access to other Azure resources like Event Hubs based on assigned roles, significantly enhancing security and simplifying credential management.

Why this answer

Managed Identity allows the Azure Stream Analytics job to authenticate to Event Hubs without storing any credentials in code or configuration. By enabling a system-assigned or user-assigned managed identity on the Stream Analytics job, it can securely obtain an Azure AD token to access the Event Hubs namespace. This eliminates the need for connection strings or SAS tokens, aligning with the requirement to avoid storing secrets.

Exam trap

The trap here is that candidates often confuse SAS tokens with managed identities, thinking SAS tokens are 'secret-free' because they are generated at runtime, but they still require the SAS key to be stored or generated from a stored key, whereas managed identities eliminate all secret storage entirely.

How to eliminate wrong answers

Option A is wrong because using a connection string with the Event Hubs namespace would require storing the connection string in code or configuration, violating the requirement to avoid storing secrets. Option B is wrong because client certificates are not a supported authentication method for Azure Stream Analytics to connect to Event Hubs; they are typically used for HTTPS or TLS mutual authentication, not for Azure service-to-service authentication. Option C is wrong because a Shared Access Signature (SAS) token still requires generating and storing the token or its signing key, which does not eliminate the need to manage secrets in code.

Full explanation →

750

MCQeasy

You are deploying a sensitive application on Azure Kubernetes Service (AKS). You need to ensure that secrets, such as database connection strings, are encrypted at rest and in transit, and that the cluster has no static credentials. Which feature should you enable?

A.Enable etcd encryption at rest

B.Enable Azure Disk Encryption on the node pools

C.Assign a managed identity to the AKS cluster

D.Use Azure Key Vault Provider for Secrets Store CSI Driver

AnswerD

The Azure Key Vault Provider for Secrets Store CSI Driver allows Kubernetes pods to retrieve secrets, keys, and certificates directly from Azure Key Vault and mount them as a volume within the pod's filesystem. This approach ensures that sensitive data is never persisted within the AKS cluster's etcd or as native Kubernetes Secret objects. Instead, secrets are fetched on demand and presented to the application through a secure, ephemeral file system, significantly reducing the risk of secret exposure within the cluster and enhancing overall security posture.

Why this answer

The Azure Key Vault Provider for Secrets Store CSI Driver integrates with AKS to securely fetch secrets from Azure Key Vault, encrypting them at rest (Key Vault uses AES-256) and in transit (TLS 1.2+). It eliminates static credentials by using a managed identity or service principal to authenticate to Key Vault, ensuring no secrets are stored on disk or in etcd.

Exam trap

The trap here is that candidates often confuse encryption at rest (e.g., etcd encryption or disk encryption) with the broader requirement of eliminating static credentials and securing secrets in transit, leading them to pick A or B instead of the integrated solution D.

How to eliminate wrong answers

Option A is wrong because enabling etcd encryption at rest only protects secrets stored in etcd (the Kubernetes backing store) but does not address secrets in transit or eliminate static credentials; it also does not integrate with an external secrets store like Key Vault. Option B is wrong because Azure Disk Encryption on node pools encrypts the OS and data disks at rest using BitLocker or DM-Crypt, but it does not protect secrets in transit, nor does it remove static credentials from the cluster. Option C is wrong because assigning a managed identity to the AKS cluster provides authentication for Azure resources but does not by itself encrypt secrets at rest or in transit, nor does it prevent static credentials from being stored in the cluster.

Full explanation →

Microsoft Azure Developer Associate AZ-204 (AZ-204) — Questions 676–750