CCNA Connect Consume Services Questions — Page 2 of 3

MCQmedium

A web app uses Azure Key Vault to store secrets. The app runs in a production environment and needs to authenticate to Key Vault without storing connection strings in configuration files. Which authentication method should be used?

A.Client secret stored in app settings

B.Managed identity

C.Storage account access keys

D.Certificate stored in Key Vault

AnswerB

Managed identity provides an automatically managed identity in Azure Active Directory (AAD) for Azure services, enabling them to authenticate to other AAD-protected services like Key Vault without requiring developers to manage any credentials. Azure automatically handles the creation, rotation, and secure provisioning of these identities, eliminating the need for secrets in application code or configuration. This approach significantly enhances security by removing the burden of credential management and reducing the attack surface.

Why this answer

Managed identity (Option B) is correct because it allows the web app to authenticate to Azure Key Vault without storing any credentials in code or configuration files. Azure automatically manages the identity for the app, and the app uses the Azure Identity SDK to obtain tokens via the Azure Instance Metadata Service (IMDS) endpoint, which eliminates the need for connection strings or secrets.

Exam trap

The trap here is that candidates may choose a certificate stored in Key Vault (Option D) thinking it is more secure, but they overlook that managed identity eliminates the need to manage any credential at all, which is the core requirement of the question.

How to eliminate wrong answers

Option A is wrong because storing a client secret in app settings violates the requirement of not storing connection strings in configuration files, and it introduces a security risk of secret leakage. Option C is wrong because storage account access keys are used for authenticating to Azure Storage, not for authenticating to Key Vault, and they would also need to be stored in configuration. Option D is wrong because while a certificate stored in Key Vault can be used for authentication, it still requires the app to have a mechanism to retrieve and use that certificate, which typically involves storing a client ID or other identifier in configuration, and it does not eliminate the need for credential management as effectively as managed identity.

Practice this question →

MCQmedium

Three analytics pipelines each need to read every event from the same Azure Event Hub: one pipeline archives events to cold storage, one computes real-time aggregations, and one feeds a machine learning model. How should the developer configure Event Hubs to allow all three to consume independently without interfering with each other?

A.Create a separate consumer group for each pipeline; each group tracks its own offset independently

B.Create three separate Event Hubs in the same namespace and replicate events between them with Event Hubs Capture

C.Use a single consumer group and route events to different pipelines by partition key prefix

D.Enable Event Hubs Capture for all three pipelines so they read from the captured Avro files in storage instead of the Event Hub directly

AnswerA

With three consumer groups, each pipeline reads the full stream from its own position. The archiving pipeline, aggregation pipeline, and ML pipeline each checkpoint independently. If one falls behind or restarts, it resumes from its own saved offset without disturbing the others.

Why this answer

A is correct because each consumer group in Event Hubs maintains its own independent offset and checkpoint, allowing multiple consumers to read the same event stream without interfering. By creating a separate consumer group for each pipeline (archival, real-time aggregation, ML), each pipeline can process events at its own pace and from its own position in the stream, ensuring no consumer's progress affects another.

Exam trap

The trap here is that candidates often confuse consumer groups with partitions, thinking that multiple consumers must use different partitions to avoid interference, but partitions are for scaling throughput, not for independent offset tracking—consumer groups are the correct abstraction for independent consumption.

How to eliminate wrong answers

Option B is wrong because creating three separate Event Hubs and replicating events between them is unnecessary overhead and does not solve the independent consumption requirement; each pipeline would still need its own consumer group within each hub, and replication introduces latency and complexity. Option C is wrong because using a single consumer group forces all pipelines to share the same offset, meaning one pipeline's consumption progress (e.g., fast real-time aggregation) would advance the offset, causing other pipelines (e.g., slower archival) to miss events. Option D is wrong because Event Hubs Capture writes events to Azure Blob Storage or Data Lake Store in Avro format, but it is a one-way archival feature, not a mechanism for multiple independent consumers; pipelines would still need to read from the Event Hub directly for real-time processing, and Capture does not provide independent offset tracking.

Practice this question →

MCQmedium

You are developing a .NET Core web API that will be hosted in Azure App Service. The API must authenticate users via Azure Active Directory (Azure AD) and call a downstream web API that is also protected by Azure AD. You need to implement the On-Behalf-Of (OBO) flow. Which Microsoft identity platform library and method should you use to acquire a token for the downstream API?

A.Use Microsoft.Identity.Web and call AddMicrosoftIdentityWebApiAuthentication to configure JWT bearer authentication, then call the downstream API with the same token.

B.Use Microsoft.IdentityModel.Clients.ActiveDirectory (ADAL) and call AcquireTokenAsync with the client credential flow.

C.Use Microsoft.Identity.Client (MSAL) and call AcquireTokenOnBehalfOf with the incoming access token and the downstream API's scopes.

D.Use Microsoft.Identity.Client (MSAL) and call AcquireTokenSilent with the downstream API's scopes.

AnswerC

The OBO flow is implemented by calling AcquireTokenOnBehalfOf in MSAL. This method takes the incoming access token (from the client) and the scopes for the downstream API, and exchanges them for a new access token. This is the correct way to authenticate the web API to call another API on behalf of the user.

Why this answer

To implement the On-Behalf-Of flow, you use MSAL's AcquireTokenOnBehalfOf method. This method takes the incoming access token and requests a new token for the downstream API using the user's context. It is the standard way to handle delegated authentication in a middle-tier service.

Other methods either do not perform the token exchange or are obsolete.

Exam trap

The trap here is confusing silent token acquisition with the on-behalf-of flow, which requires an explicit token exchange using the incoming token.

Practice this question →

MCQhard

Refer to the exhibit. You deploy the ARM template to create an Azure Key Vault. After deployment, you attempt to add an access policy to grant a user 'Get' secret permissions using the Azure portal, but the option is grayed out. What is the most likely reason?

A.The vault is disabled due to 'enableSoftDelete'

B.The property 'enabledForDeployment' is set to false

C.Soft delete is enabled, which prevents access policy changes

D.RBAC authorization is enabled, so access policies are not used

AnswerD

When an Azure Key Vault is configured with 'enableRbacAuthorization' set to 'true', it explicitly switches its data plane access control model from vault-specific access policies to Azure Role-Based Access Control (RBAC). In this configuration, traditional Key Vault access policies become ineffective and are ignored. All permissions for data plane operations, such as getting, setting, or deleting keys and secrets, must then be managed exclusively through Azure RBAC role assignments at the vault, resource group, or subscription scope.

Why this answer

When Azure Key Vault is configured to use Azure RBAC (Role-Based Access Control) for authorization, the traditional access policy UI is disabled. The ARM template in the exhibit sets 'enableRbacAuthorization' to true, which switches the vault's authorization model from vault-level access policies to Azure RBAC roles. In this mode, you must assign roles (e.g., Key Vault Secrets User) via Azure RBAC instead of adding access policies.

Exam trap

The trap here is that candidates often confuse soft delete (which only affects deletion behavior) with RBAC authorization, assuming that soft delete or other boolean properties block access policy changes, when in fact the 'enableRbacAuthorization' property is the direct cause.

How to eliminate wrong answers

Option A is wrong because enabling soft delete does not disable the ability to add access policies; it only protects deleted vaults and secrets from permanent deletion. Option B is wrong because 'enabledForDeployment' controls whether Azure Virtual Machines can retrieve certificates from the vault for deployment, not the ability to modify access policies. Option C is wrong because soft delete does not prevent access policy changes; it only requires that the vault be in a non-deleted state to modify policies, and the vault is active after deployment.

Practice this question →

Multi-Selecthard

A function consumes messages from Azure Service Bus. Which two settings help handle transient failures safely? The design must avoid adding custom operational scripts.

Select 2 answers

A.Configure max delivery count with a dead-letter queue

B.Make message processing idempotent

C.Disable lock renewal for long processing

D.Use anonymous sender access

AnswersA, B

Azure Service Bus allows configuring a `MaxDeliveryCount` for a queue or subscription. When a message's delivery count exceeds this threshold, typically after multiple failed processing attempts by the function, Service Bus automatically moves the message to a dead-letter queue (DLQ). This mechanism is crucial for isolating problematic messages, preventing them from blocking the main queue, and enabling manual inspection or reprocessing without losing data.

Why this answer

Configuring a max delivery count with a dead-letter queue allows the system to automatically move a message to the dead-letter queue after a specified number of failed delivery attempts. This prevents poison messages from being retried indefinitely, handling transient failures safely without custom scripts. Option B is correct because idempotent message processing ensures that if a message is processed more than once due to transient failures or retries, the system state remains consistent, avoiding duplicate side effects.

Exam trap

The trap here is that candidates often confuse disabling lock renewal as a way to handle long processing times, but it actually causes message abandonment and reprocessing, not safe transient failure handling.

Practice this question →

MCQmedium

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

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

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

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

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

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

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

B.Deny all traffic to storage accounts

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

D.Allow only traffic from the specified virtual network

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

A.The client secret is expired or invalid.

B.The scope parameter is incorrectly formatted.

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

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

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQeasy

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

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

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

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

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

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQhard

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

A.Increase the function's timeout duration

B.Configure the EventProcessorOptions with a longer lease duration

C.Increase the number of partitions in the Event Hub

D.Decrease the batch size to process events faster

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQhard

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

A.The event hub name is misspelled

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

C.The consumer group is set to $Default

D.The connection string is stored as a securestring parameter

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQhard

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

A.defaultMessageTimeToLive

B.maxDeliveryCount

C.lockDuration

D.requiresDuplicateDetection

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQhard

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

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

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

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

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

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

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

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

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

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

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQeasy

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

A.CORS policy

B.Rate limit policy

C.Throttling policy

D.Validate JWT policy

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQeasy

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

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

B.The Azure CLI version is outdated

C.The storage account key is not provided

D.The container name does not exist

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

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

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

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

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

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

A.Implement retry logic with exponential backoff

B.Use a saga pattern

C.Use a request-reply pattern

D.Use a circuit breaker pattern

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

A.Increase the polling frequency to every 10 seconds.

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

C.Use Azure Data Factory to monitor the storage.

D.Use Azure Service Bus topics for file notifications.

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

Multi-Selecthard

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

Select 3 answers

A.set-header

B.rate-limit

C.cache-store

D.validate-jwt

E.cache-lookup

AnswersC, D, E

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

Why this answer

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

Exam trap

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

Practice this question →

MCQhard

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

A.transform-body

B.return-response

C.convert-to-json

D.set-body

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

A.Office 365 Outlook

B.SMTP

C.SendGrid

D.Outlook.com

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

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

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

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

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

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

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

Practice this question →

MCQeasy

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

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

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

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

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

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

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

Practice this question →

100

Multi-Selecthard

Which THREE are benefits of using Azure API Management for consuming third-party APIs? (Choose three.)

Select 3 answers

A.Transforming request and response formats (e.g., XML to JSON).

B.Implementing rate limiting and throttling to avoid exceeding API quotas.

C.Automatically scaling the third-party API based on demand.

D.Caching responses to reduce latency and load on the third-party API.

E.Providing a global load balancer for the third-party API.

AnswersA, B, D

Azure API Management (APIM) provides powerful policy expressions that allow developers to modify incoming requests and outgoing responses. This includes transforming data formats, such as converting an XML payload from a backend service into a JSON format expected by a client application, or vice-versa. These transformations ensure compatibility between disparate systems, simplifying integration for API consumers and abstracting backend complexities. This capability is crucial for modernizing legacy APIs or unifying diverse API ecosystems.

Why this answer

Option A is correct because API Management policies such as the XML-to-JSON policy (xml-to-json) and the set-body policy let you transform request and response payloads on the fly, so a consumer can call a third-party XML API while its own clients speak JSON. Option B is correct because APIM provides rate-limit and rate-limit-by-key policies (and quota policies) that cap calls per subscription or key, protecting you from exceeding the third-party API's contractual quotas and avoiding throttling or overage charges. Option D is correct because the response-cache and cache-lookup/cache-store policies can cache third-party responses at the APIM gateway, cutting latency for callers and reducing the number of calls hitting the external API.

Option C is not correct because APIM does not autoscale the third-party API itself; it only scales its own gateway instances, and the external service's capacity is outside your control. Option E is not correct because APIM is not a global load balancer for the third-party API; it can route to multiple backends, but it does not provide global traffic distribution for an API you do not own.

Exam trap

The trap here is that candidates often confuse API Management's ability to manage and protect access to third-party APIs with the ability to scale or load-balance the third-party service itself, which is not under Azure's control.

Practice this question →

101

Multi-Selecteasy

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

Select 2 answers

A.Azure Batch

B.Azure Logic Apps

C.Azure Functions

D.Azure Container Instances

E.Azure Virtual Machines

AnswersB, C

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

Why this answer

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

Exam trap

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

Practice this question →

102

Multi-Selecteasy

Which TWO Azure services can be used to store application configuration settings?

Select 2 answers

A.Azure App Configuration

B.Azure Queue Storage

C.Azure Blob Storage

D.Azure Cosmos DB

E.Azure Key Vault

AnswersA, E

Azure App Configuration is a dedicated, managed service specifically engineered for centralizing and managing application configuration settings. It supports dynamic configuration updates without redeploying applications, integrates with feature flags, and provides robust version control and snapshot capabilities. This service simplifies configuration management across microservices and distributed applications, making it ideal for modern cloud-native solutions.

Why this answer

Azure App Configuration (A) is purpose-built for centrally managing application settings and feature flags, providing key-value storage with labels, revisions, and point-in-time snapshots that applications can consume via SDKs or the REST API. Azure Key Vault (E) is also correct because it stores configuration secrets such as connection strings, API keys, and certificates that applications retrieve at runtime, and it is commonly paired with App Configuration for a complete configuration solution. Azure Queue Storage (B) is a messaging service for asynchronous message passing between components, not a configuration store.

Azure Blob Storage (C) is object storage for unstructured data like documents and images, not a dedicated configuration service. Azure Cosmos DB (D) is a globally distributed NoSQL database for application data, and while it could technically hold settings, it is not intended as an application configuration service.

Exam trap

The trap here is that candidates may confuse Azure Key Vault as a configuration store for all settings, but it is specifically for secrets (e.g., connection strings, passwords) and not for general application configuration like feature flags or non-sensitive settings, which is why both A and E are correct but for different purposes.

Practice this question →

103

MCQmedium

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

A.API Connection

B.HTTP + Swagger

C.HTTP

D.HTTP Webhook

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

104

MCQeasy

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

A.Key Vault references

B.Environment variables

C.Application settings

D.Azure App Configuration

AnswerA

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

Why this answer

Key Vault references in Azure App Service allow an app setting to point to a secret stored in Azure Key Vault, so the connection string is never stored in code or in plaintext app settings. The App Service resolves the reference at runtime using the app's managed identity, which must have GET permission on the Key Vault secret. This is the recommended pattern for injecting secrets into App Service without hardcoding them.

Exam trap

AZ-204 often tests whether candidates know that App Service application settings are not a secure secret store, and that Key Vault references require a managed identity with appropriate RBAC permissions to resolve.

How to eliminate wrong answers

Option B is wrong because environment variables in App Service are essentially the same as application settings and still store the value in the app configuration, which is not a secure secret store. Option C is wrong because application settings store values directly in the App Service configuration, which is visible to anyone with portal or API access and does not provide secret management or rotation. Option D is wrong because Azure App Configuration is a configuration store, not a secret vault; while it can reference Key Vault, it does not itself provide the secure secret storage and managed-identity-based retrieval that Key Vault references do.

Practice this question →

105

Multi-Selecthard

Which THREE components are required to implement a secure authentication flow for a single-page application (SPA) using Microsoft Entra ID to call Microsoft Graph? (Choose three.)

Select 3 answers

A.Client certificate

B.Authorization endpoint

C.Client ID (Application ID)

D.Client secret

E.Token endpoint

AnswersB, C, E

The authorization endpoint is a critical component where the user interacts with the identity provider to authenticate and grant consent for the client application to access protected resources. It initiates the authorization flow, typically by redirecting the user's browser, and upon successful authentication and consent, it returns an authorization code to the client application's registered redirect URI. This step is fundamental for obtaining the initial authorization code that will later be exchanged for tokens.

Why this answer

Option B (Authorization endpoint) is required because the SPA must redirect the user to the Microsoft Entra ID authorization endpoint (https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize) to initiate the OAuth 2.0 authorization code flow with PKCE and obtain user consent. Option C (Client ID / Application ID) is required because every app registration in Microsoft Entra ID is uniquely identified by its Application (client) ID, which the SPA sends in the authorization and token requests to identify itself. Option E (Token endpoint) is required because the SPA must exchange the authorization code (with the PKCE code_verifier) at the token endpoint (https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token) to receive the access token used to call Microsoft Graph.

Option A (Client certificate) is not needed, as certificates are used for confidential client or daemon/service authentication, not for browser-based SPAs. Option D (Client secret) is not needed and is in fact prohibited for SPAs, since public clients cannot securely store secrets; PKCE replaces the secret in this flow.

Exam trap

The trap here is that candidates often confuse the requirements for confidential clients (client secret or certificate) with those for public clients like SPAs, leading them to incorrectly select client secret or client certificate instead of recognizing that SPAs rely on PKCE and do not use client secrets.

Practice this question →

106

MCQmedium

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

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

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

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

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

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

107

MCQmedium

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

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

B.HTTP request trigger

C.Recurrence trigger

D.Service Bus trigger

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

108

MCQmedium

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

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

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

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

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

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

109

MCQeasy

A developer is building a .NET console application that needs to read and write files in an Azure Storage account. The application will run on a developer's workstation and must authenticate using Azure Active Directory (Azure AD). The developer has been granted the Storage Blob Data Contributor role on the storage account. Which method should the developer use to authenticate the application to Azure Storage?

A.Use the storage account's connection string with the account name and key.

B.Use the DefaultAzureCredential class from the Azure.Identity library.

C.Use the storage account's primary access key in the connection string.

D.Generate a shared access signature (SAS) token with read and write permissions.

AnswerB

DefaultAzureCredential automatically attempts multiple authentication methods, including Azure CLI credentials, managed identity, and Visual Studio account. On a developer workstation, it can use the developer's Azure AD login from tools like Azure CLI or Visual Studio. Since the developer has the Storage Blob Data Contributor role, this credential will authenticate successfully and is the recommended approach for Azure AD authentication.

Why this answer

DefaultAzureCredential simplifies authentication by trying several methods in order, including environment variables, managed identity, and developer tool credentials. On a workstation, it will use the signed-in user's Azure AD identity from Azure CLI or Visual Studio. Because the developer has the Storage Blob Data Contributor role, this credential will have the necessary permissions to read and write blobs, satisfying the Azure AD requirement.

Exam trap

The trap here is assuming that a SAS token or account key is acceptable because it works, but the requirement specifically mandates Azure AD authentication.

Practice this question →

110

MCQeasy

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

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

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

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

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

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

111

Multi-Selectmedium

Which TWO authentication mechanisms can be used to securely connect an Azure Function app to an Azure SQL Database using managed identities?

Select 2 answers

A.System-assigned managed identity

B.User-assigned managed identity

C.Service principal with client secret

D.Certificate-based authentication

E.Connection string with access key

AnswersA, B

A system-assigned managed identity is automatically created and managed by Azure for a specific Azure resource instance, such as a Virtual Machine or App Service. Its lifecycle is directly tied to the resource, and it is automatically deleted when the resource is deleted. This identity authenticates to Azure AD and can then be granted permissions to access other Azure services securely without needing to manage credentials in code. It provides a highly secure and automated way for Azure resources to authenticate.

Why this answer

Option A (System-assigned managed identity) is correct because it creates an identity directly in Microsoft Entra ID tied to the Function app's lifecycle, allowing the app to authenticate to Azure SQL Database via the Active Directory Managed Identity authentication method without storing credentials. Option B (User-assigned managed identity) is also correct because it is a standalone Azure resource that can be assigned to the Function app, enabling the same passwordless Entra ID token-based authentication to Azure SQL Database and supporting identity reuse across resources. Option C (Service principal with client secret) is not a managed identity mechanism and requires storing and rotating a secret, so it does not meet the managed identity requirement.

Option D (Certificate-based authentication) is a separate credential-based approach that is not a managed identity and requires managing certificates. Option E (Connection string with access key) uses SQL credentials or keys rather than managed identities and does not provide the passwordless Entra ID authentication described.

Exam trap

The trap here is that candidates often confuse managed identities with service principals or certificate-based authentication, thinking any Azure AD-backed method qualifies, but only system-assigned and user-assigned managed identities are the two specific managed identity types that eliminate credential management entirely.

Practice this question →

112

MCQhard

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

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

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

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

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

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

113

MCQmedium

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

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

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

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

D.Use Azure App Configuration with Key Vault references.

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

114

MCQmedium

An application calls a third-party shipping API through HTTP. The developer must implement retries without overwhelming the remote system during partial outages. Which retry pattern is best?

A.Immediate infinite retries

B.Retry only after restarting the application

C.Exponential backoff with jitter and a maximum retry limit

D.Disable all timeout settings

AnswerC

Jittered exponential backoff spaces retries progressively while randomising timing, preventing synchronised retry storms from many clients. The maximum retry limit bounds total attempts, satisfying the requirement not to overwhelm the shipping API during partial outages.

Why this answer

Exponential backoff with jitter and a maximum retry limit is the best pattern because it progressively increases the delay between retries, preventing the client from overwhelming the third-party shipping API during partial outages. Jitter randomizes the delay to avoid thundering herd problems where multiple clients retry simultaneously, and the maximum retry limit ensures the system does not retry indefinitely, preserving resources and allowing for graceful degradation.

Exam trap

The trap here is that candidates may choose immediate infinite retries (Option A) thinking it ensures delivery, but they overlook the risk of overwhelming the remote system and violating rate limits, which is explicitly tested in the context of third-party API consumption.

How to eliminate wrong answers

Option A is wrong because immediate infinite retries would flood the third-party API with requests during a partial outage, likely exacerbating the outage or triggering rate limiting and throttling responses (e.g., HTTP 429). Option B is wrong because retrying only after restarting the application introduces unnecessary downtime and delays recovery; the application should handle transient faults programmatically without requiring a restart. Option D is wrong because disabling all timeout settings would cause the application to hang indefinitely on unresponsive requests, leading to resource exhaustion (e.g., thread pool starvation) and no mechanism to detect or recover from failures.

Practice this question →

115

MCQeasy

You are developing a web app that uses Azure Key Vault to retrieve secrets. The app must authenticate using a system-assigned managed identity. Which endpoint should you use to get an access token for Key Vault?

A.https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/token

B.http://169.254.169.254/metadata/identity/oauth2/token?resource=https://vault.azure.net&api-version=2018-02-01

C.https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{rg}/providers/Microsoft.KeyVault/vaults/{vaultName}

D.https://graph.microsoft.com/v1.0/me

AnswerB

This is the correct endpoint for acquiring an access token using an Azure Managed Identity. The Azure Instance Metadata Service (IMDS) is a REST endpoint accessible only from within an Azure VM or other Azure compute resource, providing information about the running instance. When a managed identity is enabled, IMDS exposes a specific endpoint (169.254.169.254) that the resource can query to securely obtain an OAuth 2.0 access token for a specified resource, such as Azure Key Vault, without needing to manage credentials.

Why this answer

It uses the Azure Instance Metadata Service (IMDS) endpoint, which is the standard way for Azure resources with a system-assigned managed identity to obtain an access token. The request includes the resource parameter set to 'https://vault.azure.net' to specify Key Vault as the target service, and the API version '2018-02-01' is required for the IMDS token endpoint. This token is then used to authenticate to Key Vault without storing any credentials in the application code.

Exam trap

The trap here is that candidates often confuse the IMDS endpoint with the standard Azure AD OAuth endpoint (Option A), not realizing that managed identity authentication uses a special non-routable IP and requires the 'resource' parameter instead of 'scope'.

How to eliminate wrong answers

Option A is wrong because it is the standard Azure AD OAuth 2.0 token endpoint used for client credentials or authorization code flows with a registered application, not for managed identity authentication; it requires a client ID and secret, which defeats the purpose of using a managed identity. Option C is wrong because it is the Azure Resource Manager REST API endpoint for managing Key Vault resources (e.g., creating or updating a vault), not for obtaining an access token to retrieve secrets. Option D is wrong because it is the Microsoft Graph API endpoint for accessing user profile information, which is unrelated to Key Vault authentication and does not provide tokens for Azure services.

Practice this question →

116

MCQhard

Refer to the exhibit. A developer deploys this ARM template to create a blob container. Later, they attempt to upload a file to the container using a SAS token. What is the result?

A.The upload succeeds only if the SAS token includes read permission.

B.The container is not created because publicAccess is set to None.

C.The upload succeeds if the SAS token has write permission.

D.The upload fails because the container is private.

AnswerC

To successfully upload a blob to an Azure Storage container, the Shared Access Signature (SAS) token must explicitly include `Write` permission. This permission authorizes the client to create new blobs or overwrite existing ones within the specified container. The SAS token provides authenticated access, which overrides the container's public access setting, enabling uploads even to private containers.

Why this answer

The ARM template creates a blob container with `publicAccess` set to `None`, meaning no anonymous public access. However, a SAS token with write permission grants delegated access to the container, bypassing the public access setting. Therefore, the upload succeeds because the SAS token provides the necessary authorization, regardless of the container's public access level.

Exam trap

The trap here is that candidates mistakenly think setting `publicAccess` to `None` blocks all access, including SAS tokens, when in fact SAS tokens provide explicit delegated access that overrides the public access setting.

How to eliminate wrong answers

Option A is wrong because the SAS token needs write permission, not read permission, to upload a file; read permission alone would not allow the upload operation. Option B is wrong because setting `publicAccess` to `None` does not prevent container creation; it only disables anonymous public access, and the container is created successfully. Option D is wrong because the container being private (no public access) does not cause the upload to fail when a valid SAS token with write permission is used; SAS tokens are designed to grant access to private containers.

Practice this question →

117

MCQhard

A company uses Azure Cosmos DB for a global e-commerce platform. They need to query product inventory across multiple regions with low latency. The data is partitioned by product category. Some queries filter on category and price range. What indexing policy should be configured to optimize these queries?

A.Use a wildcard index for all properties.

B.Create a composite index with (category, price).

C.Add a hash index on category and a range index on price.

D.Enable spatial index on price.

AnswerB

Creating a composite index on `(category, price)` is the optimal solution for queries that filter, sort, or combine operations on both these fields efficiently. This index allows Azure Cosmos DB to quickly locate documents matching specific categories and price ranges, drastically reducing RU/s consumption and query latency. It provides a pre-sorted structure that accelerates multi-field filtering and `ORDER BY` clauses, making it ideal for e-commerce product searches.

Why this answer

A composite index on (category, price) allows Cosmos DB to efficiently satisfy queries that filter on both fields in a single index seek, avoiding a full scan. Composite indexes are designed for multi-property filters and sort orders, which directly matches the requirement to query by category and price range with low latency.

Exam trap

The trap here is that candidates confuse Cosmos DB indexing with SQL Server indexing, assuming a hash index on a single property is valid, when Cosmos DB only supports range (default) and spatial index types for single properties.

How to eliminate wrong answers

Option A is wrong because a wildcard index indexes all properties indiscriminately, which increases RU consumption and storage overhead without optimizing multi-property filter queries like category + price. Option C is wrong because Cosmos DB does not support a 'hash index' on a single property; the indexing types are consistent (range) or spatial, and a hash index is a SQL Server concept, not applicable here. Option D is wrong because a spatial index is used for geospatial queries (e.g., points, polygons), not for numeric range filtering on price.

Practice this question →

118

MCQeasy

You are developing an application that needs to retrieve secrets from Azure Key Vault. The application will run as an Azure Functions app. Which authentication method should you use to access Key Vault?

A.Use a client certificate stored in the function app

B.Use a system-assigned managed identity

C.Use the Key Vault connection string from app settings

D.Use the storage account access key from the function app

AnswerB

A system-assigned managed identity provides an Azure Function with an automatically managed identity in Microsoft Entra ID, directly tied to the resource's lifecycle. This identity can then be granted specific, fine-grained permissions to access Azure Key Vault secrets, certificates, or keys without needing to store any credentials (like connection strings or client certificates) in the function app's configuration. This approach adheres to the principle of least privilege and significantly enhances security by eliminating the burden of credential rotation.

Why this answer

A system-assigned managed identity is the recommended authentication method for Azure Functions to access Key Vault because it eliminates the need to store credentials in code or configuration. When enabled, Azure automatically creates a service principal in Azure AD for the function app, and the function can authenticate to Key Vault using this identity via the Azure Identity SDK (e.g., DefaultAzureCredential). This approach is secure, fully managed, and aligns with the principle of least privilege.

Exam trap

The trap here is that candidates may confuse Key Vault authentication with storage account access methods, or assume that a connection string or certificate is required, when in fact managed identities are the preferred and most secure approach for Azure-hosted services.

How to eliminate wrong answers

Option A is wrong because a client certificate stored in the function app introduces certificate management overhead and potential exposure; managed identities are simpler and more secure for Azure-hosted services. Option C is wrong because Key Vault does not use connection strings—it uses URIs and authentication via Azure AD tokens, not a connection string. Option D is wrong because storage account access keys are for authenticating to Azure Storage, not Key Vault, and using them would be a security anti-pattern for secret retrieval.

Practice this question →

119

Multi-Selectmedium

Which TWO services can be used to implement a publish-subscribe messaging pattern in Azure?

Select 2 answers

A.Azure Storage Queues

B.Azure Event Hubs

C.Azure Service Bus Topics

D.Azure Event Grid

E.Azure Queue Storage

AnswersC, D

Azure Service Bus Topics are a core component for implementing the publish-subscribe pattern within Azure. Publishers send messages to a topic, and these messages are then delivered to one or more named subscriptions associated with that topic. Each subscription can have filtering rules, allowing subscribers to receive only a subset of messages, ensuring that multiple independent consumers can each receive their own copy of relevant messages from a single published source.

Why this answer

Azure Service Bus Topics (C) implement publish-subscribe natively: a topic receives messages from publishers and fans them out to multiple subscriptions, each of which can have filters/rules, so multiple independent subscribers each get a copy. Azure Event Grid (D) is also a publish-subscribe service, using topics and event subscriptions to push events to multiple handlers via a push delivery model. Azure Storage Queues (A) and Azure Queue Storage (E) are the same point-to-point queue service, where each message is consumed by only one receiver, so they do not provide pub-sub fan-out.

Azure Event Hubs (B) is a streaming/event-ingestion service using partitions and consumer groups; while multiple consumers can read the stream, it is not a true publish-subscribe topic/subscription pattern with per-subscriber filtering like Service Bus Topics or Event Grid.

Exam trap

The trap here is that candidates confuse Azure Storage Queues (point-to-point) with Service Bus Topics (pub-sub) because both are 'queues' in name, but only topics support multiple independent subscribers receiving the same message.

Practice this question →

120

MCQmedium

You are building an Azure Logic App that must call an external API that uses the OAuth 2.0 authorization code grant. The API requires the user to sign in interactively to grant consent. You want to minimize development effort and securely manage the token lifecycle. Which built-in action and authentication method should you use?

A.Use the 'HTTP' action with 'OAuth 2.0' authentication and configure the authorization endpoint, client ID, and client secret.

B.Use the 'HTTP + Swagger' action with 'Identity Provider' authentication.

C.Use the 'API Connection' action with a custom connector that uses OAuth 2.0.

D.Use the 'HTTP' action with 'Managed identity' authentication.

AnswerA

The 'HTTP' action in Azure Logic Apps is highly versatile and directly supports the OAuth 2.0 authorization code grant flow. By configuring the authorization endpoint, client ID, and client secret, the Logic App can initiate the OAuth flow, handle user consent, and acquire an access token to authenticate requests to the external API. This built-in capability minimizes development effort for integrating with standard OAuth 2.0 protected services.

Why this answer

The 'HTTP' action with 'OAuth 2.0' authentication type in Azure Logic Apps is specifically designed to handle the authorization code grant flow, including interactive user consent. It manages the token lifecycle (acquisition, refresh, and storage) automatically, minimizing development effort. You only need to configure the authorization endpoint, client ID, and client secret, and the runtime handles the redirect and token exchange.

Exam trap

The trap here is that candidates often confuse 'Managed identity' (which is for Azure AD resources without user interaction) with OAuth 2.0 flows that require interactive consent, or they overcomplicate the solution by choosing a custom connector when the built-in 'HTTP' action already supports the authorization code grant natively.

How to eliminate wrong answers

Option B is wrong because the 'HTTP + Swagger' action with 'Identity Provider' authentication is used for calling APIs described by a Swagger/OpenAPI definition, not for OAuth 2.0 authorization code grant with interactive consent; it relies on a pre-configured identity provider (like Azure AD) and does not support the interactive user consent flow. Option C is wrong because using an 'API Connection' action with a custom connector that uses OAuth 2.0 requires you to build and manage a custom connector, which increases development effort and does not minimize it; the built-in 'HTTP' action is simpler. Option D is wrong because 'Managed identity' authentication is intended for authenticating to Azure resources (e.g., Azure Key Vault, Azure SQL) without user interaction, and it cannot handle the OAuth 2.0 authorization code grant that requires interactive user consent.

Practice this question →

121

MCQhard

You are querying Azure Monitor metrics using Kusto Query Language (KQL). The query is supposed to return average metric values per hour per resource provider, but it returns no results. What is the most likely issue?

A.The ORDER BY clause should be before GROUP BY.

B.The 'bin' function is used incorrectly; it should be 'bin(TimeGenerated, 1h)' without the alias.

C.The table name should be 'AzureMetrics' instead of 'metrics'.

D.The GROUP BY clause cannot include a computed column like 'bin'.

AnswerC

Azure Monitor resource metrics, when ingested into a Log Analytics workspace, are specifically stored in the 'AzureMetrics' table. The table name 'metrics' is not a standard or recognized table for this type of data within a Log Analytics workspace. Therefore, any KQL query attempting to retrieve Azure Monitor metrics must explicitly reference 'AzureMetrics' to access the relevant time-series data and associated dimensions.

Why this answer

C is correct because the Azure Monitor metrics table is named 'AzureMetrics', not 'metrics'. When querying Azure Monitor metrics using KQL, referencing the wrong table name will result in no results being returned, as the query engine cannot find the specified table.

Exam trap

The trap here is that candidates may assume the table is simply named 'metrics' based on general database conventions, but Azure Monitor specifically uses 'AzureMetrics' as the table name for metric data.

How to eliminate wrong answers

Option A is wrong because ORDER BY is typically placed after GROUP BY in KQL, and the order of clauses does not affect whether results are returned; it only affects sorting. Option B is wrong because 'bin(TimeGenerated, 1h)' is a valid syntax and does not require an alias; the alias is optional and does not cause the query to return no results. Option D is wrong because GROUP BY can include computed columns like 'bin', and this is a common practice in KQL for aggregating data into time buckets.

Practice this question →

122

MCQhard

You are designing a solution that requires asynchronous processing of messages from an Azure Service Bus queue. The solution must guarantee at-least-once delivery and handle poison messages automatically. Which combination of Service Bus features should you use?

A.ReceiveAndDelete mode with a separate dead-letter queue

B.ReceiveAndDelete mode with automatic forwarding

C.PeekLock mode with sessions

D.PeekLock mode with dead-letter queue

AnswerD

PeekLock mode is the correct choice for reliable asynchronous processing because it ensures at-least-once delivery. When a message is received in PeekLock mode, it is locked for a configurable duration, making it invisible to other consumers. If processing fails, the lock expires or the message is explicitly abandoned, making it available for redelivery. After a message exceeds the MaxDeliveryCount due to repeated failures, Azure Service Bus automatically moves it to the associated dead-letter queue, allowing for later inspection and manual reprocessing of poison messages.

Why this answer

PeekLock mode is required for at-least-once delivery because it allows the consumer to process the message and then explicitly complete it, ensuring the message is not removed from the queue until processing succeeds. The dead-letter queue automatically handles poison messages by moving messages that exceed the maximum delivery count or fail processing, preventing them from blocking the queue.

Exam trap

The trap here is that candidates often confuse sessions with poison message handling, but sessions are for message ordering and grouping, not for automatically moving failed messages to a dead-letter queue.

How to eliminate wrong answers

Option A is wrong because ReceiveAndDelete mode removes the message from the queue immediately upon retrieval, which cannot guarantee at-least-once delivery if the consumer crashes after receiving but before processing. Option B is wrong because ReceiveAndDelete mode with automatic forwarding still removes the message immediately, and automatic forwarding does not provide poison message handling—it simply routes messages to another queue or topic. Option C is wrong because while PeekLock mode supports at-least-once delivery, sessions are used for ordered processing and grouping related messages, not for automatic poison message handling; dead-letter queue is the feature designed for that purpose.

Practice this question →

123

MCQeasy

Messages failing to process are redelivered by Azure Service Bus. After a message has been delivered and abandoned the maximum number of times (MaxDeliveryCount), where does Service Bus move the message?

A.The message is moved to the dead-letter sub-queue of the original queue

B.The message is permanently deleted from the queue

C.The message is returned to the front of the queue with its DeliveryCount reset to zero

D.The message expires and is discarded according to the Time-to-Live setting

AnswerA

When a message's DeliveryCount property exceeds the MaxDeliveryCount setting on an Azure Service Bus queue or subscription, the Service Bus automatically moves that message to the associated dead-letter sub-queue. This action is performed by the Service Bus runtime itself, ensuring that messages that cannot be processed after multiple attempts are isolated for further inspection. The DeadLetterReason property of the message will be set to 'MaxDeliveryCountExceeded' in the dead-letter queue.

Why this answer

When a message in Azure Service Bus is delivered and abandoned the maximum number of times (as defined by the MaxDeliveryCount property, default 10), the message is automatically moved to the dead-letter sub-queue of the original queue. This dead-letter sub-queue stores messages that cannot be processed successfully, allowing you to inspect and handle them separately without losing the message entirely.

Exam trap

The trap here is that candidates often assume messages are simply deleted or returned to the queue when the delivery count is exceeded, but Azure Service Bus explicitly moves them to a dead-letter sub-queue to ensure no data loss and to provide a mechanism for manual handling.

How to eliminate wrong answers

Option B is wrong because Service Bus does not permanently delete messages that exceed MaxDeliveryCount; instead, it moves them to the dead-letter sub-queue to preserve them for later analysis. Option C is wrong because returning the message to the front of the queue with a reset DeliveryCount would defeat the purpose of the MaxDeliveryCount limit and could cause infinite processing loops. Option D is wrong because the Time-to-Live (TTL) setting controls message expiration independently of MaxDeliveryCount; a message that exceeds MaxDeliveryCount is moved to the dead-letter sub-queue regardless of its TTL, unless the TTL expires first.

Practice this question →

124

Multi-Selectmedium

Which THREE Azure services can be used to send email notifications from an application?

Select 3 answers

A.Azure Event Grid

B.Azure Logic Apps

C.Azure Communication Services Email

D.Azure Functions (with SendGrid binding)

E.Azure Service Bus

AnswersB, C, D

Azure Logic Apps provide a serverless workflow engine to integrate applications, data, services, and systems. It offers a vast library of pre-built connectors, including direct integrations with popular email services like Office 365 Outlook, Gmail, and SendGrid, allowing developers to easily design workflows that send email notifications based on various triggers and actions without writing custom code.

Why this answer

Azure Logic Apps is correct because it provides built-in connectors (e.g., Office 365 Outlook, SMTP, SendGrid) that allow you to design workflows to send email notifications without writing custom code. You can trigger these workflows from various sources (HTTP requests, timers, Azure services) and include conditional logic, making it a serverless, low-code solution for email notifications.

Exam trap

The trap here is that candidates often confuse Azure Event Grid or Service Bus as email-sending services because they are messaging/event services, but they lack native email delivery capabilities and require additional services to actually send the email.

Practice this question →

125

MCQeasy

You run the following PowerShell script to upload a blob to Azure Storage: ```powershell $context = New-AzStorageContext -StorageAccountName 'mystorageaccount' -StorageAccountKey 'fakekey...' Set-AzStorageBlobContent -Context $context -Container 'mycontainer' -Blob 'myblob' -File 'This is the file content' ``` The script fails with an error. Which part of the script is causing the failure?

A.The storage account name 'mystorageaccount' is invalid.

B.The connection string format is incorrect.

C.The -File parameter should be a file path, not a string.

D.The container name 'mycontainer' does not exist.

AnswerC

This option is correct because the Set-AzStorageBlobContent cmdlet's -File parameter is specifically designed to accept a *local file path* as its argument. It expects to read content from an existing file on the local filesystem. If a literal string, such as "Hello World," is passed directly to -File, the cmdlet will attempt to interpret that string as a file path, which will fail because no such file exists, leading to an error during the content upload. To upload a string directly as blob content, the -Value parameter should be used instead.

Why this answer

The script fails because the `-File` parameter of `Set-AzStorageBlobContent` expects a local file path, but the script passes raw content as a string literal. The cmdlet cannot find a file with that path, so it throws an error.

Exam trap

The trap here is that candidates confuse the `-File` parameter (which expects a file path) with the `-Value` parameter (which accepts raw content), leading them to incorrectly assume the error is about storage account names, connection strings, or container existence.

How to eliminate wrong answers

Option A is wrong because 'mystorageaccount' is a valid placeholder name; the error is not about account name validity but about the -File parameter. Option B is wrong because the connection string format 'DefaultEndpointsProtocol=https;AccountName=mystorageaccount;AccountKey=...' is syntactically correct for Azure Storage. Option D is wrong because the container 'mycontainer' would be created automatically by the -Force parameter or the script would fail earlier if it didn't exist, but the actual error occurs before container validation due to the -File parameter issue.

Practice this question →

126

MCQhard

Your application uses Azure Cosmos DB for NoSQL. You need to implement server-side computed properties that depend on multiple document fields. The computation must be performed atomically. Which approach should you use?

A.Use a pre-trigger to compute the property on write

B.Use the change feed to compute the property asynchronously

C.Use a user-defined function (UDF) in queries

D.Use a stored procedure to compute and update the property in a single transaction

AnswerD

Stored procedures in Azure Cosmos DB for NoSQL are JavaScript functions executed directly on the database engine within a single transaction. They provide full ACID (Atomicity, Consistency, Isolation, Durability) guarantees for all operations performed within a single logical partition. This ensures that if a stored procedure computes a property and then updates the document, either all operations commit successfully as a single unit, or none do, guaranteeing the atomic persistence of the computed property with the document's state.

Why this answer

Stored procedures in Azure Cosmos DB for NoSQL execute within a transactional scope, allowing you to atomically compute a property based on multiple document fields and update the document in a single operation. This ensures that the computation and update are performed as an all-or-nothing unit, which is required for atomicity. Pre-triggers, change feeds, and UDFs do not provide atomic read-modify-write semantics across multiple fields.

Exam trap

The trap here is that candidates often confuse the atomic execution of a stored procedure with the eventual consistency of the change feed or the query-time computation of a UDF, failing to recognize that only stored procedures provide a transactional scope for read-modify-write operations on the same document.

How to eliminate wrong answers

Option A is wrong because pre-triggers run before a write operation but cannot atomically read the existing document fields, compute a new property, and update the same document in a single transaction—they only modify the document being written. Option B is wrong because the change feed processes changes asynchronously, which breaks atomicity; the computed property would be applied in a separate operation, not within the same transaction as the original write. Option C is wrong because user-defined functions (UDFs) are stateless and only compute values at query time; they cannot persist computed properties back to the document or guarantee atomic updates.

Practice this question →

127

MCQmedium

You are developing a microservice that processes images. After processing, it needs to store the result in Azure Blob Storage and send a message to Azure Service Bus for further processing. Which Azure SDK client should you use to minimize overhead?

A.Use the Azure.Storage.Blobs and Azure.Messaging.ServiceBus NuGet packages

B.Deploy the microservice as an Azure Function

C.Call the Azure REST APIs directly using HttpClient

D.Use Azure SignalR Service for messaging

AnswerA

For a microservice processing images, Azure Blob Storage is the standard solution for storing the images, and the Azure.Storage.Blobs NuGet package provides a robust, idiomatic .NET client library for interacting with it. Similarly, Azure Service Bus is a highly reliable enterprise-grade messaging service ideal for asynchronous communication between microservices, and the Azure.Messaging.ServiceBus package offers a high-performance, feature-rich client for sending and receiving messages, enabling efficient decoupled processing workflows.

Why this answer

The Azure.Storage.Blobs and Azure.Messaging.ServiceBus NuGet packages are the official, high-level Azure SDK client libraries that provide optimized, asynchronous APIs for interacting with Azure Blob Storage and Azure Service Bus. These libraries handle connection pooling, retry policies, serialization, and authentication automatically, minimizing overhead compared to lower-level approaches.

Exam trap

The trap here is that candidates may confuse a hosting option (Azure Functions) or a different service (SignalR) with the correct client library, or assume that raw REST calls are simpler when they actually introduce more overhead due to manual protocol handling.

How to eliminate wrong answers

Option B is wrong because deploying the microservice as an Azure Function does not change the SDK client used to interact with Blob Storage or Service Bus; it is a hosting model, not a client library, and introduces additional overhead from the Functions runtime. Option C is wrong because calling the Azure REST APIs directly using HttpClient requires manual handling of authentication (e.g., SAS tokens or OAuth), retry logic, and request/response serialization, which increases development and operational overhead. Option D is wrong because Azure SignalR Service is designed for real-time web messaging (e.g., WebSocket push), not for queue-based or pub/sub messaging patterns like Service Bus, and using it would add unnecessary complexity and protocol mismatch.

Practice this question →

128

MCQmedium

A company uses Azure Logic Apps to integrate with a third-party CRM system. The CRM API requires OAuth 2.0 authentication. The developer needs to securely store the client secret and refresh token. Which Azure service should the developer use?

A.Azure App Configuration

B.Azure Key Vault

C.Azure Managed Identity

D.Azure SQL Database

AnswerB

Azure Key Vault is the dedicated Azure service for securely storing and managing cryptographic keys, certificates, and secrets, including API keys, connection strings, and OAuth tokens. It provides robust security features such as hardware security module (HSM)-backed protection, granular access policies, and comprehensive auditing capabilities. Logic Apps can seamlessly integrate with Key Vault to retrieve these secrets at runtime, ensuring credentials are never exposed in application code or configuration.

Why this answer

Azure Key Vault is the correct service because it provides a secure, centralized store for secrets such as client secrets and refresh tokens. By storing these sensitive values in Key Vault, the developer can reference them in the Logic App workflow using the Key Vault connector, ensuring that secrets are never exposed in code or configuration. This aligns with the OAuth 2.0 requirement to protect long-lived credentials like refresh tokens.

Exam trap

The trap here is that candidates often confuse Azure Managed Identity with a secret storage solution, not realizing that Managed Identity is an authentication mechanism for Azure resources, not a service for storing arbitrary secrets like OAuth client secrets or refresh tokens.

How to eliminate wrong answers

Option A is wrong because Azure App Configuration is designed for managing application configuration settings (e.g., feature flags, connection strings) but does not provide the same level of encryption, access policies, or audit logging as Key Vault for secrets; it is not a secure secret store. Option C is wrong because Azure Managed Identity provides an automatically managed service principal for authenticating to Azure services without storing credentials, but it cannot be used to store or retrieve arbitrary secrets like a client secret or refresh token; it is an identity, not a secret store. Option D is wrong because Azure SQL Database is a relational database service and is not designed for secure secret storage; storing secrets directly in a database would expose them to SQL injection risks and lack the built-in encryption and access control features of Key Vault.

Practice this question →

129

MCQhard

A system receives high-volume event notifications from Azure resources and routes them to serverless handlers. Events are lightweight and should use native event routing. Which service should be used? The architecture review board prefers a managed Azure-native control.

A.Azure DNS

B.Azure Event Grid

C.Azure Files

D.Azure Service Bus queue

AnswerB

Azure Event Grid delivers lightweight, discrete event notifications from Azure resources to serverless handlers through native, managed event routing. It satisfies the stem's requirement for high-volume, Azure-native event distribution, unlike storage-queue polling or Service Bus messaging, which target different patterns. Event Grid's push model and first-class Azure resource integration make it the appropriate choice here.

Why this answer

Azure Event Grid is the correct choice because it is a fully managed event routing service designed for high-volume, lightweight event notifications using native event routing (HTTP push). It directly supports Azure resource events and serverless handlers like Azure Functions, aligning with the requirement for native event routing without polling or queuing overhead.

Exam trap

The trap here is confusing Azure Event Grid (push-based, lightweight event routing) with Azure Service Bus (pull-based, durable messaging), leading candidates to choose Service Bus for its familiarity with queuing, despite the requirement for native event routing.

How to eliminate wrong answers

Option A is wrong because Azure DNS is a domain name resolution service, not an event routing service; it cannot handle event notifications or trigger serverless handlers. Option C is wrong because Azure Files provides managed file shares via SMB/NFS protocols, which are unsuitable for event-driven, lightweight event routing. Option D is wrong because Azure Service Bus queue is a message broker for ordered, durable messaging with pull-based consumption, not a native event routing service for lightweight, push-based events.

Practice this question →

130

MCQhard

A.Azure DNS

B.Azure Event Grid

C.Azure Files

D.Azure Service Bus queue

AnswerB

Azure Event Grid is a native, lightweight event-routing service that pushes discrete event notifications to serverless handlers via subscriptions. This satisfies the requirement for high-volume, lightweight events using native event routing rather than queuing or streaming.

Why this answer

Azure Event Grid is the correct choice because it is a fully managed event routing service designed for high-volume, lightweight event notifications using native event routing (HTTP-based push model). It supports serverless handlers like Azure Functions and automatically delivers events to subscribers with built-in retry and dead-lettering, making it ideal for reacting to Azure resource state changes.

Exam trap

The trap here is confusing Azure Event Grid (push-based, lightweight event routing) with Azure Service Bus (pull-based, message queuing), leading candidates to choose Service Bus for event scenarios when Event Grid is the native, serverless-optimized choice.

How to eliminate wrong answers

Option A is wrong because Azure DNS is a domain name resolution service (translates domain names to IP addresses) and does not handle event routing or serverless event processing. Option C is wrong because Azure Files provides fully managed file shares accessible via SMB or NFS protocols, not event notification or routing capabilities. Option D is wrong because Azure Service Bus queue is a message broker designed for reliable, ordered message delivery with features like sessions and transactions, but it uses pull-based messaging and is not optimized for lightweight, native event routing; it is better suited for decoupled messaging with complex processing requirements.

Practice this question →

131

MCQeasy

You need to send notifications to mobile devices when a new file is uploaded to Azure Blob Storage. Which Azure service should you use to route the event to a notification hub?

A.Azure Service Bus

B.Azure Queue Storage

C.Azure Event Grid

D.Azure Event Hubs

AnswerC

Azure Event Grid is the correct choice because it is a fully managed event routing service designed for building reactive, event-driven architectures. It enables you to easily publish events from various sources and deliver them to multiple subscribers, including Azure Functions or Logic Apps, which can then trigger mobile notifications. Its publish-subscribe model and ability to filter events make it ideal for efficiently fanning out discrete events to diverse endpoints for real-time alerts.

Why this answer

Azure Event Grid is the correct choice because it provides a fully managed event routing service that can react to Blob Storage events (such as 'BlobCreated') and deliver them directly to Azure Notification Hubs. This enables push notifications to mobile devices without polling or custom middleware, using a publish-subscribe model with low latency.

Exam trap

The trap here is confusing event-driven routing (Event Grid) with message queuing (Service Bus or Queue Storage) or data streaming (Event Hubs), leading candidates to pick a wrong option that handles different workloads like ordered processing or high-throughput ingestion.

How to eliminate wrong answers

Option A is wrong because Azure Service Bus is a message broker designed for enterprise messaging, command-and-control patterns, and ordered delivery, not for event-driven routing to Notification Hubs. Option B is wrong because Azure Queue Storage is a simple message queue for decoupling components, but it lacks built-in event filtering and direct integration with Notification Hubs for push notifications. Option D is wrong because Azure Event Hubs is optimized for high-throughput telemetry ingestion and big data streaming, not for event routing to Notification Hubs with event subscription capabilities.

Practice this question →

132

MCQmedium

You are building an Azure Logic App that must send email notifications via Office 365 when a new order is placed. You need to securely store the Office 365 credentials and reference them in the Logic App. Which approach should you use?

A.Store the credentials in a variable within the Logic App designer

B.Use an Azure Key Vault action with a connection that uses a username and password

C.Use an Azure Key Vault connector with a managed identity assigned to the Logic App

D.Store the credentials in an Azure Storage table and fetch them in the Logic App

AnswerC

Using an Azure Key Vault connector with a managed identity assigned to the Logic App is the most secure and recommended approach. The Logic App receives an identity from Azure Active Directory, which is then granted specific access policies on Key Vault. This eliminates the need for any developer-managed secrets or connection strings for Key Vault authentication, establishing a secure, credential-less connection to retrieve the Office 365 credentials at runtime.

Why this answer

Using an Azure Key Vault connector with a managed identity assigned to the Logic App allows you to securely store Office 365 credentials in Key Vault and authenticate to it without hardcoding secrets or managing credentials. The managed identity provides an Azure AD-backed identity for the Logic App, eliminating the need for username/password in connection strings and enabling secure, auditable access to secrets.

Exam trap

The trap here is that candidates often confuse using a Key Vault action with a username/password connection (Option B) as secure, when in fact the connection itself still stores credentials, whereas a managed identity eliminates credential storage entirely.

How to eliminate wrong answers

Option A is wrong because storing credentials in a variable within the Logic App designer exposes them in plain text in the workflow definition and logs, violating security best practices. Option B is wrong because using an Azure Key Vault action with a connection that uses a username and password still requires you to store and manage those credentials in the connection definition, defeating the purpose of Key Vault and introducing a security risk. Option D is wrong because storing credentials in an Azure Storage table is insecure (data is not encrypted at rest by default unless client-side encryption is used) and introduces unnecessary complexity and latency when fetching secrets at runtime.

Practice this question →

133

MCQhard

Refer to the exhibit. The exhibit shows an Azure Event Grid subscription configuration. You notice that the webhook endpoint is not receiving events when a .png file is uploaded to the 'images' container. What is the most likely reason?

A.The subscription is disabled

B.The destination endpoint type is incorrect

C.The webhook endpoint requires authentication

D.The subject filter excludes .png files

AnswerD

Event Grid subscriptions apply subject filters to each event's subject string, and a filter that excludes .png means those uploads never match, so the webhook receives nothing. The stem's constraint is that only .png uploads fail, which a subject filter explains precisely.

Why this answer

The exhibit shows an Event Grid subscription with a subject filter configured to only include events where the subject ends with '.jpg'. Since a .png file upload would have a subject ending in '.png', the filter excludes it, preventing the event from being sent to the webhook endpoint. Therefore, the subject filter is the most likely reason the webhook is not receiving .png file events.

Exam trap

The trap here is that candidates often overlook subject filtering as the cause of selective event delivery, assuming instead that the webhook endpoint is misconfigured or that authentication is the issue, when in fact the filter is silently discarding events based on the subject string.

How to eliminate wrong answers

Option A is wrong because if the subscription were disabled, no events would be received for any file type, not just .png files. Option B is wrong because the destination endpoint type (Webhook) is correct for receiving events at an HTTP endpoint; the issue is not about the endpoint type but about filtering. Option C is wrong because if the webhook endpoint required authentication, the event delivery would fail with a 401 or 403 error, but the question states the endpoint is 'not receiving events'—this could be due to validation handshake failure, but the exhibit shows no authentication configuration, and the most common cause for selective file type exclusion is subject filtering.

Practice this question →

134

MCQhard

You are using Azure Logic Apps to orchestrate a workflow that calls a third-party API. The API occasionally returns HTTP 429 (Too Many Requests). How should you handle this to ensure the workflow completes successfully without manual intervention?

A.Increase the timeout value for the HTTP request.

B.Change the concurrency setting to 1 to avoid multiple requests.

C.Use a webhook action instead of HTTP.

D.Configure a retry policy on the HTTP action with exponential backoff.

AnswerD

Configuring a retry policy on the HTTP action with exponential backoff is the correct and most robust solution for handling transient errors like HTTP 429 (Too Many Requests). This policy automatically reattempts the failed request after a calculated delay, which increases with each subsequent retry, preventing the Logic App from overwhelming the target service further. Exponential backoff allows the external service time to recover from the high load, significantly improving the workflow's resiliency.

Why this answer

Azure Logic Apps supports configuring a retry policy on HTTP actions, and using exponential backoff is the standard approach to handle HTTP 429 responses. The retry policy automatically waits for increasing intervals between attempts, respecting the 'Retry-After' header if present, which allows the third-party API to recover from rate limiting without manual intervention.

Exam trap

The trap here is that candidates often confuse concurrency control (Option B) with retry logic, mistakenly thinking limiting parallel requests prevents 429 errors, but 429 can still occur from a single request if the API's rate limit is per-request or per-account, not per-concurrent-call.

How to eliminate wrong answers

Option A is wrong because increasing the timeout value only extends how long the Logic App waits for a single HTTP response; it does not address the rate-limiting error (429) and will still result in failure if the request is rejected. Option B is wrong because changing concurrency to 1 limits the number of parallel requests but does not retry failed requests; a single request that receives a 429 will still fail without a retry mechanism. Option C is wrong because a webhook action is used for asynchronous callbacks, not for handling retries or rate-limiting responses; it does not automatically retry on 429 errors.

Practice this question →

135

MCQmedium

You develop an app that uses Azure Cosmos DB for NoSQL. The app requires reading a specific item by ID with low latency. You need to ensure the query is as fast as possible. What should you use?

A.Use a stored procedure that reads the item.

B.Use a SQL query filtering by ID without partition key.

C.Use a point read with the item's ID and partition key.

D.Use a SQL query with a composite index on ID.

AnswerC

A point read retrieves a single item directly by its ID and partition key, bypassing the query engine entirely. This satisfies the low-latency requirement, since it avoids cross-partition fan-out and index traversal, consuming minimal request units. Supplying both keys routes the request straight to the correct partition.

Why this answer

A point read by ID and partition key is the fastest operation in Cosmos DB, directly accessing the item without query engine overhead. Option A is wrong because stored procedures still involve query processing and are not as fast as point reads. Option B is wrong because cross-partition queries add latency.

Option D is wrong because even with a composite index, a SQL query requires query engine processing, whereas a point read is a direct lookup.

Practice this question →

136

MCQhard

Your team is migrating a legacy application to Azure. The application uses a proprietary database that is not supported by Azure SQL or Cosmos DB. You need to provide a managed database service with minimal rearchitecture. Which Azure service should you use?

A.Azure Virtual Machines with the database software installed

B.Azure Database for MySQL

C.Azure Database Migration Service

D.Azure SQL Database

AnswerA

Azure Virtual Machines (VMs) provide an Infrastructure-as-a-Service (IaaS) offering, granting complete control over the operating system and installed software. This flexibility is crucial when migrating legacy applications that rely on specific, potentially uncommon, or highly customized database software not available as a managed PaaS offering in Azure. By deploying a VM, your team can install and configure any required database engine, ensuring full compatibility with the existing application's data layer and operational requirements, thus minimizing refactoring efforts.

Why this answer

Azure Virtual Machines (IaaS) is the correct choice because the proprietary database is not supported by any Azure PaaS database service. By deploying the database software on a VM, you retain full control over the database engine and configuration, enabling a lift-and-shift migration with minimal rearchitecture. This approach avoids the need to rewrite application code or adapt to a different database schema.

Exam trap

The trap here is that candidates may confuse Azure Database Migration Service (a migration tool) with a managed database service, or assume that any database can be migrated to a PaaS offering like Azure SQL Database, ignoring the proprietary database constraint.

How to eliminate wrong answers

Option B is wrong because Azure Database for MySQL is a managed PaaS service for MySQL databases only, and it cannot run a proprietary database engine. Option C is wrong because Azure Database Migration Service is a tool for migrating supported databases (e.g., SQL Server, MySQL, PostgreSQL) to Azure PaaS services, not a managed database service itself. Option D is wrong because Azure SQL Database is a managed relational database service that supports only Microsoft SQL Server and its variants, not a proprietary database.

Practice this question →

137

MCQmedium

An application publishes order events that multiple independent subscribers must process. Subscribers may be added later without changing the publisher. Which Azure messaging service should be used? The team wants the control to be enforceable during normal operations.

A.Azure Blob Storage lifecycle policy

B.Azure Storage Queue

C.Azure Cache for Redis list only

D.Azure Service Bus topic

AnswerD

Azure Service Bus Topics are purpose-built for enterprise-grade asynchronous messaging, specifically implementing the publish-subscribe pattern. Publishers send messages to a topic, and multiple independent applications can each create their own distinct subscriptions to that topic. Each subscription receives a copy of the messages published to the topic, enabling diverse consumers to process the same event concurrently and independently. This service provides robust features like message filtering, dead-lettering, and guaranteed delivery, making it ideal for distributing events to multiple systems.

Why this answer

Azure Service Bus topics support a publish/subscribe pattern where multiple independent subscribers can each receive a copy of every published message. Subscribers can be added later without modifying the publisher, and the team can enforce control during normal operations using topic-level authorization rules and subscription filters.

Exam trap

The trap here is that candidates often confuse Azure Storage Queue (point-to-point) with Service Bus topics (pub/sub), missing the requirement for multiple independent subscribers that can be added later without changing the publisher.

How to eliminate wrong answers

Option A is wrong because Azure Blob Storage lifecycle policies automate tiering or deletion of blobs based on age, not message delivery to multiple subscribers. Option B is wrong because Azure Storage Queue implements a point-to-point messaging model where each message is consumed by a single consumer, not broadcast to multiple independent subscribers. Option C is wrong because Azure Cache for Redis list only provides a simple list data structure for ordered storage, not a managed pub/sub messaging system with durable delivery and subscriber management.

Practice this question →

138

MCQhard

A company uses Azure Service Bus to receive order messages. Each order message must be processed exactly once, and duplicate messages are not tolerated due to financial transactions. However, the order processing system sometimes fails and retries, leading to potential duplicates. What Service Bus feature should be enabled on the message to support idempotent processing?

A.Scheduled delivery

B.Duplicate detection

C.Message sessions

D.Auto-forwarding

AnswerB

Azure Service Bus duplicate detection leverages a configurable history window to track MessageId values of all messages sent to a queue or topic. When a new message arrives with a MessageId that matches one within the detection window, Service Bus automatically discards the duplicate, ensuring that each message is processed exactly once by the consuming application. This feature is crucial for idempotent message processing, preventing unintended side effects from retries or network issues.

Why this answer

B is correct because Azure Service Bus's duplicate detection feature uses a user-defined MessageId to identify and discard duplicate messages within a specified time window (default 10 minutes, configurable up to 7 days). This ensures exactly-once processing by preventing the same order message from being processed multiple times, even if the sender retries due to failures.

Exam trap

The trap here is that candidates often confuse message sessions (which guarantee order and grouping) with duplicate detection, but sessions do not prevent duplicates—they only ensure FIFO delivery within a session.

How to eliminate wrong answers

Option A is wrong because scheduled delivery delays message availability until a specified time, which does not prevent duplicate processing. Option C is wrong because message sessions enable ordered processing and grouping of related messages, but they do not inherently detect or discard duplicates. Option D is wrong because auto-forwarding automatically moves messages from one queue or subscription to another, which does not provide any duplicate detection or idempotency guarantee.

Practice this question →

139

MCQhard

You develop an IoT solution using Azure IoT Hub. Devices send telemetry data that must be processed by a custom Azure Function. You need to ensure that the Function processes messages in order per device and exactly once. Which IoT Hub feature should you use?

A.Use IoT Hub message routing to send messages to a Service Bus queue, and process from the queue.

B.Use IoT Hub direct methods to invoke the Function per device.

C.Use IoT Hub device twins to store telemetry and trigger the Function on twin changes.

D.Use IoT Hub's built-in Event Hub-compatible endpoint with a consumer group that has one partition per device.

AnswerD

IoT Hub's built-in endpoint is fully compatible with Azure Event Hubs, making it the ideal choice for high-throughput telemetry ingestion. By configuring devices to use their Device ID as the partition key, all messages from a specific device are guaranteed to be routed to the same Event Hub partition. This ensures message ordering *per device* within that partition, and processing with a dedicated consumer group per partition allows for scalable, ordered, and at-least-once delivery, with idempotent processing achieving exactly-once semantics.

Why this answer

IoT Hub's built-in Event Hub-compatible endpoint supports partitioning, and by using a consumer group with one partition per device, you can guarantee per-device ordering and exactly-once processing. The Event Hub model ensures that messages from the same device (same partition key) are delivered in order and can be checkpointed to avoid duplicates.

Exam trap

The trap here is that candidates often confuse IoT Hub's message routing (which can send to multiple endpoints) with the built-in Event Hub-compatible endpoint, not realizing that only the latter provides the partition-based ordering and checkpointing needed for per-device exactly-once processing.

How to eliminate wrong answers

Option A is wrong because IoT Hub message routing to a Service Bus queue does not guarantee per-device ordering across multiple partitions, and Service Bus queues do not natively support partition-based ordering per device without additional complexity. Option B is wrong because direct methods are synchronous request-reply operations for immediate device commands, not designed for processing telemetry streams with ordering and exactly-once guarantees. Option C is wrong because device twins are for state synchronization and desired/reported properties, not for telemetry streaming; triggering a function on twin changes does not provide ordered, exactly-once message processing.

Practice this question →

140

MCQmedium

A developer is creating an Azure Logic App that must call an external REST API. The API requires an OAuth 2.0 access token from Azure AD. The Logic App will run on a schedule and must authenticate without user interaction. The developer has registered an app in Azure AD and has a client secret. Which action should the developer take to configure the Logic App to authenticate to the API?

A.Use the HTTP action with a managed identity and assign the identity the necessary permissions on the API.

B.Use the HTTP action with basic authentication, providing the client ID and client secret as username and password.

C.Use the HTTP action with a shared access signature (SAS) token in the header.

D.Use the HTTP action with Azure AD OAuth authentication, providing the tenant ID, client ID, and client secret.

AnswerD

The HTTP action in Logic Apps supports Azure AD OAuth authentication. By providing the tenant ID, client ID, and client secret, the Logic App can obtain an access token from Azure AD and include it in the request to the external API. This method is suitable for scheduled runs without user interaction, as it uses the client credentials flow. The app registration must have the appropriate API permissions.

Why this answer

The HTTP action in Azure Logic Apps supports Azure AD OAuth authentication. By specifying the tenant ID, client ID, and client secret, the Logic App can acquire an access token using the client credentials flow. This token is then included in the Authorization header when calling the external API.

This approach works for scheduled runs without user interaction and meets the requirement of using OAuth 2.0 from Azure AD.

Exam trap

The trap here is assuming that managed identity or basic authentication can be used, but the external API specifically requires an OAuth 2.0 token from Azure AD, which the HTTP action can provide via client credentials.

Practice this question →

141

MCQmedium

An application calls a Service Bus topic through HTTP. The developer must implement retries without overwhelming the remote system during partial outages. Which retry pattern is best?

A.Disable all timeout settings

B.Immediate infinite retries

C.Retry only after restarting the application

D.Exponential backoff with jitter and a maximum retry limit

AnswerD

Exponential backoff with jitter spaces retries increasingly apart and randomises the delay, preventing synchronised retry storms that would overwhelm the remote system during partial outages. The maximum retry limit bounds total attempts, satisfying the requirement to avoid overwhelming the service.

Why this answer

Exponential backoff with jitter and a maximum retry limit is the best pattern because it progressively increases the delay between retries, preventing the client from overwhelming the Service Bus topic during partial outages. The jitter randomizes the delay to avoid thundering herd problems, while the maximum retry limit ensures the system doesn't retry indefinitely, aligning with Azure's recommended retry guidance for HTTP-based calls to Service Bus.

Exam trap

The trap here is that candidates may confuse 'exponential backoff' with 'immediate retries' or 'infinite retries,' overlooking the critical need for jitter and a maximum retry limit to prevent overwhelming the remote system during partial outages.

How to eliminate wrong answers

Option A is wrong because disabling all timeout settings would cause the application to hang indefinitely on a single request, failing to handle partial outages and potentially exhausting resources. Option B is wrong because immediate infinite retries would flood the Service Bus topic with repeated requests during an outage, exacerbating the load and violating the principle of not overwhelming the remote system. Option C is wrong because retrying only after restarting the application introduces unnecessary downtime and delays recovery, as it doesn't leverage transient fault handling within the same application session.

Practice this question →

142

MCQeasy

Your company uses Azure API Management to expose APIs to external partners. You need to enforce throttling limits per subscription key. Which policy should you add?

A.rate-limit by key policy with @(context.Subscription.Id) as counter key

B.rate-limit policy with IP address filtering

C.rate-limit by key policy with no counter key

D.validate-jwt policy with claims check

AnswerA

The `rate-limit by key` policy in Azure API Management is the correct choice for applying throttling based on specific caller identifiers. By using `@(context.Subscription.Id)` as the counter key, the policy effectively tracks and limits the number of requests originating from each unique API subscription. This ensures that each subscriber adheres to their allocated quota, preventing any single subscription from monopolizing API resources and maintaining service stability.

Why this answer

The `rate-limit by key` policy in Azure API Management allows you to enforce throttling limits based on a specific counter key. Using `@(context.Subscription.Id)` as the counter key ensures that each subscription key is tracked individually, enabling per-subscription throttling as required.

Exam trap

The trap here is confusing the `rate-limit` policy (global) with `rate-limit by key` (scoped), leading candidates to pick Option B without realizing it lacks the per-subscription granularity required by the question.

How to eliminate wrong answers

Option B is wrong because the `rate-limit` policy without a key applies a global rate limit to all requests, not per subscription key, and IP address filtering is unrelated to subscription-based throttling. Option C is wrong because omitting the counter key in `rate-limit by key` would cause the policy to fail or apply a default behavior, not enforce per-subscription limits. Option D is wrong because `validate-jwt` is used for token validation and claims checking, not for throttling or rate limiting.

Practice this question →

143

MCQmedium

You are building an event-driven solution that processes orders from an Azure Storage Queue. Each order triggers an Azure Function. To improve reliability, you need to automatically retry processing if an exception occurs, but only up to 3 times. You must also preserve the original order message in a poison queue after max retries. Which configuration should you use in the function's host.json?

A.Set 'prefetchCount' to 3

B.Set 'newBatchThreshold' to 3

C.Set 'maxDequeueCount' to 3

D.Set 'batchSize' to 3

AnswerC

The 'maxDequeueCount' is a critical property of an Azure Storage Queue message that directly governs its retry mechanism and eventual dead-lettering. Each time a message is retrieved from the queue, its 'DequeueCount' property increments. If message processing fails and the message is not deleted within its visibility timeout, it becomes visible again, and its 'DequeueCount' further increases upon subsequent retrieval. Once this 'DequeueCount' reaches the 'maxDequeueCount' value (e.g., 3 in this scenario), the Azure Storage Queue service automatically moves the message to a designated poison message queue, preventing infinite retries and allowing for manual inspection.

Why this answer

The 'maxDequeueCount' setting in the host.json for an Azure Storage Queue-triggered function controls the number of times a message is dequeued for processing before it is moved to the poison queue. Setting it to 3 ensures that after three failed processing attempts (due to exceptions), the message is automatically redirected to the poison queue, preserving the original message for later inspection.

Exam trap

The trap here is that candidates often confuse 'maxDequeueCount' with 'batchSize' or 'prefetchCount', thinking they control retries, when in fact they control concurrency and throughput, not poison queue behavior.

How to eliminate wrong answers

Option A is wrong because 'prefetchCount' controls how many messages are fetched ahead of time to improve throughput, not retry or poison queue behavior. Option B is wrong because 'newBatchThreshold' is used with Service Bus triggers to control when a new batch is fetched, not with Storage Queue triggers. Option D is wrong because 'batchSize' determines the maximum number of messages processed simultaneously, not the retry count or poison queue handling.

Practice this question →

144

MCQmedium

A developer is configuring a web app to authenticate users with Microsoft Entra ID. The web app needs to call a downstream API that also uses Microsoft Entra ID for authentication. The developer must ensure that the web app can securely obtain access tokens for the downstream API. Which authentication flow should the developer implement?

A.OAuth 2.0 Client Credentials flow

B.OAuth 2.0 Implicit flow

C.OAuth 2.0 On-Behalf-Of flow

D.OAuth 2.0 Authorization Code flow

AnswerC

The OAuth 2.0 On-Behalf-Of (OBO) flow is precisely designed for multi-tier applications where a middle-tier service, such as a web app, needs to call a downstream API using the authenticated user's identity. The web app exchanges the initial access token (obtained during user authentication) for a new access token specifically scoped for the downstream API. This ensures that the downstream API receives a token representing the original user, allowing it to enforce user-specific permissions and maintain the user's context across service boundaries.

Why this answer

The OAuth 2.0 On-Behalf-Of (OBO) flow is the correct choice because the web app has already authenticated the user via Microsoft Entra ID and needs to exchange the user's access token for a new token to call the downstream API. This flow allows the web app to act on behalf of the authenticated user, maintaining the user's identity and consent context for the downstream API call.

Exam trap

The trap here is that candidates often confuse the On-Behalf-Of flow with the Authorization Code flow, not realizing that the Authorization Code flow only provides the initial user token and does not handle the downstream token exchange required for chained API calls.

How to eliminate wrong answers

Option A is wrong because the OAuth 2.0 Client Credentials flow is used for server-to-server authentication without a user context, which does not preserve the original user's identity for the downstream API. Option B is wrong because the OAuth 2.0 Implicit flow is deprecated and insecure for modern applications, as it returns tokens in the URL fragment and is not suitable for server-side web apps that need to call downstream APIs. Option D is wrong because the OAuth 2.0 Authorization Code flow is used to authenticate the user and obtain an initial access token for the web app, but it does not directly provide a mechanism to exchange that token for a downstream API token on behalf of the user.

Practice this question →

145

MCQmedium

An application publishes order events that multiple independent subscribers must process. Subscribers may be added later without changing the publisher. Which Azure messaging service should be used? The design must avoid adding custom operational scripts.

A.Azure Blob Storage lifecycle policy

B.Azure Storage Queue

C.Azure Cache for Redis list only

D.Azure Service Bus topic

AnswerD

Azure Service Bus Topics are specifically engineered for enterprise-grade publish-subscribe messaging scenarios, making them ideal for distributing order events to multiple independent applications. Publishers send messages to a topic, and each attached subscription receives a copy of the message, allowing for decoupled processing. This service provides advanced features like message filtering, durable message storage, and dead-lettering, ensuring reliable event distribution to all interested parties.

Why this answer

Azure Service Bus topics support a publish-subscribe pattern where multiple independent subscribers each receive a copy of every published message. This decouples the publisher from subscribers, allowing new subscribers to be added later without modifying the publisher. The built-in subscription entities eliminate the need for custom operational scripts.

Exam trap

The trap here is confusing a point-to-point queue (Storage Queue) with a publish-subscribe topic (Service Bus), where the requirement for multiple independent subscribers and future extensibility without scripts directly points to the topic's subscription model.

How to eliminate wrong answers

Option A is wrong because Azure Blob Storage lifecycle policies automate tiering or deletion of blobs based on age, not message delivery to multiple subscribers. Option B is wrong because Azure Storage Queues implement a point-to-point message queue where each message is consumed by a single worker, not broadcast to multiple independent subscribers. Option C is wrong because Azure Cache for Redis list only provides a simple list data structure; it lacks built-in publish-subscribe semantics and would require custom polling logic and scripts to distribute messages to multiple subscribers.

Practice this question →

146

MCQmedium

You are building an Azure Logic App that calls an external REST API secured with the OAuth 2.0 client credentials flow. You have registered an app in Microsoft Entra ID with client ID and client secret stored in Azure Key Vault. The Logic App uses a system-assigned managed identity with Get permission on the secret. Which action should you use in the Logic App designer to authenticate to the API?

A.HTTP action with 'Active Directory OAuth' authentication type, referencing the client ID and client secret

B.HTTP action with 'Managed Identity' authentication type

C.Invoke an API with OAuth predefined connector

D.HTTP action with 'Basic' authentication and pass the secret as password

AnswerA

This option correctly leverages the "Active Directory OAuth" authentication type within the Logic Apps HTTP action. This type is specifically designed for scenarios where a client application (like a Logic App) needs to obtain an access token from Microsoft Entra ID (formerly Azure AD) using its own identity, rather than on behalf of a user. By providing the client ID and client secret, the Logic App performs the OAuth 2.0 Client Credentials flow, allowing it to authenticate and acquire a token to call the external REST API securely.

Why this answer

The OAuth 2.0 client credentials flow requires a client ID and client secret to obtain an access token from Microsoft Entra ID. The HTTP action's 'Active Directory OAuth' authentication type directly supports this flow, allowing you to reference the client ID and the client secret stored in Azure Key Vault. The Logic App's system-assigned managed identity has Get permission on the secret, enabling it to retrieve the secret at runtime without exposing it in the workflow definition.

Exam trap

The trap here is that candidates confuse 'Managed Identity' authentication (which works only for Azure resources like Azure SQL or Storage) with the need to authenticate to an external API using OAuth client credentials, leading them to incorrectly select Option B instead of the HTTP action with Active Directory OAuth.

How to eliminate wrong answers

Option B is wrong because the 'Managed Identity' authentication type is used to authenticate to Azure resources that support managed identity (e.g., Azure Storage, Azure SQL), not to external REST APIs secured with OAuth 2.0 client credentials; it cannot provide a client ID and client secret for token acquisition. Option C is wrong because 'Invoke an API with OAuth predefined connector' is not a built-in Logic App action; there is no generic 'OAuth predefined connector' that dynamically handles client credentials with Key Vault secrets—connectors are specific to services like Microsoft Graph or Salesforce. Option D is wrong because 'Basic' authentication sends the client ID and secret as a plaintext username:password pair in the HTTP Authorization header, which violates the OAuth 2.0 client credentials flow that requires a token endpoint exchange and does not support Basic auth for bearer token issuance.

Practice this question →

147

MCQhard

You are developing a solution that processes events from Azure Event Hubs and stores them in Azure Blob Storage. The processing must be idempotent and exactly-once. Which approach should you use?

A.Use EventProcessorHost with checkpointing and blob leases to track processed events

B.Use Azure Functions with Event Hubs trigger and store events in batches

C.Use a simple consumer group and delete events after reading from Event Hubs

D.Implement a transactional outbox pattern with Azure SQL Database

AnswerA

EventProcessorHost (or the modern EventProcessorClient) is the recommended pattern for robustly consuming events from Azure Event Hubs. It automatically manages partition ownership across multiple instances using blob leases in Azure Storage, ensuring that each partition is processed by only one consumer instance at a time. Checkpointing involves periodically recording the last successfully processed event's offset and sequence number to blob storage, allowing the consumer to resume processing from the correct point after failures or rebalancing, thereby achieving at-least-once delivery and enabling idempotent processing for effective exactly-once semantics.

Why this answer

The EventProcessorHost (EPH) pattern with checkpointing and blob leases provides the foundation for exactly-once processing in Event Hubs. Checkpointing records the offset of the last successfully processed event in Azure Blob Storage, while blob leases ensure partition ownership and prevent duplicate processing by competing consumers. This combination allows the processor to resume from the last checkpoint after a failure, guaranteeing that each event is processed exactly once.

Exam trap

The trap here is that candidates often confuse 'at-least-once' delivery (which is the default for Event Hubs and Azure Functions) with 'exactly-once' processing, and they overlook the critical role of checkpointing and lease management in achieving idempotent, exactly-once semantics.

How to eliminate wrong answers

Option B is wrong because Azure Functions with Event Hubs trigger does not natively guarantee exactly-once processing; it can result in at-least-once delivery due to retries and lack of built-in idempotency enforcement. Option C is wrong because deleting events after reading from Event Hubs is not supported (Event Hubs does not allow event deletion) and consumer groups do not provide idempotent or exactly-once guarantees. Option D is wrong because the transactional outbox pattern is designed for reliable message publishing from a database, not for idempotent consumption from Event Hubs, and it introduces unnecessary complexity and latency for this scenario.

Practice this question →

148

MCQhard

You are developing a web application that relies on a third-party weather API. The API has a rate limit of 10 requests per second per API key. You need to ensure your application never exceeds this limit and also caches responses for 10 minutes to reduce call frequency. Which combination of Azure services should you implement?

A.Azure Functions with Durable Functions to throttle calls and a static in-memory cache.

B.Azure Logic Apps with a retry policy and a cache using Azure Redis Cache.

C.Azure API Management with rate-limit and caching policies.

D.Azure Traffic Manager to distribute requests and Azure Front Door for caching.

AnswerC

Azure API Management is specifically designed to act as a facade for APIs, offering robust, declarative policies for both rate limiting and caching. Its `rate-limit-by-key` or `rate-limit` policies can effectively throttle calls to the third-party API, preventing exceeding quotas, while its response caching policies significantly reduce latency and load by serving cached responses directly, improving overall application performance and resilience.

Why this answer

Azure API Management (APIM) provides built-in rate-limit and caching policies that directly address the requirements: the `rate-limit` policy enforces a per-key request quota (e.g., 10 calls/second), and the `cache-store`/`cache-lookup` policies cache responses for a configurable duration (e.g., 10 minutes). This eliminates the need for custom throttling logic or external caching services, making it the most straightforward and maintainable solution.

Exam trap

The trap here is that candidates often overcomplicate the solution by choosing a combination of services (e.g., Functions + Redis) when Azure API Management's single, purpose-built policy set directly solves both rate limiting and caching without custom code.

How to eliminate wrong answers

Option A is wrong because Durable Functions are designed for orchestrating long-running workflows, not for fine-grained per-second rate limiting, and a static in-memory cache in a serverless function app is not shared across instances, leading to cache inconsistency and potential rate-limit breaches. Option B is wrong because Azure Logic Apps' retry policy handles transient failures but does not provide proactive rate limiting, and Azure Redis Cache, while a valid distributed cache, adds unnecessary complexity and cost when APIM's built-in caching suffices. Option D is wrong because Azure Traffic Manager distributes traffic at the DNS level for global load balancing and does not enforce per-key rate limits, and Azure Front Door's caching is for static content at the edge, not for API response caching with per-key granularity.

Practice this question →

149

MCQhard

An application uses Azure Event Hubs to ingest telemetry data. The team wants to process the data in near real-time and store aggregated results in Azure SQL Database. Which Azure service should they use?

A.Azure HDInsight

B.Azure Functions

C.Azure Stream Analytics

D.Azure Data Lake Storage Gen2

AnswerC

Azure Stream Analytics is a fully managed, real-time analytics service specifically designed for processing large volumes of streaming data from sources like Azure Event Hubs. It enables users to define complex event processing (CEP) queries using a SQL-like language to filter, aggregate, and transform data in motion, often incorporating windowing functions for time-based analysis. This service is ideal for scenarios requiring low-latency insights from telemetry, allowing direct output to various sinks, including Azure SQL Database, for immediate consumption or further analysis.

Why this answer

Azure Stream Analytics is the correct choice because it is a fully managed stream processing engine designed for real-time analytics on high-throughput data from sources like Event Hubs. It can ingest telemetry data, apply SQL-based queries for aggregation (e.g., tumbling windows), and output results directly to Azure SQL Database with exactly-once semantics, meeting the near-real-time requirement.

Exam trap

The trap here is that candidates often confuse Azure Functions as a real-time stream processor, but it lacks native windowed aggregation and state management, making Stream Analytics the correct choice for this specific near-real-time aggregation requirement.

How to eliminate wrong answers

Option A is wrong because Azure HDInsight is a big data batch/processing platform (Hadoop/Spark) that is overkill for simple near-real-time aggregation and introduces significant operational overhead; it is not optimized for low-latency stream processing from Event Hubs to SQL Database. Option B is wrong because Azure Functions can process Event Hubs events but lacks built-in windowed aggregation and stateful stream processing capabilities, making it unsuitable for computing aggregated results like sums or averages over time windows without complex custom code. Option D is wrong because Azure Data Lake Storage Gen2 is a hierarchical storage service for big data analytics, not a real-time processing engine; it cannot perform aggregations or write directly to Azure SQL Database.

Practice this question →

150

MCQmedium

You are reviewing an ARM template that deploys an Azure App Service. The template sets an app setting 'MyApiKey' that references a Key Vault secret. However, the deployment fails with an error that the app service cannot access the secret. What is the most likely cause?

A.The Key Vault reference syntax '@Microsoft.KeyVault(SecretUri=...)' is incorrect.

B.The ARM template cannot use Key Vault references in app settings.

C.The secret name in the URI does not match the actual secret name.

D.The App Service does not have a managed identity enabled and the Key Vault access policy is missing.

AnswerD

For an Azure App Service to successfully retrieve a secret using a Key Vault reference, it must first be configured with a system-assigned or user-assigned managed identity. Subsequently, this managed identity requires an explicit access policy within the target Azure Key Vault, granting it 'Get' permissions on secrets. Without both the enabled managed identity and the corresponding Key Vault access policy, the App Service lacks the necessary authentication and authorization to resolve the secret, leading to a runtime failure.

Why this answer

An Azure App Service must have a managed identity enabled and the Key Vault must have an access policy granting that identity the 'Get' permission for secrets. Without these, the App Service cannot authenticate to Key Vault, causing the deployment to fail with an access error.

Exam trap

The trap here is that candidates often assume the Key Vault reference syntax is the issue, when in reality the error message 'cannot access the secret' points directly to an authentication or authorization failure, not a syntax or naming problem.

How to eliminate wrong answers

Option A is wrong because the correct Key Vault reference syntax is '@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret/)', and if it were incorrect, the error would be about parsing, not access. Option B is wrong because ARM templates can use Key Vault references in app settings; this is a supported feature for secure secret injection. Option C is wrong because a mismatched secret name would produce a 'SecretNotFound' error, not an access error.

Practice this question →