Knowledge + Practice

CCNA Connect to and consume Azure services and third-party services Questions

75 of 229 questions · Page 1/4 · Connect to and consume Azure services and third-party services · Answers revealed

Practice these questions Domain overview All questions

1

MCQhard

A company uses Azure API Management to expose APIs. They need to enforce rate limiting per subscription key and also allow a burst of requests for a short period. Which policy should they apply?

A.limit-concurrency

B.rate-limit (per product)

C.rate-limit-by-key

D.rate-limit-by-ip

AnswerC

The `rate-limit-by-key` policy is the correct choice as it specifically enforces request limits on a per-subscription-key basis, ensuring each individual API consumer is independently governed. This policy allows precise control over the number of API calls permitted within a defined time window for a unique subscriber, identified by their distinct subscription key. Its support for burst limits further enhances flexibility by allowing temporary spikes in traffic while maintaining overall rate adherence.

Why this answer

The `rate-limit-by-key` policy is correct because it allows rate limiting based on a specified key, such as a subscription key, and supports a burst configuration via the `renewal-period` and `retry-after` attributes. This policy enforces a per-key counter that resets after a defined period, enabling a burst of requests (e.g., 10 requests in 60 seconds) while still enforcing an overall limit.

Exam trap

The trap here is that candidates confuse `rate-limit-by-key` with `rate-limit (per product)`, assuming product-level limits automatically apply per subscription, but product limits aggregate all subscriptions under that product, not per individual key.

How to eliminate wrong answers

Option A is wrong because `limit-concurrency` throttles the number of simultaneous requests, not the rate over time, and does not support burst behavior or key-based scoping. Option B is wrong because `rate-limit (per product)` applies limits at the product level, not per individual subscription key, and cannot enforce per-key bursts. Option D is wrong because `rate-limit-by-ip` limits based on the caller's IP address, not the subscription key, and cannot differentiate between different subscribers behind the same IP.

Practice this question →

2

MCQhard

Your Azure App Service app uses SignalR Service to push real-time updates to clients. You notice that some clients are disconnected after 30 minutes of inactivity. What is the most likely cause and solution?

A.The app service plan is scaled down, causing idle connections to drop

B.The app service plan has an idle timeout of 30 minutes

C.The SignalR service is in serverless mode, which disconnects idle clients

D.The Azure SignalR Service has a default client timeout of 30 minutes; configure the ClientTimeout setting in the SignalR service

AnswerD

The Azure SignalR Service includes a configurable ClientTimeoutInterval property, which defaults to 30 minutes. This setting dictates the maximum period of inactivity allowed on a client connection before the service proactively terminates it. To prevent unexpected disconnections for idle clients, administrators should increase this ClientTimeoutInterval value within the SignalR Service configuration to a duration appropriate for their application's requirements.

Why this answer

The Azure SignalR Service has a default idle client timeout of 30 minutes. When a client connection remains idle (no data frames sent or received) for this duration, the service proactively closes the connection to conserve resources. To prevent this, you must configure the `ClientTimeout` setting in the SignalR service to a higher value or implement keep-alive mechanisms such as ping frames from the client.

Exam trap

The trap here is that candidates confuse the App Service plan's idle timeout (which affects the web app process) with the SignalR Service's client timeout, leading them to incorrectly select Option B, whereas the real culprit is the SignalR Service's default 30-minute idle disconnect.

How to eliminate wrong answers

Option A is wrong because scaling down the App Service plan reduces compute capacity but does not impose a 30-minute idle timeout on SignalR connections; idle connection drops due to scaling are not time-bound to exactly 30 minutes. Option B is wrong because the App Service plan's idle timeout (default 20 minutes for Always On disabled) applies to the web app process, not to SignalR Service connections, and the default is 20 minutes, not 30. Option C is wrong because SignalR Service in serverless mode does not have a built-in 30-minute idle disconnect; serverless mode uses Azure Functions and still respects the same `ClientTimeout` setting, but the default timeout is not exclusive to serverless mode.

Practice this question →

3

MCQeasy

A company uses Azure Logic Apps to integrate with a third-party REST API. The API has a rate limit of 100 requests per minute. You need to ensure that the Logic App respects this limit. Which connector feature should you configure?

A.Retry policy.

B.Concurrency control.

C.Swagger connector.

D.API Management.

AnswerB

Concurrency control in Azure Logic Apps allows developers to limit the number of workflow instances or loop iterations that can run simultaneously for a specific trigger or action. By setting a maximum concurrent run limit, the Logic App proactively throttles its own outbound requests, preventing it from overwhelming a downstream API. This mechanism directly helps in adhering to external service rate limits by controlling the rate of outgoing calls.

Why this answer

Concurrency control in Azure Logic Apps allows you to limit the number of concurrent workflow instances (when applied to the trigger) or parallel iterations (when applied to a 'For each' loop). By configuring this setting, you can proactively manage the rate at which requests are sent to an external API, helping to prevent exceeding rate limits. For example, if each Logic App run makes one API call, setting the concurrency limit on the trigger to a value that aligns with the rate limit (e.g., 100, if runs are short and the trigger fires frequently) can help throttle the overall request volume by queuing additional runs.

This proactively manages the request volume, unlike a retry policy which reacts to failures.

Exam trap

The trap here is that candidates often confuse Retry policy (which handles failures after they occur) with concurrency control (which prevents the failures by limiting parallelism), leading them to select Retry policy as a proactive solution when it is actually reactive.

How to eliminate wrong answers

Option A is wrong because Retry policy handles transient failures (e.g., HTTP 429 or 5xx) by retrying failed requests, but it does not prevent the Logic App from sending too many requests in the first place; it only reacts after a limit is exceeded. Option C is wrong because a Swagger connector is used to import an OpenAPI definition for custom API integration, not to control request rate or concurrency. Option D is wrong because API Management is an external service that can enforce rate limits via policies, but it is not a feature of the Logic App connector itself; the question asks for a connector feature to configure within the Logic App.

Practice this question →

4

MCQmedium

You are using Azure Event Grid to respond to blob storage events (blob created). You need to ensure that only JPEG image files trigger a function for processing, while other files are ignored. The number of files is high, and you want to minimize cost and latency. How should you filter events?

A.Create the function to check the blob extension at the start of the function code and return early if it's not a JPEG.

B.Configure Advanced Filters on the Event Grid subscription with a 'subjectEndsWith' condition set to '.jpg' or '.jpeg'.

C.Create separate event subscriptions for each file extension and point them to different functions.

D.Use Event Hubs capture to filter files before sending events.

AnswerB

Configuring Advanced Filters on the Event Grid subscription is the most efficient and cost-effective solution. By setting a 'subjectEndsWith' condition to '.jpg' or '.jpeg', Event Grid will inspect the event's subject property, which typically contains the blob's full path and name, and only deliver events for matching file extensions. This pre-filters events at the platform level, preventing unnecessary function invocations and significantly reducing compute costs and latency.

Why this answer

Azure Event Grid supports advanced filtering on event properties, including 'subjectEndsWith', which allows you to filter events at the service level before they are delivered to the endpoint. This ensures that only blob creation events for files ending with '.jpg' or '.jpeg' trigger the function, reducing unnecessary invocations, cost, and latency. By filtering at the Event Grid level, you avoid processing unwanted events entirely, which is more efficient than filtering within the function code.

Exam trap

The trap here is that candidates often default to filtering inside the function code (Option A) because it seems simpler, but they overlook that Event Grid's advanced filtering can prevent the function from being triggered at all, which is the key to minimizing cost and latency in high-volume scenarios.

How to eliminate wrong answers

Option A is wrong because it requires the function to be invoked for every blob creation event, including non-JPEG files, which increases cost and latency due to unnecessary function executions; this approach does not minimize cost or latency as required. Option C is wrong because creating separate event subscriptions for each file extension increases management complexity and does not provide a cost or latency benefit over a single subscription with advanced filters; it also requires multiple functions or routing logic. Option D is wrong because Event Hubs capture is designed for data ingestion and storage, not for real-time event filtering; it adds unnecessary complexity and latency compared to Event Grid's built-in filtering capabilities.

Practice this question →

5

MCQhard

Trey Research uses Azure Service Bus for messaging between microservices. One microservice written in Node.js needs to send messages to a queue. The team wants to use managed identity to authenticate to Service Bus. The microservice runs in an Azure Container Instance (ACI) with a user-assigned managed identity. The identity has been granted 'Sender' role on the Service Bus namespace. The team uses the @azure/service-bus SDK. Which code snippet should the developer use to create a ServiceBusClient?

A.const { ServiceBusClient } = require('@azure/service-bus'); const { InteractiveBrowserCredential } = require('@azure/identity'); const credential = new InteractiveBrowserCredential(); const sbClient = new ServiceBusClient('<namespace>.servicebus.windows.net', credential);

B.const { ServiceBusClient } = require('@azure/service-bus'); const { DefaultAzureCredential } = require('@azure/identity'); const credential = new DefaultAzureCredential(); const sbClient = new ServiceBusClient('<namespace>.servicebus.windows.net', credential);

C.const { ServiceBusClient } = require('@azure/service-bus'); const { ManagedIdentityCredential } = require('@azure/identity'); const credential = new ManagedIdentityCredential('<client-id>'); const sbClient = new ServiceBusClient('<namespace>.servicebus.windows.net', credential);

D.const { ServiceBusClient } = require('@azure/service-bus'); const sbClient = new ServiceBusClient('<connection-string>');

AnswerB

Correct: DefaultAzureCredential works with user-assigned MI if environment variable set.

Why this answer

DefaultAzureCredential (option B) is the correct choice because it automatically uses the managed identity of the Azure resource (ACI) when the environment variable AZURE_CLIENT_ID is set to the user-assigned identity's client ID. This approach works without hardcoding credentials. Option A (InteractiveBrowserCredential) is for interactive user scenarios and is inappropriate for a server-side application.

Option C (ManagedIdentityCredential) would also work but requires explicitly passing the client ID, which is less flexible and not the recommended pattern. Option D uses a connection string, bypassing managed identity entirely.

Practice this question →

6

MCQeasy

A developer needs to store a large number of binary files (images) that are accessed frequently from a web app. Which Azure storage solution is most cost-effective?

A.Azure Queue Storage

B.Azure Files

C.Azure Blob Storage

D.Azure Cosmos DB

AnswerC

Azure Blob Storage is purpose-built for storing massive amounts of unstructured object data, such as binary files, images, videos, and documents, at a highly scalable and cost-effective rate. It offers various access tiers (Hot, Cool, Archive) to optimize costs based on access frequency and provides direct HTTP/S access to individual blobs. Its design makes it ideal for cloud-native applications requiring global accessibility, high availability, and efficient storage for large volumes of binary content.

Why this answer

Azure Blob Storage is the most cost-effective solution for storing large numbers of binary files like images because it is optimized for massive scale, high-throughput, and low-cost object storage. It supports hot, cool, and archive access tiers to balance cost and access frequency, and it integrates directly with web apps via HTTP/HTTPS REST APIs or SDKs, making it ideal for frequently accessed static content.

Exam trap

The trap here is that candidates often confuse Azure Files with Blob Storage because both store files, but Azure Files is designed for SMB-based file shares (e.g., for legacy apps or shared drives) and is more expensive per GB than Blob Storage, making it the wrong choice for cost-effective, high-frequency binary file serving.

How to eliminate wrong answers

Option A is wrong because Azure Queue Storage is a messaging service for asynchronous communication between application components, not designed for storing or serving binary files like images. Option B is wrong because Azure Files provides fully managed SMB file shares for legacy or lift-and-shift scenarios, but it is more expensive per GB than Blob Storage and incurs additional costs for transactions and data access, making it less cost-effective for high-frequency image serving. Option D is wrong because Azure Cosmos DB is a NoSQL database optimized for low-latency, globally distributed transactional data with high throughput and indexing costs, which is overkill and significantly more expensive than Blob Storage for storing and serving static binary files.

Practice this question →

7

MCQmedium

You manage a set of APIs using Azure API Management (APIM). One backend API requires an API key passed in the 'X-API-Key' header. The API key is stored securely in a named value in APIM. You need to configure APIM to add this header to all requests to that backend without exposing the key to API consumers. Which policy should you add to the inbound processing for that API?

A.set-backend-service

B.set-header

C.authentication-basic

D.validate-jwt

AnswerB

The set-header policy is the precise solution for this requirement, as it explicitly allows for the addition, modification, or deletion of HTTP headers in either the request or response. It can be configured to add a custom header, such as X-API-Key, with its value securely retrieved from a Named Value within APIM. This approach ensures the API key remains confidential, preventing its exposure in policy definitions or to API consumers, while successfully passing it to the backend.

Why this answer

The 'set-header' policy in Azure API Management allows you to add, modify, or remove HTTP headers on requests or responses. By placing this policy in the inbound processing section, you can inject the 'X-API-Key' header with the value retrieved from a named value (using the '{{NamedValue}}' syntax) without exposing the key to API consumers, as the policy executes on the gateway side.

Exam trap

The trap here is that candidates often confuse 'set-header' with 'authentication-basic' because both deal with adding authentication-related headers, but 'authentication-basic' specifically encodes credentials in Base64 and is intended for HTTP Basic Auth, not for arbitrary API key headers.

How to eliminate wrong answers

Option A is wrong because 'set-backend-service' is used to change the backend service URL for the request, not to manipulate headers. Option C is wrong because 'authentication-basic' is used to add a Basic Authentication header (username:password encoded in Base64) to the backend request, which is not the same as adding a custom API key header. Option D is wrong because 'validate-jwt' is used to enforce the existence and validity of a JSON Web Token (JWT) in the request, not to add a header.

Practice this question →

8

MCQmedium

You are building a mobile app backend using Azure Functions. The function must send push notifications to devices using the Notification Hubs service. You need to authenticate the function to Notification Hubs using the principle of least privilege. What should you use?

A.Store the Notification Hubs connection string in Application Settings.

B.Use a managed identity assigned to the Function App to access Notification Hubs.

C.Create a shared access signature (SAS) token for the Notification Hub.

D.Use Microsoft Entra ID OAuth 2.0 client credentials flow.

AnswerB

Managed identities provide an automatically managed identity in Microsoft Entra ID for Azure services, eliminating the need for developers to manage credentials. Assigning a system-assigned or user-assigned managed identity to the Function App allows it to authenticate to Azure Notification Hubs without storing any secrets. This approach enables fine-grained access control through Azure RBAC, where specific roles, such as 'Azure Notification Hubs Data Sender' or 'Contributor', can be assigned to the managed identity, ensuring the function operates with the principle of least privilege for its required operations.

Why this answer

Using a managed identity assigned to the Function App allows it to authenticate to Azure Notification Hubs without storing any credentials in code or configuration. This follows the principle of least privilege by granting only the necessary permissions (e.g., via Azure RBAC role assignments like 'Notification Hubs Data Sender') and eliminates the risk of connection string leakage. Managed identities are the recommended approach for Azure services to securely access other Azure resources.

Exam trap

The trap here is that candidates often confuse managed identities with SAS tokens or connection strings, thinking any form of shared secret is acceptable, but the principle of least privilege demands a secretless, identity-based approach that only managed identities provide.

How to eliminate wrong answers

Option A is wrong because storing the Notification Hubs connection string in Application Settings still exposes a shared secret that grants broad permissions (e.g., manage, send, listen) and violates the principle of least privilege; it also requires manual rotation and management. Option C is wrong because creating a SAS token for the Notification Hub still relies on a shared key and does not leverage Azure RBAC; SAS tokens are typically used for fine-grained access but still embed a secret and require secure distribution. Option D is wrong because Microsoft Entra ID OAuth 2.0 client credentials flow is used for service-to-service authentication with an app registration and client secret, which still requires managing a secret and does not provide the zero-secret, identity-based access that managed identities offer.

Practice this question →

9

MCQhard

A company uses Azure Service Bus for messaging between microservices. They need to ensure that messages are processed in order within a partition. Which feature should they enable?

A.Duplicate detection

B.Partitioning

C.Sessions

D.Dead-letter queue

AnswerC

Azure Service Bus sessions enable the processing of related messages in a guaranteed First-In, First-Out (FIFO) order. By assigning a SessionId to messages, all messages belonging to that session are delivered to the same message receiver, ensuring sequential processing. This mechanism is essential for scenarios where the order of operations for a specific entity or conversation must be strictly maintained.

Why this answer

Sessions in Azure Service Bus provide strict message ordering and first-in-first-out (FIFO) guarantees within a session. By setting the SessionId property on messages, all messages with the same session ID are processed sequentially by a single receiver, ensuring order is preserved even across multiple partitions or competing consumers.

Exam trap

The trap here is that candidates often confuse partitioning with ordering, but partitioning alone does not guarantee order; sessions must be explicitly enabled to achieve FIFO processing within a partition.

How to eliminate wrong answers

Option A is wrong because duplicate detection prevents duplicate messages from being processed, but it does not enforce any ordering guarantees. Option B is wrong because partitioning improves throughput and scalability by distributing messages across multiple message brokers, but it does not guarantee order across partitions unless combined with sessions. Option D is wrong because a dead-letter queue is used to hold messages that cannot be processed successfully, not to enforce message ordering.

Practice this question →

10

MCQmedium

An application calls a Event Grid event stream 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.Disable all timeout settings

D.Exponential backoff with jitter and a maximum retry limit

AnswerD

This strategy is optimal for handling transient faults by progressively increasing the delay between retries, allowing the remote service time to recover without being overwhelmed. Jitter adds a random component to these delays, preventing a 'thundering herd' problem where multiple clients retry simultaneously and exacerbate the issue. The maximum retry limit ensures the application eventually gives up on persistent failures, conserving resources and enabling alternative error handling.

Why this answer

Exponential backoff with jitter and a maximum retry limit is the best pattern because it prevents overwhelming the Event Grid endpoint during partial outages by progressively increasing wait times between retries, while jitter randomizes those intervals to avoid thundering herd problems. The maximum retry limit ensures the system does not retry indefinitely, aligning with Event Grid's own retry policy (which uses exponential backoff up to 30 minutes and a max of 30 retries for HTTP 5xx errors). This balances resilience with resource protection.

Exam trap

The trap here is that candidates may think immediate retries or disabling timeouts are acceptable for reliability, but Azure explicitly recommends exponential backoff with jitter and a cap to protect both the client and the service from overload during outages.

How to eliminate wrong answers

Option A is wrong because immediate infinite retries would flood the Event Grid endpoint with requests during an outage, likely causing a thundering herd problem and potentially triggering rate limiting or denial-of-service conditions. Option B is wrong because retrying only after restarting the application introduces unnecessary downtime and fails to handle transient failures gracefully, as Event Grid expects clients to retry with backoff for HTTP 429 or 5xx responses. Option C is wrong because disabling all timeout settings removes critical safeguards, risking indefinite hangs and resource exhaustion, and does not address retry logic or backoff behavior.

Practice this question →

11

MCQhard

You have an Azure App Service web app that uses Azure SQL Database. The connection string is stored in Azure Key Vault. You need to automatically rotate the database password every 30 days without app downtime. Which solution should you implement?

A.Store the connection string as a Key Vault reference in App Service application settings and use Key Vault's auto-rotation.

B.Use Azure CLI to update the connection string in App Service settings.

C.Use Managed Identity to access SQL Database instead of a password.

D.Update the connection string in the application code and redeploy.

AnswerA

Key Vault reference updates automatically without restart.

Why this answer

Key Vault references in App Service application settings allow the web app to dynamically retrieve the connection string from Key Vault at runtime. By enabling Key Vault's auto-rotation feature (e.g., using a rotation function or event grid trigger), the database password can be rotated every 30 days without any app downtime, as the app reads the latest secret on each request or after a cached secret expires.

Exam trap

The trap here is that candidates may think Managed Identity (Option C) is a valid rotation solution, but it eliminates the password entirely rather than rotating it, failing the explicit requirement to rotate the database password every 30 days.

How to eliminate wrong answers

Option B is wrong because using Azure CLI to update the connection string in App Service settings would require a restart of the app service to pick up the new setting, causing downtime. Option C is wrong because while Managed Identity eliminates the need for a password, it does not address the requirement to rotate a password every 30 days; it replaces password-based authentication entirely. Option D is wrong because updating the connection string in the application code and redeploying would require a new deployment, causing downtime and violating the no-downtime requirement.

Practice this question →

12

MCQmedium

Refer to the exhibit. An Azure OpenAI Service account is deployed with this ARM template. After deployment, a developer tries to call the OpenAI endpoint from an Azure App Service that has no public IP. The request is blocked. What change should be made to allow access?

A.Add a service tag for App Service in the ipRules.

B.Configure a private endpoint for the OpenAI account.

C.Change the defaultAction to Allow.

D.Add the App Service's outbound IP address to the ipRules.

AnswerB

Configuring a private endpoint for the Azure OpenAI account establishes a secure, private connection from your Azure Virtual Network to the OpenAI service. This solution ensures that traffic between your App Service, residing within a VNet, and the OpenAI service traverses the Microsoft backbone network privately, bypassing the public internet entirely. The private endpoint assigns a private IP address from your VNet to the OpenAI resource, allowing secure access and eliminating the need to expose the OpenAI service to public IP ranges or manage outbound IP addresses.

Why this answer

The ARM template sets `networkAcls.defaultAction` to `Deny`, which blocks all traffic by default. Since the App Service has no public IP, it cannot be reached via IP-based rules. Configuring a private endpoint for the OpenAI account creates a private network connection over Azure's backbone, bypassing the public endpoint and allowing the App Service to access the OpenAI service securely without requiring a public IP.

Exam trap

The trap here is that candidates often assume IP-based firewall rules (like adding outbound IPs) are sufficient, but they overlook that an App Service without a public IP cannot be reached via IP rules, and that private endpoints are the correct solution for private, secure access to PaaS services.

How to eliminate wrong answers

Option A is wrong because a service tag for App Service in `ipRules` would still require the App Service to have a public IP; service tags are used in network security groups, not in the `ipRules` property of an Azure OpenAI account's network ACLs, and the App Service has no public IP. Option C is wrong because changing `defaultAction` to `Allow` would open the OpenAI account to all public internet traffic, which is a security risk and does not solve the specific requirement of allowing access from a private App Service without a public IP. Option D is wrong because the App Service has no public IP, so adding its outbound IP address to `ipRules` is impossible; even if it had a public IP, the outbound IPs of an App Service can change (e.g., in multi-tenant scenarios), making this approach unreliable.

Practice this question →

13

MCQhard

A company uses Azure API Management (APIM) to expose a set of REST APIs. A new requirement mandates that all API calls must be throttled per user based on usage tiers (Free, Basic, Premium). User identity is provided via a JWT token. Which policy should the developer configure in APIM to enforce this throttling?

A.rate-limit policy

B.rate-limit-by-key policy

C.quota-by-key policy

D.IP-based throttling

AnswerB

rate-limit-by-key can throttle based on a key extracted from JWT claims, enabling per-user throttling.

Why this answer

The rate-limit-by-key policy is correct because it allows throttling based on a specific key extracted from the request, such as the user identity from a JWT token. This policy enables per-user rate limiting by using a policy expression to extract the 'sub' claim or a custom claim from the JWT as the counter key, which maps directly to the usage tiers requirement.

Exam trap

Azure often tests the distinction between rate limiting (short-term, sliding window) and quota (long-term, fixed window), and the trap here is that candidates confuse 'quota-by-key' with 'rate-limit-by-key' because both use a key, but quota is for total usage over a month, not per-second throttling.

How to eliminate wrong answers

Option A is wrong because the rate-limit policy applies a single global rate limit to all requests, not per user or per key, and cannot differentiate based on JWT claims. Option C is wrong because the quota-by-key policy enforces a total number of calls over a longer period (e.g., daily, weekly, monthly), not a short-term rate limit per second/minute as required for throttling. Option D is wrong because IP-based throttling limits based on the caller's IP address, which does not reliably identify individual users behind shared IPs or NAT, and cannot leverage JWT-based user identity.

Practice this question →

14

Multi-Selecthard

Which THREE are best practices for implementing an API using Azure API Management? (Choose three.)

Select 3 answers

A.Use policies to enforce throttling and quotas.

B.Implement caching policies to reduce backend load.

C.Use subscription keys for client authentication and rate limiting.

D.Use the Consumption tier for production APIs with custom domains.

E.Expose the backend service URLs directly to clients.

AnswersA, B, C

Azure API Management policies are XML-based configurations that can be applied at various scopes (global, product, API, operation). Throttling policies (e.g., `rate-limit-by-key`) prevent abuse by limiting the number of calls within a specified period, while quota policies (e.g., `quota-by-key`) restrict the total number of calls or bandwidth over a longer duration. These are crucial for protecting backend services from overload and ensuring fair usage among consumers.

Why this answer

A is correct because Azure API Management policies allow you to enforce throttling and quotas at the API level, protecting your backend from excessive traffic. By defining rate limits and quota policies, you can control the number of requests a client can make within a specified time window, ensuring fair usage and preventing abuse.

Exam trap

The trap here is that candidates may assume the Consumption tier is suitable for production APIs with custom domains, but it lacks custom domain support and other enterprise features, making it only appropriate for low-volume or development scenarios.

Practice this question →

15

MCQmedium

You are building an application that subscribes to an Azure Event Grid topic using a custom webhook endpoint. The endpoint is a web API hosted on Azure App Service. You need to ensure that only Event Grid can invoke your webhook endpoint, preventing unauthorized requests. What should you implement in your webhook endpoint?

A.IP address filtering to allow only the Azure Event Grid service tag

B.Validate the Aeg-SasKey header against a shared secret known to Event Grid

C.Require a client certificate that you upload to Event Grid

D.Use an OAuth 2.0 token from Microsoft Entra ID

AnswerB

This is the recommended and most secure method for authenticating Event Grid webhook deliveries. Event Grid includes an Aeg-SasKey HTTP header in every event delivery request, containing a Shared Access Signature (SAS) key. Your webhook endpoint should validate this key against the access key configured for your Event Grid subscription. This cryptographic validation confirms that the request genuinely originated from your Event Grid topic or domain, ensuring the authenticity and integrity of the event delivery.

Why this answer

Event Grid sends an Aeg-SasKey header with each request to a custom webhook endpoint. By validating this header against a pre-configured shared secret (the same key used when creating the event subscription), the endpoint can confirm that the request originated from Event Grid. This prevents unauthorized actors from invoking the webhook, as they would not possess the shared secret.

Exam trap

The trap here is that candidates often assume IP whitelisting (Option A) is sufficient for security, but Event Grid's outbound IPs are not static or documented for custom webhooks, making this approach unreliable and unsupported.

How to eliminate wrong answers

Option A is wrong because IP address filtering using the Azure Event Grid service tag is not supported for custom webhook endpoints; Event Grid's outbound IP addresses can vary and are not published as a stable service tag for inbound validation. Option C is wrong because Event Grid does not support uploading client certificates for authentication to custom webhook endpoints; client certificate authentication is not a feature of Event Grid's webhook delivery. Option D is wrong because OAuth 2.0 tokens from Microsoft Entra ID are not natively supported by Event Grid for authenticating to custom webhook endpoints; Event Grid uses its own shared access signature (SAS) mechanism via the Aeg-SasKey header.

Practice this question →

16

MCQmedium

A web app running on Azure App Service must integrate with Microsoft Graph API to read user profiles. The app is registered in Microsoft Entra ID and uses the OAuth 2.0 authorization code flow. However, after deployment, the app fails to acquire tokens. What is the most likely cause?

A.The API permission for User.Read is not granted

B.The app is using the client credentials flow instead of authorization code flow

C.The redirect URI is not configured in the app registration

D.The client secret is expired

AnswerC

In the OAuth 2.0 authorization code flow, Azure AD redirects the user's browser back to a pre-registered redirect URI (also known as a reply URL) on the client application, carrying the authorization code. If this URI is not configured in the Azure AD app registration, or if it does not precisely match the URI used in the authorization request, Azure AD will refuse to issue the authorization code. This critical security measure prevents code interception and is a common cause for token acquisition failures during the initial authorization phase.

Why this answer

The OAuth 2.0 authorization code flow requires a redirect URI to be registered in the app registration in Microsoft Entra ID. This URI is where the authorization server sends the authorization code after user consent. If the redirect URI is missing or mismatched, the token acquisition fails because the authorization server cannot validate the callback endpoint, causing the authentication request to be rejected.

Exam trap

The trap here is that candidates often confuse token acquisition failures with permission or secret issues, overlooking the mandatory redirect URI registration requirement for the authorization code flow.

How to eliminate wrong answers

Option A is wrong because missing the User.Read API permission would cause the app to fail when calling Microsoft Graph after acquiring a token, but it would not prevent the token acquisition itself. Option B is wrong because the question explicitly states the app uses the authorization code flow, and using the client credentials flow would be a design choice, not a deployment failure cause. Option D is wrong because an expired client secret would cause token acquisition to fail with an 'invalid_client' error, but the question describes a scenario where the app fails after deployment, and a secret expiration is typically a runtime issue that would be caught during testing, not a misconfiguration that persists from deployment.

Practice this question →

17

MCQeasy

A company uses Azure Functions to process messages from Azure Service Bus. The function needs to scale out during high load. Which consumption plan should you choose to enable automatic scaling?

A.Logic Apps plan

B.Premium plan

C.Consumption plan

D.App Service plan

AnswerC

The Consumption plan is the correct choice as it offers a truly serverless, event-driven execution model perfectly suited for processing messages from Azure Service Bus. This plan automatically scales resources dynamically from zero instances up to many, based on the volume of incoming messages or other event triggers, and you are billed only for the compute resources consumed during execution. This automatic, granular scaling ensures optimal cost efficiency and responsiveness for intermittent or variable workloads.

Why this answer

The Consumption plan is the correct choice because it automatically scales out based on the number of incoming messages from Azure Service Bus, adding function instances up to a maximum of 200 instances per function app. This plan is event-driven and provides true serverless scaling with no reserved capacity, making it ideal for handling variable workloads like Service Bus message processing.

Exam trap

The trap here is that candidates often confuse the Premium plan's automatic scaling with the Consumption plan's scaling, but the question explicitly asks for the plan that 'enables automatic scaling' in the context of serverless, and the Consumption plan is the foundational serverless plan with automatic scale-out, while Premium adds features like VNet integration and pre-warmed instances.

How to eliminate wrong answers

Option A is wrong because Logic Apps plan is not a valid Azure Functions hosting plan; Logic Apps is a separate integration service, not a consumption plan for Functions. Option B is wrong because the Premium plan, while offering automatic scaling and enhanced performance, is not the Consumption plan; it provides pre-warmed instances and VNet connectivity but incurs higher cost and is not the default serverless scaling option. Option D is wrong because the App Service plan (Dedicated) requires manual scaling or autoscale rules and does not provide the automatic, event-driven scaling of the Consumption plan; it also incurs cost for reserved instances even when idle.

Practice this question →

18

Matchingmedium

Match each Azure DevOps component to its function.

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

Concepts

Matches

Git repositories for source control

CI/CD for building and deploying code

Agile project management with Kanban boards

Package management for Maven, npm, NuGet

Why these pairings

Correct matches: Azure Boards tracks work items, Azure Repos hosts source code, Azure Pipelines automates builds and deployments. Common confusions include mixing up Boards with Repos, or Repos with Pipelines.

Practice this question →

19

MCQmedium

You deploy the above policy to an Azure API Management API. What is the effect?

A.Limits the total bandwidth to 100 MB per 60 seconds.

B.Limits the API to 100 calls per 60 seconds from the backend.

C.Limits the API to 100 calls per 60 seconds per subscription key.

D.Limits the API to 100 calls per 60 seconds per client IP address.

AnswerC

This statement is correct. The `rate-limit` policy, when configured without a `by` attribute, defaults to applying the limit based on the subscription key provided in the client request. This means that each unique subscription key is independently allowed to make up to 100 calls within a 60-second period. This behavior ensures fair usage across different consumers of the API.

Why this answer

The policy shown is a rate-limit policy in Azure API Management that uses the `rate-limit-by-key` element with a `counter-key` attribute set to `@(context.Subscription.Key)`. This limits the number of calls per subscription key, not per IP or backend. The `calls` attribute is set to 100 and the `renewal-period` is 60 seconds, so it enforces 100 calls per 60 seconds per subscription key.

Exam trap

The trap here is that candidates confuse `rate-limit-by-key` (which resets every renewal period) with `quota-by-key` (which accumulates over a longer period), or they misidentify the counter-key as the client IP address instead of the subscription key.

How to eliminate wrong answers

Option A is wrong because the policy limits call count, not bandwidth (data transfer); bandwidth limits are enforced using `quota-by-key` with a `bandwidth` attribute, not `calls`. Option B is wrong because the counter-key is based on the subscription key, not the backend; backend-level limits would require a different policy or configuration. Option D is wrong because the counter-key is explicitly set to `@(context.Subscription.Key)`, not the client IP address; IP-based rate limiting would use `@(context.Request.IpAddress)` as the counter-key.

Practice this question →

20

Multi-Selecteasy

Which TWO Azure services can be used to store and manage secrets, such as API keys and connection strings? (Choose 2)

Select 1 answer

A.Azure Key Vault

B.Azure App Configuration

C.Azure Storage

D.Azure SQL Database

E.Azure Managed Identity

AnswersA

Azure Key Vault is designed for secure secret storage and management, making it the correct choice.

Why this answer

Azure Key Vault is the dedicated service for securely storing and managing secrets, keys, and certificates. Managed Identity, on the other hand, is an authentication mechanism that provides an identity for Azure resources to access secrets stored elsewhere, such as Key Vault. It does not store secrets itself.

Therefore, only Azure Key Vault qualifies as a service for storing and managing secrets among the given options.

Exam trap

The trap here is that candidates often confuse Azure App Configuration (which can store configuration values but not secrets securely) with Azure Key Vault, or they mistakenly think Managed Identity is a secret store when it is actually an authentication mechanism for accessing secrets.

Practice this question →

21

MCQhard

Your company uses Azure API Management to expose APIs to external partners. You need to implement rate limiting per subscription key to prevent abuse, but you also want to allow burst traffic up to a certain limit. Which policy should you configure?

A.Add a 'quota-per-key' policy with a renewal period of 1 day.

B.Add a 'limit' policy with a condition on subscription key.

C.Add a 'rate-limit-by-key' policy with a counter key of 'subscription-key'.

D.Add a 'rate-limit' policy with a renewal period of 60 seconds and a burst count of 10.

AnswerD

The 'rate-limit' policy supports both a steady-state rate limit and an optional burst count, making it suitable for this scenario.

Why this answer

The 'rate-limit' policy in Azure API Management allows you to set a rate limit (e.g., requests per 60 seconds) with a burst count, enabling short bursts of traffic beyond the steady-state limit. When applied at the product scope, it effectively enforces per-subscription throttling, meeting the requirement to prevent abuse while allowing burst traffic.

Exam trap

The trap here is that candidates often confuse 'rate-limit' (which supports burst) with 'rate-limit-by-key' (which does NOT support burst and is typically used for custom keys like IP addresses or user IDs), or 'quota-per-key' (which does not support burst and operates over longer periods). Another common mistake is assuming any rate-limit policy inherently allows bursts without explicitly configuring the 'burst-count' parameter.

How to eliminate wrong answers

Option A is wrong because 'quota-per-key' enforces a total number of calls over a longer period (e.g., per day), not a per-second or burst-aware rate limit, and does not allow burst traffic within short intervals. Option B is wrong because there is no generic 'limit' policy in Azure API Management; the correct policy names are 'rate-limit' and 'rate-limit-by-key', and a condition on subscription key is not a standalone policy. Option C is wrong because 'rate-limit-by-key' with a counter key of 'subscription-key' is the correct policy for per-key rate limiting, but the option omits the burst count configuration, which is essential for allowing burst traffic; without specifying a burst, the policy enforces a strict rate limit without burst allowance.

Practice this question →

22

MCQeasy

A web app needs to access Azure Key Vault secrets for database credentials. The app runs as a managed identity in Azure App Service. Which authentication method should be used to retrieve secrets without storing credentials in the app code?

A.Managed identity

B.Access key

C.Client certificate

D.Shared access signature (SAS) token

AnswerA

Managed identities for Azure resources provide an automatically managed identity in Azure Active Directory (Azure AD) for applications to use when connecting to resources that support Azure AD authentication. This eliminates the need for developers to manage credentials, as Azure handles the lifecycle of the identity. The web app can be granted specific permissions to Key Vault secrets directly via Azure AD role-based access control (RBAC), ensuring secure and credential-free access. This is the recommended and most secure approach for Azure-hosted applications.

Why this answer

Managed identity is the correct authentication method because it allows the Azure App Service web app to authenticate to Azure Key Vault without storing any credentials in code or configuration. Azure automatically manages the identity, and the app uses a token from the Azure Instance Metadata Service (IMDS) endpoint to access Key Vault secrets. This aligns with the principle of zero-trust and eliminates the security risk of hardcoded secrets.

Exam trap

The trap here is that candidates may confuse managed identity with other credential-based methods like access keys or client certificates, not realizing that managed identity is the only option that completely eliminates the need to store any credentials in the app code or configuration.

How to eliminate wrong answers

Option B is wrong because an access key is a static credential that must be stored in the app code or configuration, defeating the purpose of avoiding stored credentials. Option C is wrong because a client certificate requires the certificate to be stored in the app's code or file system, which introduces management overhead and potential exposure. Option D is wrong because a shared access signature (SAS) token is used for delegating access to Azure Storage resources, not for authenticating to Azure Key Vault, and it would still need to be stored in the app.

Practice this question →

23

MCQmedium

You have an order processing system using Azure Service Bus. Each order generates multiple messages that must be processed in order and by the same consumer. Which Service Bus feature ensures this?

A.Message sessions

B.Topics and subscriptions

C.Dead-letter queues

D.Auto-forwarding

AnswerA

Message sessions are the correct mechanism for guaranteeing ordered, first-in-first-out (FIFO) delivery of related messages and ensuring that all messages belonging to a specific session are processed by a single consumer. By assigning a unique SessionId to a group of messages, Azure Service Bus ensures that these messages are delivered sequentially and processed exclusively by one receiver, which is crucial for maintaining the logical order in an order processing system.

Why this answer

Message sessions in Azure Service Bus enable ordered, sequential processing of related messages by a single consumer. When messages belong to the same session, they are guaranteed to be delivered in order and are locked to a single consumer until the session is complete, ensuring that all messages for a given order are processed by the same consumer without interleaving.

Exam trap

The trap here is that candidates often confuse topics/subscriptions (which handle fan-out messaging) with the need for ordered, single-consumer processing, not realizing that only sessions provide the required ordering and consumer affinity.

How to eliminate wrong answers

Option B is wrong because topics and subscriptions implement a publish/subscribe pattern, which broadcasts messages to multiple subscribers and does not guarantee ordered delivery or single-consumer processing. Option C is wrong because dead-letter queues are used to hold messages that cannot be processed normally (e.g., due to exceeding max delivery count), not to enforce ordering or consumer affinity. Option D is wrong because auto-forwarding moves messages from one queue or subscription to another automatically, but it does not provide session-based ordering or ensure the same consumer processes all related messages.

Practice this question →

24

MCQeasy

Avanade is developing a .NET Core console application that runs on an Azure VM. The application needs to read a secret from Azure Key Vault. The VM has a system-assigned managed identity enabled. The managed identity has been granted 'Get' and 'List' permissions on the Key Vault secrets. The code uses the Azure.Identity and Azure.Security.KeyVault.Secrets NuGet packages. Which code snippet should the developer use to authenticate to Key Vault?

A.var client = new SecretClient(new Uri(keyVaultUrl), new EnvironmentCredential());

B.var client = new SecretClient(new Uri(keyVaultUrl), new DefaultAzureCredential());

C.var client = new SecretClient(new Uri(keyVaultUrl), new ManagedIdentityCredential());

D.var client = new SecretClient(new Uri(keyVaultUrl), new ClientSecretCredential(tenantId, clientId, clientSecret));

AnswerB

DefaultAzureCredential is the most robust and recommended choice for applications deployed to Azure. It intelligently attempts to authenticate using a chain of methods, including managed identity, Azure CLI, environment variables, and Visual Studio. When running on an Azure resource with a system-assigned managed identity enabled, it automatically detects and utilizes that identity, eliminating the need for explicit credential management in the application code. This adaptability makes it ideal for production environments.

Why this answer

DefaultAzureCredential attempts multiple authentication sources in order, including EnvironmentCredential, ManagedIdentityCredential, and others. Since the VM has a system-assigned managed identity enabled and the code runs in that environment, DefaultAzureCredential will automatically fall through to ManagedIdentityCredential and authenticate using the managed identity's token endpoint. This provides the most flexible and recommended approach for Azure SDK authentication.

Exam trap

The trap here is that candidates often pick ManagedIdentityCredential (Option C) thinking it is the most direct choice, but Azure recommends DefaultAzureCredential for production code because it provides automatic fallback and works across local development and Azure environments without code changes.

How to eliminate wrong answers

Option A is wrong because EnvironmentCredential only reads credentials from environment variables (AZURE_TENANT_ID, AZURE_CLIENT_ID, AZURE_CLIENT_SECRET) and does not attempt managed identity authentication, so it would fail on a VM without those variables set. Option C is wrong because while ManagedIdentityCredential would work in this specific scenario, it is less flexible than DefaultAzureCredential and would not fall back to other credential sources if the managed identity is unavailable or misconfigured; the question asks for the best practice snippet. Option D is wrong because ClientSecretCredential requires explicit tenant ID, client ID, and client secret, which are not available or appropriate when using a system-assigned managed identity.

Practice this question →

25

MCQeasy

You are developing a microservices application that needs to send messages between services asynchronously. Which Azure service should you use to decouple the components and ensure reliable message delivery?

A.Azure Cosmos DB

B.Azure Service Bus

C.Azure Queue Storage

D.Azure Event Hubs

AnswerB

Azure Service Bus is an enterprise-grade message broker offering advanced features like message sessions, topics for publish/subscribe patterns, transactions, and dead-lettering. While excellent for complex integration scenarios requiring guaranteed message delivery and sophisticated routing, it introduces more overhead and cost than necessary for simple asynchronous decoupling between microservices. For basic point-to-point message queuing, its extensive feature set is often overkill, making it a less optimal choice when simplicity is paramount.

Why this answer

Azure Service Bus is a fully managed enterprise message broker that provides advanced features crucial for robust microservices architectures, such as message sessions for guaranteed ordering (FIFO), dead-lettering for error handling, duplicate detection, and transactional processing. These features enhance reliability and manageability beyond the basic at-least-once delivery offered by Azure Queue Storage, making it a more comprehensive solution for decoupling components and ensuring reliable message delivery in complex microservices applications.

Exam trap

The trap is choosing Azure Queue Storage for its simplicity and cost when the requirements for 'microservices application' and 'reliable message delivery' often imply a need for the more advanced features and robust guarantees provided by Azure Service Bus, such as dead-lettering, message sessions, and transactional capabilities.

How to eliminate wrong answers

Option A is wrong because Azure Cosmos DB is a NoSQL database designed for storing and querying structured data, not for asynchronous message queuing; it lacks built-in message queuing features like FIFO ordering, visibility timeouts, and poison message handling. Option B is wrong because Azure Service Bus is a more advanced messaging broker with features like topics, subscriptions, and sessions, but it is overkill for simple point-to-point message queuing and introduces higher latency and cost compared to Queue Storage for basic decoupling needs. Option D is wrong because Azure Event Hubs is a big data streaming platform optimized for high-throughput event ingestion (e.g., telemetry, logs) and does not provide reliable message delivery with consumer-side deletion; it uses a pull-based model with checkpointing, not a queue-based model for decoupling services.

Practice this question →

26

MCQmedium

Coho Vineyard has an Azure Logic App that processes orders. The workflow must call a third-party API that uses Basic authentication. The credentials (username and password) must be stored securely in Azure Key Vault. The Logic App uses a system-assigned managed identity. The managed identity has been granted 'Get' permission on the Key Vault secrets. Which approach should the team use to pass the credentials to the third-party API?

A.Use an HTTP connector with 'Active Directory OAuth' authentication. Provide the client ID and client secret.

B.Use managed identity authentication on the HTTP connector. The third-party API must support managed identity.

C.Store the username and password directly in the Logic App's connection settings for the HTTP connector.

D.Add a Key Vault connector step to retrieve the secret containing the password. Then use an HTTP connector with 'Basic' authentication type. In the authentication parameters, reference the secret for the password.

AnswerD

This approach correctly addresses both security and functional requirements. Azure Key Vault provides a secure, centralized store for secrets, ensuring the password is encrypted at rest and access is controlled via Azure RBAC. By retrieving the password from Key Vault at runtime and then using it with the HTTP connector's 'Basic' authentication type, the Logic App securely authenticates to the third-party API without exposing credentials in its definition. This adheres to security best practices for credential management.

Why this answer

The correct approach is to add a Key Vault connector step to retrieve the secret containing the password, then use an HTTP connector with 'Basic' authentication type. In the authentication parameters, reference the secret for the password field. Option A is incorrect because Active Directory OAuth is not compatible with Basic authentication.

Option B is incorrect because the third-party API does not support managed identity authentication. Option C is insecure as it stores credentials directly in the Logic App configuration. Option D is correct.

Practice this question →

27

MCQhard

You have an Azure API Management instance that exposes a REST API. You need to secure the API using OAuth 2.0 with Microsoft Entra ID. The API should accept tokens from multiple client applications. Which policy should you add to the inbound processing section?

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

B.<xml-to-json>

C.<rate-limit>

D.<cache-lookup>

AnswerA

The <validate-jwt> policy is specifically designed to validate JSON Web Tokens (JWTs) presented in an HTTP header, typically the 'Authorization' header using the 'Bearer' scheme. It verifies the token's signature, expiration, audience, issuer, and other claims against configured validation parameters, ensuring the request originates from an authenticated and authorized source. If validation fails, it immediately terminates the request processing and returns the specified HTTP status code, such as 401 Unauthorized, preventing access to the backend API.

Why this answer

The <validate-jwt> policy is the correct choice because it validates the OAuth 2.0 token presented in the Authorization header, ensuring that only requests with valid tokens from Microsoft Entra ID are processed. This policy checks the token's signature, issuer, audience, and expiration, and returns a 401 status code if validation fails, which is essential for securing the API against unauthorized access from multiple client applications.

Exam trap

The trap here is that candidates often confuse authentication (validating who the user is) with authorization (what the user can do), and may incorrectly choose a policy like <rate-limit> or <cache-lookup> thinking they provide security, but only <validate-jwt> actually validates the OAuth 2.0 token's authenticity and integrity.

How to eliminate wrong answers

Option B is wrong because <xml-to-json> is a transformation policy that converts XML responses to JSON format, which has nothing to do with OAuth 2.0 token validation or API security. Option C is wrong because <rate-limit> is a throttling policy that limits the number of requests per time period, but it does not authenticate or authorize requests using OAuth 2.0 tokens. Option D is wrong because <cache-lookup> is a caching policy that retrieves responses from the cache to improve performance, and it does not perform any token validation or security checks.

Practice this question →

28

MCQmedium

Refer to the exhibit. You executed the Azure CLI command to create a storage account. Later, you attempt to connect from an application that uses TLS 1.1. The connection fails. What is the most likely reason?

A.The storage account uses Standard_GRS replication which is not accessible from all clients

B.The storage account is in a different location than the client

C.The storage account kind is StorageV2 which does not support blobs

D.The minimum TLS version is set to 1.2, blocking TLS 1.1

AnswerD

The Azure CLI command `az storage account update --minimum-tls-version TLS1_2` explicitly configures the storage account to reject any incoming connections that attempt to negotiate a TLS protocol version older than 1.2. If a client application or operating system is configured to use TLS 1.0 or TLS 1.1, the connection will fail during the initial TLS handshake phase, resulting in a connectivity error. This setting directly enforces a higher security standard, blocking older, less secure TLS versions.

Why this answer

The Azure CLI command used to create the storage account did not specify a minimum TLS version, so the default value of 1.2 applies. When the application attempts to connect using TLS 1.1, Azure Storage rejects the connection because the service enforces TLS 1.2 or higher. This is a security default in Azure Storage accounts created after a certain date, and it can be overridden by setting the `--min-tls-version` parameter to 1.0 during creation or by updating the account's properties.

Exam trap

The trap here is that candidates may overlook the default minimum TLS version setting in Azure Storage and assume that TLS 1.1 is always supported, or they may incorrectly attribute the failure to replication type, location, or storage account kind.

How to eliminate wrong answers

Option A is wrong because Standard_GRS replication provides geo-redundant storage and does not impose any TLS version restrictions; all replication types support the same TLS protocols. Option B is wrong because the location of the storage account relative to the client does not affect TLS version negotiation; TLS is a transport-layer protocol independent of geographic location. Option C is wrong because StorageV2 (general purpose v2) fully supports blobs, including block blobs, append blobs, and page blobs; the 'kind' parameter does not disable blob functionality.

Practice this question →

29

MCQmedium

You are building an Azure Logic App that processes orders. When an order is placed, the Logic App must send a message to an Azure Service Bus queue. The queue is secured using managed identity. Which connector action should you use?

A.HTTP action with SAS token

B.Service Bus connector with managed identity authentication

C.Azure Functions connector

D.Event Grid connector

AnswerB

This is the optimal and recommended approach. The Azure Service Bus connector natively supports managed identity authentication, allowing the Logic App to securely authenticate with Azure Service Bus using an identity managed by Azure Active Directory. This eliminates the need to store or manage connection strings, SAS tokens, or other credentials within the Logic App, significantly enhancing security and simplifying credential rotation and lifecycle management through Azure RBAC.

Why this answer

The Service Bus connector with managed identity authentication is correct because it allows the Logic App to authenticate to the Azure Service Bus queue using an Azure AD managed identity, eliminating the need for secrets or SAS tokens. This is the recommended approach for securing Service Bus resources when using Azure services, as it leverages Azure RBAC for fine-grained access control and aligns with the principle of least privilege.

Exam trap

The trap here is that candidates may confuse the HTTP action with SAS token as a valid way to use managed identity, but managed identity requires Azure AD authentication, not SAS, and the Service Bus connector explicitly supports this authentication type.

How to eliminate wrong answers

Option A is wrong because the HTTP action with SAS token requires you to generate and manage a Shared Access Signature token, which introduces secret management overhead and does not use managed identity; it is less secure and not the intended method for managed identity scenarios. Option C is wrong because the Azure Functions connector is used to trigger or invoke Azure Functions, not to directly send messages to a Service Bus queue; it would add unnecessary complexity and latency. Option D is wrong because the Event Grid connector is designed for publishing and subscribing to events via Azure Event Grid, not for sending messages to a Service Bus queue; it does not support Service Bus queue operations directly.

Practice this question →

30

Multi-Selectmedium

Which TWO Azure services can be used to implement a pub/sub messaging pattern?

Select 2 answers

A.Azure Service Bus Topics

B.Azure Blob Storage

C.Azure Event Hubs

D.Azure Queue Storage

E.Azure Event Grid

AnswersA, E

Azure Service Bus Topics enable a pub/sub pattern through topic subscriptions, where each subscriber receives its own copy of every message sent to the topic, satisfying the requirement for one-to-many asynchronous decoupling. This contrasts with queues, which implement point-to-point messaging, making Topics the correct choice for broadcast-style distribution.

Why this answer

Azure Service Bus Topics supports a publish/subscribe pattern through its topic and subscription model. Publishers send messages to a topic, and multiple subscriptions can independently receive copies of each message, enabling fan-out delivery to multiple consumers. This is the core pub/sub mechanism in Azure Service Bus.

Exam trap

The trap here is that candidates confuse Azure Event Hubs (a streaming ingestion service) with a pub/sub broker, but Event Hubs uses consumer groups for load-balanced consumption, not independent subscriptions, making it unsuitable for traditional pub/sub patterns.

Practice this question →

31

MCQhard

A company has an Azure Service Bus namespace with a topic that receives high-throughput messages. They need to ensure that if a subscriber fails, messages are not lost and can be replayed. The subscriber is a client application that uses the PeekLock receive mode. What should they configure?

A.Enable auto-forwarding on the subscription.

B.Set a SQL filter on the subscription.

C.Disable dead-lettering on the subscription.

D.Enable dead-lettering on the subscription.

AnswerD

Enabling dead-lettering on a subscription automatically moves messages that cannot be delivered or processed successfully into a special sub-queue called the Dead-Letter Queue (DLQ). Messages are typically dead-lettered if they exceed the MaxDeliveryCount, expire, or if there are issues with subscription filters. This provides a crucial fault-tolerance mechanism, allowing operators to inspect failed messages, diagnose the root cause of processing errors, and potentially re-submit them for processing after corrective action, preventing data loss and enabling message recovery.

Why this answer

Dead-lettering on a subscription allows messages that cannot be processed by a subscriber to be moved to a dead-letter queue (DLQ) instead of being lost. When a subscriber using PeekLock mode fails to process a message (e.g., exceeds MaxDeliveryCount or the lock expires), the message is automatically transferred to the DLQ. This ensures messages are preserved and can be replayed later by reprocessing the DLQ, meeting the requirement for no message loss and replay capability.

Exam trap

The trap here is that candidates may think disabling dead-lettering prevents message loss (by keeping messages in the subscription), but in reality, without dead-lettering, messages that cannot be delivered are simply discarded after exceeding the maximum delivery count, leading to permanent loss.

How to eliminate wrong answers

Option A is wrong because auto-forwarding automatically moves messages from one subscription to another queue or topic, which does not preserve failed messages for replay; it simply redirects them, potentially losing the original failure context. Option B is wrong because a SQL filter is used to select which messages are delivered to a subscription based on message properties, not to handle message failures or replay. Option C is wrong because disabling dead-lettering would cause messages that exceed the maximum delivery count or expire to be silently discarded, violating the requirement to not lose messages.

Practice this question →

32

MCQhard

Refer to the exhibit. You are deploying an API in Azure API Management using an ARM template. The API is configured to use OAuth 2.0 authentication. The deployment fails with a validation error. What is the most likely cause?

A.The serviceUrl is not a valid URL.

B.The dependsOn array uses resourceId incorrectly.

C.The protocols array does not include http.

D.The authorization server 'auth-server-1' is not defined in the template.

AnswerD

The dependsOn expects the authorization server resource to exist; if missing, validation fails.

Why this answer

When an API in Azure API Management is configured to use OAuth 2.0 authentication, the ARM template must include a corresponding authorization server resource (type 'Microsoft.ApiManagement/service/authorizationServers') that defines the OAuth 2.0 provider. The API's authenticationSettings reference this authorization server by name, and if that server is not defined in the template, the deployment fails with a validation error indicating a missing dependency or undefined resource.

Exam trap

A common pitfall is assuming that OAuth 2.0 configuration for an API in Azure API Management can be defined entirely within the API resource itself in an ARM template. In reality, a separate authorization server resource (type 'Microsoft.ApiManagement/service/authorizationServers') must be deployed and referenced by the API's authenticationSettings. If that resource is missing or not properly referenced, the deployment fails with a validation error.

How to eliminate wrong answers

Option A is wrong because the serviceUrl is validated for format but does not cause a validation error related to OAuth 2.0 authentication; an invalid URL would produce a different error (e.g., 'Invalid service URL'). Option B is wrong because the dependsOn array using resourceId incorrectly would cause a deployment ordering issue or a 'ResourceNotFound' error, not a validation error specifically about OAuth 2.0 configuration. Option C is wrong because the protocols array does not need to include http; Azure API Management supports https by default, and omitting http is not a validation error—it is a common security best practice.

Practice this question →

33

MCQmedium

You are building an Azure Logic App that needs to call an external HTTP API secured with OAuth 2.0 Client Credentials flow. The client ID and client secret are stored in Azure Key Vault. You need to obtain an access token and include it in the Authorization header of each request. Which combination of actions should you use within the Logic App?

A.Use an HTTP action with the OAuth 2.0 authentication type. Set the client secret parameter to a secure reference to the Key Vault secret.

B.Use two HTTP actions: first, call the token endpoint with credentials to get a token, then use the token in the second action. Store credentials in a string variable.

C.Use the HTTP action with managed identity authentication.

D.Use the 'Invoke an Microsoft Entra ID protected API' connector with the client credentials grant type.

AnswerA

Logic Apps' built-in OAuth 2.0 authentication for HTTP actions handles token acquisition and renewal. The secret can be securely referenced from Key Vault via a parameter.

Why this answer

The HTTP action in Azure Logic Apps natively supports the OAuth 2.0 authentication type, which can directly handle the Client Credentials flow. By setting the client secret parameter to a secure reference (e.g., `@Microsoft.KeyVault(SecretUri=...)`) pointing to the secret stored in Azure Key Vault, you avoid exposing credentials in the workflow definition. The Logic Apps runtime automatically retrieves the secret from Key Vault, obtains an access token from the token endpoint, and includes it in the Authorization header of each request without requiring custom token management.

Exam trap

The trap here is that candidates often overcomplicate the solution by manually implementing token acquisition (Option B) or misapplying managed identity (Option C) or prebuilt connectors (Option D), not realizing that the built-in HTTP action's OAuth 2.0 authentication type directly supports the Client Credentials flow with Key Vault integration.

How to eliminate wrong answers

Option B is wrong because storing credentials in a string variable within the Logic App is insecure and defeats the purpose of using Key Vault; it also requires manual token acquisition and renewal, which is error-prone and unnecessary when the built-in OAuth 2.0 authentication type handles it automatically. Option C is wrong because managed identity authentication is designed for Azure AD-protected resources that support managed identities (e.g., Azure Storage, Azure SQL), not for external HTTP APIs secured with OAuth 2.0 Client Credentials flow; it cannot be used to obtain a token for a third-party API that expects a client ID and client secret. Option D is wrong because the 'Invoke an Microsoft Entra ID protected API' connector is a prebuilt connector that works only with APIs registered in the same Azure AD tenant and does not support the Client Credentials grant type with custom client secrets from Key Vault; it is intended for delegated user authentication scenarios, not for service-to-service calls.

Practice this question →

34

MCQeasy

You are building an Azure Logic App that must call a third-party REST API. The API requires an API key passed as a query parameter. You need to store the API key securely and automatically add it to each request. Which approach should you use?

A.Hardcode the API key in the Logic App definition.

B.Use Azure Key Vault and the Key Vault connector to retrieve the secret dynamically.

C.Store the API key in an Azure Storage Table and reference it from the Logic App.

D.Use an environment variable in the Logic App.

AnswerB

Azure Key Vault is the industry-standard solution for securely storing and managing cryptographic keys, secrets, and certificates. By using the Key Vault connector in a Logic App, the API key is retrieved dynamically at runtime, typically leveraging a Managed Identity assigned to the Logic App for authentication to Key Vault. This approach ensures the secret is never exposed in the Logic App's definition, source control, or logs, facilitating secure rotation and auditing while adhering to robust security and compliance standards.

Why this answer

Azure Key Vault provides a secure, centralized service for storing secrets like API keys, and the Key Vault connector in Logic Apps allows you to dynamically retrieve the secret at runtime without exposing it in the workflow definition. This approach ensures the API key is never hardcoded or stored in plaintext, meeting security best practices for accessing third-party APIs.

Exam trap

The trap here is that candidates may think storing the key in an Azure Storage Table or using environment variables is sufficient, but Azure Key Vault is the only option that provides secure, auditable, and managed secret storage with built-in integration for Logic Apps.

How to eliminate wrong answers

Option A is wrong because hardcoding the API key in the Logic App definition exposes the secret in plaintext within the workflow JSON, making it visible to anyone with access to the definition and violating security best practices. Option C is wrong because storing the API key in an Azure Storage Table does not provide encryption at rest by default (unless client-side encryption is implemented), and the key would be stored as plaintext in a table, which is not a secure secret management solution. Option D is wrong because Logic Apps do not support environment variables; this concept is not applicable to Azure Logic Apps, and even if it were, environment variables are not a secure way to store secrets as they can be exposed in logs or configuration files.

Practice this question →

35

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?

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 publish-subscribe messaging scenarios, enabling a publisher to send messages to a topic that can then be delivered to multiple independent and competing subscriptions. Each subscription acts as a virtual queue, receiving its own copy of the messages published to the topic, and can be configured with filtering rules to selectively receive events. This architecture perfectly supports the requirement for multiple independent applications to consume order events without affecting each other.

Why this answer

Azure Service Bus topics support a publish/subscribe pattern where multiple independent subscribers can each receive a copy of the same message. This decouples the publisher from subscribers, allowing new subscribers to be added later without modifying the publisher. The topic's subscription mechanism ensures each subscriber processes the event independently.

Exam trap

The trap here is that candidates often confuse Azure Storage Queue (point-to-point) with Service Bus topics (pub/sub), mistakenly thinking a queue can serve multiple independent subscribers when it actually requires a single consumer or competing consumers pattern.

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 provides a point-to-point messaging model where a single consumer processes each message, not a broadcast to multiple independent subscribers. Option C is wrong because Azure Cache for Redis list only supports a simple list data structure for point-to-point message queuing (e.g., via LPUSH/BRPOP), lacking the publish/subscribe semantics needed for multiple independent subscribers.

Practice this question →

36

MCQeasy

You are using Azure Blob Storage to store large media files. Clients upload files directly to the storage account using SAS tokens. You need to ensure that the SAS token expires 1 hour after creation. Which parameter should you set when generating the SAS token?

A.SignedProtocol (spr)

B.IP range (sip)

C.SignedExpiry (se)

D.SignedStart (st)

AnswerC

The SignedExpiry (se) parameter is the fundamental and correct mechanism for defining the lifespan of an Azure Storage Shared Access Signature (SAS) token. It specifies the exact Coordinated Universal Time (UTC) date and time at which the SAS token will cease to be valid. Once this time is reached, any subsequent attempts to use the token for accessing storage resources will be met with an authorization failure, thereby enforcing time-limited access and adhering to security best practices.

Why this answer

The SignedExpiry (se) parameter explicitly defines the expiration time of a SAS token. When generating a SAS token for Azure Blob Storage, setting 'se' to a UTC time 1 hour from creation ensures the token is valid only for that duration, meeting the requirement that clients can upload files directly using the SAS token for exactly 1 hour.

Exam trap

The trap here is that candidates confuse SignedStart (st) with SignedExpiry (se), mistakenly thinking setting a start time alone controls the token's lifetime, when in fact without an expiry, the token remains valid indefinitely.

How to eliminate wrong answers

Option A is wrong because SignedProtocol (spr) restricts the protocol (HTTPS or HTTP) used for requests, not the token's validity period. Option B is wrong because IP range (sip) limits the source IP addresses that can use the SAS token, not its expiration. Option D is wrong because SignedStart (st) defines when the SAS token becomes valid, not when it expires; setting only 'st' without 'se' would make the token valid indefinitely from that start time.

Practice this question →

37

Multi-Selecteasy

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

Select 2 answers

A.Azure Queue Storage

B.Azure Event Grid

C.Azure Notification Hubs

D.Azure Service Bus Topics

E.Azure Event Hubs

AnswersB, D

Event Grid supports pub-sub with event subscriptions.

Why this answer

Azure Service Bus Topics (Option D) natively implement a publish-subscribe pattern by allowing multiple subscriptions to receive copies of messages sent to a topic. Azure Event Grid (Option B) is a fully managed event routing service that uses a publish-subscribe model, where publishers send events and subscribers handle them via webhooks or Azure services. Both support decoupled communication with multiple receivers.

Exam trap

The trap here is confusing Azure Event Hubs (a telemetry ingestion service) with a publish-subscribe broker, since both support multiple consumers, but Event Hubs uses consumer groups for partitioned stream processing, not topic subscriptions with independent message copies.

Practice this question →

38

Multi-Selecteasy

Which TWO Azure services can be used to trigger an Azure Function in response to a new blob being added to an Azure Storage account? (Choose two.)

Select 2 answers

A.HTTP trigger

B.Queue trigger

C.Timer trigger

D.Azure Blob Storage trigger

E.Azure Event Grid subscription

AnswersD, E

The Azure Blob Storage trigger is a native binding in Azure Functions that automatically executes a function whenever a new or updated blob is detected in a specified container within an Azure Storage account. This built-in integration directly monitors the storage account for changes, providing a straightforward and efficient way to process blob events without requiring intermediary services. The function receives the blob content or metadata as input, enabling immediate processing upon creation or modification.

Why this answer

The Azure Blob Storage trigger is specifically designed to execute a function whenever a new or updated blob is detected in a storage container. It uses a polling mechanism to monitor the container and invokes the function with the blob's content and metadata as input. Option E is correct because an Azure Event Grid subscription can be configured to listen for the 'Microsoft.Storage.BlobCreated' event and route it to an Azure Function as an event-driven trigger, providing near-real-time, push-based notification without polling.

Exam trap

The trap here is that candidates often confuse the Blob Storage trigger (which directly monitors blob containers) with Event Grid subscriptions (which require explicit configuration), or mistakenly think an HTTP trigger can be used by having a client poll for new blobs, but the question specifically asks for services that trigger the function in response to a new blob being added.

Practice this question →

39

MCQeasy

Your web app needs to authenticate users with Microsoft Entra ID (formerly Azure AD). Which OAuth 2.0 flow should you use for a single-page application (SPA) that uses MSAL.js?

A.Client credentials flow

B.Authorization code flow with PKCE

C.Implicit flow

D.Resource owner password credentials flow

AnswerB

The Authorization Code flow with PKCE (Proof Key for Code Exchange) is the recommended and most secure method for authenticating users in public clients like single-page applications (SPAs) and mobile apps. This flow prevents code interception attacks by requiring the client to generate a secret `code_verifier` and a `code_challenge` that are exchanged during the authorization and token request steps, respectively. This ensures that only the legitimate client that initiated the authorization request can successfully exchange the authorization code for access and refresh tokens, providing robust security without exposing client secrets.

Why this answer

The authorization code flow with PKCE (Proof Key for Code Exchange) is the recommended OAuth 2.0 flow for single-page applications (SPAs) using MSAL.js because it provides a secure way to obtain tokens without exposing the client secret. PKCE ensures that even if the authorization code is intercepted, it cannot be exchanged for tokens without the original code verifier, mitigating authorization code injection attacks. Microsoft deprecated the implicit flow for SPAs in favor of this flow due to its enhanced security.

Exam trap

The trap here is that candidates often confuse the deprecated implicit flow (Option C) as the correct answer for SPAs, but Microsoft now mandates the authorization code flow with PKCE for all new SPA applications using MSAL.js.

How to eliminate wrong answers

Option A is wrong because the client credentials flow is designed for server-to-server (daemon) applications that need to authenticate without a user context, not for SPAs that require user authentication. Option C is wrong because the implicit flow was the original OAuth 2.0 flow for SPAs but is now deprecated by Microsoft due to security vulnerabilities, such as access token leakage in the browser history and lack of PKCE support. Option D is wrong because the resource owner password credentials flow requires the user to provide their username and password directly to the application, which is highly insecure and violates the principles of delegated authentication; it is only recommended for legacy or highly trusted scenarios.

Practice this question →

40

MCQeasy

You are developing an application that needs to store and retrieve large binary objects (up to 5 TB) in Azure Blob Storage. The application requires the ability to access data from any URL via HTTP/HTTPS. Which Blob Storage access tier should you use?

A.Hot

B.Archive

C.Cool

D.Premium

AnswerA

The Hot storage tier is specifically designed for frequently accessed data that requires instant retrieval capabilities via HTTP/HTTPS. It offers the lowest access costs and highest availability among the standard tiers, making it ideal for active datasets and applications where immediate data access is critical for user experience or operational efficiency. While its storage cost per GB is higher than Cool or Archive, its low transaction costs make it the most cost-effective choice for high-access patterns.

Why this answer

The Hot access tier is optimized for frequent read and write access to data, supports objects up to 5 TB, and allows access via HTTP/HTTPS from any URL. It is the only tier that combines low-latency access, high throughput, and public internet accessibility without requiring rehydration or special permissions, making it suitable for general-purpose blob storage scenarios.

Exam trap

The trap here is that candidates may confuse the Archive tier's low storage cost with suitability for large objects, forgetting that Archive requires manual rehydration (which can take hours) before data can be accessed via HTTP/HTTPS, making it incompatible with the requirement for immediate URL-based access.

How to eliminate wrong answers

Option B (Archive) is wrong because it is designed for long-term cold storage with retrieval times of up to 15 hours, and data must be rehydrated to a Hot or Cool tier before it can be accessed via HTTP/HTTPS, making it unsuitable for immediate URL-based access. Option C (Cool) is wrong because while it supports HTTP/HTTPS access, it is optimized for infrequently accessed data with higher access costs and lower availability guarantees compared to Hot, and it does not meet the requirement for frequent or large-scale binary object access. Option D (Premium) is wrong because it is a block blob storage tier optimized for low-latency and high transaction rates using SSD-backed hardware, but it is not designed for general-purpose large binary objects up to 5 TB and incurs significantly higher costs without providing any benefit for standard HTTP/HTTPS access patterns.

Practice this question →

41

MCQhard

Your Azure Function app needs to call a third-party REST API that requires OAuth 2.0 client credentials flow. The API expects a JWT token signed with a client certificate. You want to store the certificate securely and rotate it automatically. Which Azure service and feature should you use?

A.Store the certificate in Azure Cosmos DB as a document, and retrieve it using the Cosmos DB SDK.

B.Store the certificate in Azure Key Vault with automatic rotation enabled, and use Managed Identity to access it from the Function app.

C.Store the certificate in Azure App Service as a TLS/SSL binding, and use the WEBSITE_LOAD_CERTIFICATES app setting.

D.Store the certificate in Azure Storage as a blob, and reference it from the Function app using a SAS token.

AnswerB

Azure Key Vault is specifically designed as a secure, centralized store for cryptographic keys, secrets, and certificates, offering robust access control, versioning, and auditing. Enabling automatic rotation within Key Vault ensures certificates are refreshed before expiration, minimizing operational overhead and security risks associated with manual management. Using Managed Identity allows the Azure Function App to authenticate directly with Key Vault without needing to manage any connection strings or secrets, adhering to the principle of least privilege and significantly enhancing overall security. This combination represents the recommended best practice for secure certificate handling and access in Azure.

Why this answer

Azure Key Vault provides secure storage for client certificates with built-in automatic rotation capabilities, and using Managed Identity allows the Azure Function app to authenticate to Key Vault without storing any secrets in code or configuration. This combination satisfies the OAuth 2.0 client credentials flow requirement by enabling the Function app to retrieve the certificate dynamically and sign the JWT token.

Exam trap

The trap here is that candidates often confuse inbound TLS/SSL certificate binding (Option C) with outbound client certificate usage, mistakenly thinking the WEBSITE_LOAD_CERTIFICATES setting provides programmatic access to certificates for signing outbound requests.

How to eliminate wrong answers

Option A is wrong because Azure Cosmos DB is a NoSQL database designed for transactional and analytical workloads, not for secure secret storage; it lacks automatic rotation and access control features like Managed Identity integration. Option C is wrong because Azure App Service TLS/SSL bindings are intended for securing inbound HTTPS traffic to the app, not for storing client certificates used to authenticate outbound calls to third-party APIs; the WEBSITE_LOAD_CERTIFICATES setting loads certificates for inbound TLS termination, not for programmatic signing. Option D is wrong because Azure Storage blobs do not support automatic certificate rotation and using a SAS token to access the blob introduces a long-lived secret that must be managed separately, defeating the purpose of secure, automated rotation.

Practice this question →

42

MCQmedium

You are developing a microservice that needs to publish events to multiple subscribers. Each subscriber should receive the event independently and at its own pace. The event must be retained for up to 7 days. Which Azure messaging service should you use?

A.Azure Service Bus queue

B.Azure Service Bus topic

C.Azure Event Grid

D.Azure Event Hubs

AnswerB

Azure Service Bus topic subscriptions provide each subscriber with an independent copy of the message, yet messages are removed from the subscription as soon as they are consumed. This means the event is not retained for the full seven-day window if all subscribers have processed it early. Event Hubs retains events in a partitioned log for the entire retention period regardless of consumption, supporting replay. Service Bus topics are tempting because they offer reliable pub/sub messaging and would be correct when you need transactional guarantees or message sessions, not long-term event storage.

Why this answer

Azure Service Bus Topic is the correct choice. It provides a publish-subscribe model where each subscriber receives events independently through its own durable subscription. Messages are retained within each subscription until they are processed or their time-to-live expires (up to 14 days by default), which perfectly meets the requirement for events to be retained for up to 7 days for subscribers to consume at their own pace.

Event Grid is designed for near real-time event delivery and does not offer durable message retention for subscribers over several days; its retry policy is limited to a maximum of 24 hours.

Exam trap

Candidates often confuse Event Grid's pub/sub capabilities with the durable messaging requirements of Service Bus Topics. While Event Grid supports multiple subscribers, it is optimized for near real-time event routing and does not provide durable message retention for subscribers to pick up events at their own pace over several days. Its retry mechanism is limited (max 24 hours), and dead-lettering is for failed deliveries, not for holding events for slow subscribers.

Service Bus Topics, conversely, offer durable subscriptions where messages are retained for each subscriber until processed, fulfilling the long-term retention requirement.

How to eliminate wrong answers

Option A is wrong because Azure Service Bus queues implement a point-to-point messaging pattern where each message is consumed by a single receiver, not multiple subscribers. Option B is wrong because Azure Service Bus topics do support multiple subscribers, but they are designed for message-oriented middleware with a maximum retention period of 14 days, not specifically optimized for event-driven architectures with independent subscriber pacing. Option D is wrong because Azure Event Hubs is a big data streaming platform optimized for high-throughput ingestion and replay, not for routing events to multiple subscribers with independent consumption and 7-day retention; it retains events for up to 7 days but focuses on event streaming rather than pub-sub event distribution.

Practice this question →

43

MCQmedium

You are developing a mobile app that uses Azure Cognitive Services to analyze images. The app must authenticate to the Computer Vision API using a key that is rotated monthly. What is the best practice for handling the key?

A.Store the key in Azure App Configuration with Key Vault references and retrieve it at runtime

B.Use a system-assigned managed identity and acquire a token for Cognitive Services

C.Prompt the user to enter the key on first launch

D.Store the key in the mobile app's local secure storage after initial retrieval

AnswerA

Storing the key in Azure App Configuration with Key Vault references and retrieving it at runtime provides a robust and secure solution. A backend service, not the mobile app directly, would fetch the secret from App Configuration, which in turn securely retrieves it from Key Vault. This architecture enables dynamic key rotation in Key Vault without requiring any redeployment of the backend service or updates to the mobile application, significantly enhancing security posture and operational agility by centralizing secret management.

Why this answer

Azure App Configuration with Key Vault references provides a secure, centralized way to store and rotate secrets like API keys without embedding them in code or requiring redeployment. A secure backend service (e.g., an Azure Function or App Service) that the mobile app interacts with would retrieve the key at runtime via a managed identity, ensuring the key is never stored locally on the mobile device and can be rotated monthly by updating Key Vault, with App Configuration automatically fetching the latest version. The mobile app would then call this backend service, which in turn authenticates to Cognitive Services.

Exam trap

The trap here is that candidates often assume managed identity works directly for client-side applications like mobile apps, or that Cognitive Services APIs can be directly authenticated with a managed identity without first acquiring a key or an Azure AD token. While a backend service can use a managed identity to acquire a token or retrieve a key, a mobile app itself does not use a system-assigned managed identity.

How to eliminate wrong answers

Option B is wrong because Azure Cognitive Services (including Computer Vision) do not support managed identity authentication for key-based access; they require either a key or a token from Azure AD, but the key rotation requirement here mandates a key, not a token. Option C is wrong because prompting the user to enter the key on first launch violates security best practices (exposes the key to the user) and is impractical for monthly rotation, as it would require user intervention every month. Option D is wrong because storing the key in the mobile app's local secure storage after initial retrieval still leaves the key vulnerable to extraction from the device and does not address the monthly rotation requirement—the app would need to re-fetch the new key each month, which is better handled via a centralized service like App Configuration.

Practice this question →

44

MCQhard

You are building a solution that processes events from multiple Azure Event Hubs. Events must be dispatched to different downstream services based on the event type. You need a serverless solution that can handle high throughput and uses managed identity to authenticate to Event Hubs. Which Azure service should you use?

A.Azure Functions (Event Hubs trigger) with managed identity

B.Azure Stream Analytics

C.Azure Logic Apps (Event Hubs connector)

D.Azure Data Factory

AnswerA

Azure Functions with an Event Hubs trigger is an excellent choice for processing events from multiple Event Hubs at scale. It automatically handles consumer group management and checkpointing, allowing for highly concurrent and reliable event processing. Utilizing a managed identity provides a secure, credential-free way for the Function App to authenticate with Event Hubs and other Azure services, adhering to the principle of least privilege and enhancing security posture.

Why this answer

Azure Functions with an Event Hubs trigger supports managed identity authentication, enabling secure, passwordless connections to Event Hubs. It is a serverless, event-driven compute service that can scale to handle high throughput by processing events in parallel across multiple partitions. This makes it the ideal choice for dispatching events to downstream services based on event type.

Exam trap

The trap here is that candidates often confuse Azure Stream Analytics as a general-purpose event dispatcher, but it is specifically a stream analytics engine, not a serverless event router; Azure Functions is the correct choice for event-driven dispatching with managed identity support.

How to eliminate wrong answers

Option B (Azure Stream Analytics) is wrong because it is designed for real-time analytics and complex stream processing (e.g., SQL-like queries over time windows), not for dispatching individual events to multiple downstream services based on event type. Option C (Azure Logic Apps) is wrong because while it can connect to Event Hubs, it is a low-throughput, workflow-orchestration service that does not natively support managed identity for Event Hubs authentication and is not optimized for high-throughput event processing. Option D (Azure Data Factory) is wrong because it is a data integration and ETL service for scheduled, batch-oriented data movement, not a real-time event processing or dispatching service.

Practice this question →

45

Drag & Dropmedium

Arrange the steps to implement Azure Blob Storage lifecycle management to archive blobs after 30 days in the correct order.

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

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

First create storage and container, upload blobs, navigate to lifecycle, add rule with actions.

Practice this question →

46

MCQmedium

You are developing a serverless application using Azure Functions that processes orders. Each order must be validated by calling a third-party API. If the third-party API is unavailable, the function should retry with exponential backoff. How should you implement this?

A.Implement retry logic with exponential backoff and circuit breaker using Polly within the function

B.Enable automatic retries on the function's trigger binding

C.Configure the function to have a long timeout and hope the API responds

D.Use Azure Durable Functions to orchestrate the retry

AnswerA

Polly provides robust transient fault handling.

Why this answer

It uses the Polly library to implement retry logic with exponential backoff and circuit breaker, which is a lightweight and flexible approach. Option B is incorrect because the trigger binding's automatic retries are for infrastructure failures (e.g., message delivery), not for application-level errors like API unavailability. Option C is incorrect because a long timeout does not handle transient faults; it just waits.

Option D is incorrect because, while Azure Durable Functions does support retry via CallActivityWithRetryAsync, it introduces unnecessary complexity (orchestration overhead) for a simple HTTP call that can be handled directly with a library like Polly.

Practice this question →

47

MCQmedium

You are designing a solution that uses Azure Event Grid to handle events from multiple Azure services. The events must be filtered and routed to different endpoints based on event type. Which component should you use to filter events before they are sent to subscribers?

A.Event grid domain

B.Event grid topic

C.Event subscription with filters

D.Event handler

AnswerC

An Event Grid event subscription is the precise mechanism for selecting and routing specific events to an event handler. Subscribers define criteria using basic filters (e.g., event type, subject begins/ends with) or advanced filters (e.g., properties within the event payload) directly within their subscription configuration. This ensures that only relevant events, matching the specified conditions, are delivered to the designated endpoint, optimizing processing and reducing unnecessary traffic.

Why this answer

C is correct because Event Subscriptions in Azure Event Grid allow you to define filters on event types, subject prefixes/suffixes, and advanced filtering (e.g., based on data fields) to control which events are delivered to each subscriber. This filtering happens before the events are sent to the endpoint, ensuring only matching events are routed.

Exam trap

The trap here is that candidates often confuse the role of a topic (which is just a channel for events) with the filtering capability that is actually implemented at the subscription level, leading them to incorrectly select Event Grid Topic.

How to eliminate wrong answers

Option A is wrong because an Event Grid domain is a management construct for grouping multiple topics and enabling topic-level authentication, not a component for filtering events before delivery. Option B is wrong because an Event Grid topic is an endpoint where publishers send events, but filtering is configured at the subscription level, not the topic itself. Option D is wrong because an Event Handler is the destination (e.g., Azure Function, Webhook) that receives events; it does not perform pre-delivery filtering.

Practice this question →

48

MCQeasy

Your company is building a microservices application on Azure Kubernetes Service (AKS). The application must securely access Azure Key Vault to retrieve secrets. Which identity type should you use for the pods?

A.Service principal with certificate stored in the pod

B.User-assigned managed identity on the node resource group

C.System-assigned managed identity on AKS cluster

D.Microsoft Entra Workload ID (formerly Azure AD Pod Identity)

AnswerD

Microsoft Entra Workload ID (formerly Azure AD Pod Identity) is the recommended and most secure approach for enabling applications running in AKS pods to authenticate to Azure services. It allows a Kubernetes service account to be federated with a managed identity in Microsoft Entra ID, enabling pods to securely obtain Azure AD tokens without managing any secrets. This provides fine-grained, pod-level identity for accessing Azure resources, adhering to the principle of least privilege.

Why this answer

Microsoft Entra Workload ID (formerly Azure AD Pod Identity) is the recommended identity type for pods in AKS because it directly maps an Azure managed identity to a pod, allowing the pod to authenticate to Azure Key Vault without storing any credentials. It integrates with the Kubernetes native service account token projection and uses federated identity credentials, eliminating the need for manual secret management or node-level configuration.

Exam trap

The trap here is that candidates often confuse the cluster-level managed identity (system-assigned or user-assigned) with pod-level identity, assuming that a managed identity on the AKS cluster or its nodes can be directly used by pods, when in fact Microsoft Entra Workload ID is the correct mechanism for pod-level identity.

How to eliminate wrong answers

Option A is wrong because storing a service principal certificate inside the pod violates the principle of secretless authentication and creates a security risk if the pod is compromised. Option B is wrong because a user-assigned managed identity on the node resource group applies to the underlying VM nodes, not to individual pods, and would require additional configuration to be used by pods. Option C is wrong because a system-assigned managed identity on the AKS cluster is assigned to the cluster's control plane, not to individual pods, and cannot be directly used by a pod to authenticate to Key Vault.

Practice this question →

49

MCQeasy

You need to process large volumes of streaming data from IoT devices in near real-time. The processed data must be stored in Azure Cosmos DB for further analysis. Which Azure service should you use for stream processing?

A.Azure Batch

B.Azure Databricks

C.Azure Data Lake Storage

D.Azure Stream Analytics

AnswerD

Azure Stream Analytics is a fully managed, real-time analytics service designed specifically for processing large volumes of streaming data with low latency. It enables users to perform complex event processing, aggregations, and transformations on data from sources like IoT Hub using a SQL-like query language. Its native integration with Azure IoT Hub for input and Azure Cosmos DB for output makes it the ideal, purpose-built solution for real-time IoT data pipelines.

Why this answer

Azure Stream Analytics is purpose-built for real-time stream processing, capable of ingesting large volumes of data from sources like Azure Event Hubs or IoT Hub, applying SQL-based queries, and outputting results directly to Azure Cosmos DB. This aligns perfectly with the requirement for near real-time processing and storage in Cosmos DB.

Exam trap

The trap here is that candidates may confuse Azure Databricks as the only option for streaming analytics due to its Spark Structured Streaming capability, overlooking that Azure Stream Analytics is the simpler, fully managed service specifically designed for near real-time processing without the need for cluster management.

How to eliminate wrong answers

Option A is wrong because Azure Batch is designed for batch processing of large-scale parallel compute jobs, not for continuous, low-latency stream processing. Option B is wrong because Azure Databricks is an Apache Spark-based analytics platform that can handle streaming via Structured Streaming, but it introduces additional complexity and overhead compared to a dedicated, fully managed stream processing service like Stream Analytics. Option C is wrong because Azure Data Lake Storage is a scalable data lake for storing raw and processed data, not a stream processing engine; it lacks the ability to perform real-time transformations or queries on streaming data.

Practice this question →

50

MCQeasy

A company develops a web app that processes images uploaded by users. The app uses Azure Cognitive Services to analyze images for moderation. The solution must minimize latency when calling the Cognitive Services endpoint. Which service should the developer use to call the endpoint?

A.Azure Traffic Manager

B.Azure Front Door

C.Azure API Management

D.Azure Blob Storage with a public endpoint

AnswerB

Azure Front Door is a global, scalable entry-point that uses Microsoft's global edge network to provide fast, secure, and highly available web applications. It acts as a reverse proxy, leveraging Anycast IP and TCP split to terminate client connections at the closest edge location, then routing requests over Microsoft's optimized backbone network to the backend. This significantly reduces latency for users and accelerates calls to backend services like Azure Cognitive Services by optimizing the network path and providing caching capabilities, making it ideal for improving global application performance.

Why this answer

Azure Front Door is a global, scalable entry point that uses the Microsoft global edge network to route user traffic to the nearest regional Cognitive Services endpoint. It provides anycast-based acceleration and TLS termination at the edge, which minimizes latency by reducing the number of network hops and enabling connection reuse. This makes it the optimal choice for low-latency calls to Cognitive Services from a web app.

Exam trap

The trap here is that candidates confuse Azure Traffic Manager's DNS-level load balancing with Front Door's application-layer acceleration, assuming both provide similar latency benefits, but only Front Door offers anycast-based edge routing and TLS termination to minimize network hops.

How to eliminate wrong answers

Option A is wrong because Azure Traffic Manager operates at the DNS level and does not provide anycast routing or edge caching; it only distributes traffic based on DNS resolution, which adds DNS lookup latency and does not accelerate the actual HTTP request path. Option C is wrong because Azure API Management is a full API gateway focused on policy enforcement, rate limiting, and transformation, not on global low-latency acceleration; it introduces additional processing overhead and is not designed for edge-based latency minimization. Option D is wrong because Azure Blob Storage with a public endpoint is a storage service for binary data, not a routing or acceleration service; it cannot reduce latency for Cognitive Services API calls and would require the app to manage direct connectivity without any global optimization.

Practice this question →

51

MCQhard

Refer to the exhibit. You run the above Azure CLI command to upload a blob to Azure Blob Storage. The command fails with the error 'This request is not authorized to perform this operation.' You have verified that the storage account name and container name are correct, and the file exists. What should you do to resolve the error?

A.Provide the storage account key using the --account-key parameter or set the AZURE_STORAGE_KEY environment variable.

B.Generate a shared access signature (SAS) and use it instead of key.

C.Change --auth-mode key to --auth-mode login.

D.Upgrade to the latest version of Azure CLI.

AnswerA

When `--auth-mode key` is specified, the Azure CLI command requires the storage account's access key to authenticate operations. The error indicates this essential credential is not being supplied. Providing the key directly via the `--account-key` parameter or by setting the `AZURE_STORAGE_KEY` environment variable allows the command to successfully authenticate and execute the intended operation using the chosen key-based method.

Why this answer

The error 'This request is not authorized to perform this operation' indicates that the Azure CLI command did not provide valid credentials for the storage account. By default, Azure CLI uses Azure AD authentication (--auth-mode login), but when the command is run without a logged-in user context or without proper RBAC roles, it fails. Providing the storage account key via --account-key or setting the AZURE_STORAGE_KEY environment variable supplies the shared key for HMAC-SHA256 authorization, which is a fallback authentication method that does not require Azure AD.

Exam trap

The trap here is that candidates assume the error is about network or permissions on the container, but the real issue is that the CLI command lacks any form of authentication credential (key or token), and they may incorrectly think changing to --auth-mode login will fix it without ensuring Azure AD authentication is properly set up.

How to eliminate wrong answers

Option B is wrong because generating a SAS token and using it instead of the key would still require proper authentication; the error is about missing credentials, not the type of credential, and SAS tokens are typically used for delegated access, not for fixing a missing-key issue. Option C is wrong because changing --auth-mode key to --auth-mode login would switch from shared key to Azure AD authentication, which would fail if the user is not logged in or lacks RBAC permissions (e.g., Storage Blob Data Contributor). Option D is wrong because upgrading Azure CLI does not resolve authentication failures; the error is a permissions/credentials issue, not a version incompatibility.

Practice this question →

52

MCQhard

You manage an API in Azure API Management. You need to cache API responses such that different responses are returned based on the product subscription key used by the caller. Which set of policies should you implement?

A.Set a 'cache-lookup' policy in the inbound section and a 'cache-store' policy in the outbound section, using the subscription key as a cache vary-by parameter.

B.Set a 'cache-store' policy in the inbound section and a 'cache-lookup' policy in the outbound section.

C.Set both 'cache-lookup' and 'cache-store' policies in the inbound section.

D.Set only a 'cache-store' policy in the backend section.

AnswerA

This configuration correctly implements response caching in Azure API Management. The 'cache-lookup' policy in the inbound section efficiently checks for a cached response before forwarding the request to the backend, optimizing performance. If no cached entry is found, the request proceeds, and upon receiving a successful response from the backend, the 'cache-store' policy in the outbound section saves this response for future requests. Using the subscription key as a 'vary-by' parameter ensures that different API consumers receive their specific cached data, maintaining data isolation and correctness.

Why this answer

Caching API responses based on the subscription key ensures that each caller receives a cached response unique to their subscription. The 'cache-lookup' policy in the inbound section checks the cache before forwarding the request, and the 'cache-store' policy in the outbound section stores the response after it is generated. By specifying the subscription key as a vary-by parameter, the cache key includes the subscription key, so different keys produce different cached entries.

Exam trap

The trap here is that candidates often assume caching policies must both be in the inbound section, not realizing that 'cache-lookup' must run before the backend call and 'cache-store' must run after the response is generated, requiring them in inbound and outbound respectively.

How to eliminate wrong answers

Option B is wrong because it reverses the policy placement: 'cache-store' in the inbound section would attempt to store a response before it is generated, and 'cache-lookup' in the outbound section would check the cache after the response is already produced, defeating the purpose of caching. Option C is wrong because placing both policies in the inbound section would attempt to store a response before it is created, and the 'cache-lookup' would not have a response to cache from the outbound flow. Option D is wrong because a 'cache-store' policy alone in the backend section does not include a 'cache-lookup' to retrieve cached responses, and the backend section is not the correct location for response caching; caching policies must be paired in inbound/outbound sections.

Practice this question →

53

MCQhard

A developer is building a microservices application on Azure Kubernetes Service (AKS). One service needs to consume messages from an Azure Service Bus queue. The solution must minimize cost and automatically scale based on the number of messages. Which approach should the developer choose?

A.Use KEDA to scale the pods based on the Service Bus queue length

B.Use Azure Event Grid to route messages to the microservice

C.Use Azure Functions with a Service Bus trigger on a dedicated App Service plan

D.Use the Azure Service Bus SDK in the pod code and manually scale pods

AnswerA

KEDA (Kubernetes Event-driven Autoscaling) is the optimal choice as it directly integrates with Azure Service Bus, enabling event-driven autoscaling for Kubernetes pods. It monitors the Service Bus queue length and automatically scales the number of microservice pods up or down based on the message backlog. This dynamic scaling ensures that compute resources are efficiently utilized, only consuming capacity when demand exists, which significantly optimizes operational costs and maintains application responsiveness.

Why this answer

KEDA (Kubernetes Event-Driven Autoscaling) is the correct choice because it natively integrates with Azure Service Bus to monitor queue length and automatically scale the number of pods in AKS based on that metric. This minimizes cost by scaling to zero when there are no messages and scaling up only as needed, without requiring manual intervention or additional infrastructure.

Exam trap

The trap here is that candidates might choose Azure Functions (Option C) because of its built-in Service Bus trigger, overlooking that the question explicitly requires the solution to run on AKS and minimize cost, whereas Functions on a dedicated plan incurs higher cost and is not part of the AKS microservices architecture.

How to eliminate wrong answers

Option B is wrong because Azure Event Grid is a publish-subscribe event routing service, not designed for consuming messages from a queue; it would require additional components to handle message processing and does not provide built-in autoscaling based on queue depth. Option C is wrong because Azure Functions with a Service Bus trigger on a dedicated App Service plan incurs higher costs compared to KEDA on AKS, and it moves the workload outside the microservices architecture on AKS, violating the requirement to minimize cost and stay within the AKS environment. Option D is wrong because manually scaling pods using the Azure Service Bus SDK in the pod code defeats the purpose of automatic scaling and increases operational overhead, making it inefficient and cost-ineffective.

Practice this question →

54

MCQeasy

A business process requires sending an approval email, waiting up to 48 hours for a manager's response, and then updating a SharePoint list based on the decision. The process owner has no programming experience and wants to build this without writing code. Which Azure service is the most appropriate?

A.Azure Logic Apps with the Office 365 Outlook approval action and the SharePoint connector

B.Azure Durable Functions with the Human Interaction pattern using a timer and event listener

C.Azure Data Factory with a Copy Activity pipeline triggered by an Azure Function

D.Azure Event Grid with a custom webhook handler that calls the SharePoint REST API

AnswerA

The Logic Apps approval action sends an email with Approve/Reject buttons and suspends the workflow run (using Azure's durable storage) until the response arrives or the timeout expires. The SharePoint connector's 'Update item' action then writes the outcome to the list. The entire workflow is configured without code using the Logic Apps Designer.

Why this answer

Azure Logic Apps is the correct choice because it provides a no-code/low-code designer that allows the process owner to visually build the approval workflow using the Office 365 Outlook 'Send approval email' action and the SharePoint connector to update the list. This fully meets the requirement of no programming experience while handling the 48-hour wait and conditional update.

Exam trap

The trap here is that candidates may over-engineer the solution by choosing Durable Functions (Option B) because they recognize the Human Interaction pattern, but they overlook the explicit 'no programming experience' constraint that makes Logic Apps the only viable choice.

How to eliminate wrong answers

Option B is wrong because Azure Durable Functions require writing code in C#, JavaScript, or Python to implement the Human Interaction pattern, which violates the 'no programming experience' requirement. Option C is wrong because Azure Data Factory is designed for data movement and transformation pipelines, not for human approval workflows or sending emails. Option D is wrong because Azure Event Grid is a pub/sub event routing service that requires a custom webhook handler (typically an Azure Function or web app) to process the approval logic and call the SharePoint REST API, which again requires coding.

Practice this question →

55

Multi-Selectmedium

Which TWO approaches can you use to call an external REST API from an Azure Function while ensuring the API key is not exposed in the function code?

Select 2 answers

A.Store the API key in GitHub repository secrets.

B.Hardcode the API key in the function code.

C.Store the API key as an environment variable in the function app settings.

D.Pass the API key in an HTTP header and include it in the source code.

E.Store the API key in Azure Key Vault and retrieve it using Managed Identity.

AnswersC, E

Storing the API key as an application setting within the Azure Function App configuration is a standard and secure practice for managing secrets. These settings are exposed to the function code as environment variables at runtime, keeping the sensitive key out of the source code. This approach allows for independent management, updates without code redeployment, and benefits from Azure's platform-level access controls.

Why this answer

Storing the API key in the function app settings (environment variables) keeps it out of the source code and allows the function to access it via the `Environment.GetEnvironmentVariable` method at runtime. Option E is correct because Azure Key Vault, combined with a Managed Identity, provides a secure, auditable, and rotation-friendly way to store secrets without embedding them in code or configuration files.

Exam trap

The trap here is that candidates often confuse storing secrets in environment variables (which is acceptable for app settings) with storing them in source code or CI/CD secrets, and they may overlook that Managed Identity with Key Vault is the recommended enterprise pattern for production-grade secret management.

Practice this question →

56

MCQhard

A company uses Azure API Management (APIM) to expose APIs to external partners. They need to enforce rate limiting per subscription key. Which APIM policy should be configured?

A.quota

B.rate-limit

C.ip-filter

D.throttling

AnswerB

The "rate-limit" policy in Azure API Management is specifically engineered to restrict the number of API calls a client can make within a precise, short time interval, such as per second or per minute. This policy can be effectively scoped to a `subscription-key`, ensuring that individual API consumers are prevented from making excessive requests and thereby protecting backend services from overload. It operates using a sliding or fixed window counter, rejecting requests that exceed the defined threshold until the window resets.

Why this answer

The rate-limit policy in Azure API Management is specifically designed to enforce rate limiting per subscription key, preventing individual API consumers from exceeding a defined number of calls within a specified time window (e.g., per second or per minute). This policy operates on a sliding window counter, ensuring fair usage across partners without affecting other subscribers. It is the correct choice because it directly targets subscription-based throttling at the API gateway level.

Exam trap

The trap here is that candidates confuse the 'quota' policy (which enforces total call volume over a long period) with 'rate-limit' (which enforces call frequency over a short window), or mistakenly think 'throttling' is a valid policy name when it is actually a deprecated term replaced by 'rate-limit' in Azure API Management.

How to eliminate wrong answers

Option A is wrong because the quota policy enforces a total number of calls over a longer period (e.g., per day, week, or month) and does not provide the per-time-window rate limiting required for subscription keys; it is used for volume-based caps, not rate limiting. Option C is wrong because the ip-filter policy restricts access based on client IP addresses, not subscription keys, and is used for security filtering rather than rate limiting. Option D is wrong because the throttling policy is a legacy name for rate limiting in older APIM documentation, but the correct current policy name is 'rate-limit'; 'throttling' is not a valid policy identifier in Azure API Management and would cause a configuration error.

Practice this question →

57

MCQmedium

You manage an API in Azure API Management. You need to enforce a rate limit of 200 requests per minute for each subscription key. Which policy should you include in the inbound policy section?

A.<rate-limit> policy

B.<quota> policy

C.<limit-concurrency> policy

D.<throttle> policy

AnswerA

The <rate-limit> policy is designed to restrict the number of API calls a client can make within a specified short time interval, such as per minute or per second. It operates using a sliding window mechanism, continuously evaluating the call count against the defined limit. This policy is crucial for preventing bursts of traffic, protecting backend services from overload, and ensuring fair usage across consumers by enforcing immediate call rate constraints.

Why this answer

The <rate-limit> policy in Azure API Management is specifically designed to enforce a per-subscription key rate limit, such as 200 requests per minute. It operates on a sliding window counter to smooth traffic and is applied in the inbound section to evaluate each request before it reaches the backend. This matches the requirement exactly.

Exam trap

The trap here is confusing <rate-limit> with <quota>, as both control request volume, but <quota> applies to total counts over days/months, not per-minute rate limiting.

How to eliminate wrong answers

Option B is wrong because the <quota> policy enforces a total number of requests over a longer period (e.g., 10,000 calls per month), not a per-minute rate limit. Option C is wrong because the <limit-concurrency> policy restricts the number of simultaneous connections, not the request rate over time. Option D is wrong because there is no <throttle> policy in Azure API Management; the correct term is <rate-limit> for per-key throttling.

Practice this question →

58

MCQmedium

You are using Azure Logic Apps to integrate with a third-party CRM. The CRM API requires OAuth 2.0 authentication with a client secret. The secret must be stored securely and rotated automatically. What should you do?

A.Use a system-assigned managed identity without storing the secret

B.Store the secret in Azure Key Vault and use a managed identity to access it

C.Store the secret in the Logic App definition as a string parameter

D.Store the secret in Azure App Configuration with encryption

AnswerB

Correct. Store the client secret in Azure Key Vault, which provides secure storage and automatic rotation. Use a managed identity to allow the Logic App to retrieve the secret securely.

Why this answer

The CRM API requires OAuth 2.0 with a client secret, so the secret must be stored securely and support automatic rotation. Azure Key Vault is the appropriate service for storing secrets, and using a managed identity allows secure access without hardcoding credentials. Option A is incorrect because a managed identity alone does not store the secret; the secret must be kept in a vault.

Option C is wrong because storing secrets directly in a Logic App definition is insecure and does not support rotation. Option D is wrong because Azure App Configuration is designed for application settings, not secrets; it lacks automatic secret rotation capabilities.

Practice this question →

59

MCQhard

You are designing a solution to securely store connection strings for an Azure Function app that connects to Azure Service Bus. The connection string contains a Shared Access Key. The company policy requires that secrets be rotated every 90 days and that no secret is stored in source code or configuration files. The solution should minimize operational overhead. What should you use?

A.Store the connection string in Azure Key Vault and use a managed identity to access it from the Function app.

B.Store the connection string in a JSON configuration file and use Azure Policy to enforce encryption.

C.Store the connection string in Azure App Configuration with encryption at rest using a customer-managed key.

D.Store the connection string as an environment variable in the Function app's application settings.

AnswerA

Key Vault with managed identity provides secure storage, rotation, and no secrets in code.

Why this answer

Azure Key Vault provides a centralized, secure store for secrets like connection strings, and using a managed identity allows the Azure Function app to authenticate to Key Vault without storing any credentials in code or configuration. This approach satisfies the rotation policy by enabling automatic or scheduled secret rotation in Key Vault, and it minimizes operational overhead by eliminating manual credential management.

Exam trap

The trap here is that candidates may confuse Azure App Configuration with Azure Key Vault, thinking App Configuration's encryption at rest is sufficient for secrets, but App Configuration lacks secret rotation and managed identity integration for secure access.

How to eliminate wrong answers

Option B is wrong because storing the connection string in a JSON configuration file, even with Azure Policy enforcing encryption, still places the secret in source code or configuration files, violating the policy that no secret be stored there. Option C is wrong because Azure App Configuration is designed for application configuration settings, not secrets; it lacks native secret rotation capabilities and does not provide the same level of security as Key Vault for sensitive data like connection strings. Option D is wrong because storing the connection string as an environment variable in the Function app's application settings still exposes the secret in the Azure portal and configuration, and it does not support automated rotation or managed identity-based access, increasing operational overhead.

Practice this question →

60

MCQmedium

You are deploying a microservices application to Azure Kubernetes Service (AKS). One service needs to retrieve configuration values from Azure App Configuration. The configuration includes sensitive values that must be stored in Azure Key Vault. The solution should not require application code changes to reference Key Vault. What should you use?

A.Store the configuration values as Key Vault references in Azure App Configuration.

B.Use Azure AD managed identity to access Key Vault directly from the service.

C.Store the secrets in Kubernetes Secrets and mount them as environment variables.

D.Use the Azure Key Vault SDK directly in the service to retrieve secrets.

AnswerA

Storing configuration values as Key Vault references in Azure App Configuration is the most robust solution for microservices. Azure App Configuration automatically resolves these references at runtime, fetching the actual secret value from Key Vault using its own managed identity. This centralizes configuration management, enhances security by keeping secrets out of application code, and allows for dynamic updates without redeploying microservices.

Why this answer

Azure App Configuration supports Key Vault references, which allow you to store a reference to a secret in Key Vault rather than the secret itself. When the application retrieves the configuration value, App Configuration automatically resolves the reference and fetches the secret from Key Vault, requiring no code changes. This satisfies the requirement of storing sensitive values in Key Vault while keeping the application code unchanged.

Exam trap

The trap here is that candidates often assume managed identity (Option B) is the correct answer because it avoids storing credentials, but they overlook that it still requires code changes to call Key Vault directly, whereas Key Vault references in App Configuration provide a code-free integration.

How to eliminate wrong answers

Option B is wrong because using Azure AD managed identity to access Key Vault directly from the service would require application code changes to call the Key Vault SDK or REST API, which violates the requirement of no code changes. Option C is wrong because storing secrets in Kubernetes Secrets and mounting them as environment variables does not use Azure App Configuration or Key Vault, and it introduces security risks such as base64-encoded secrets and lack of centralized management. Option D is wrong because using the Azure Key Vault SDK directly in the service requires explicit code changes to retrieve secrets, which contradicts the requirement that the solution should not require application code changes to reference Key Vault.

Practice this question →

61

MCQeasy

A developer needs to store session state for a web app that runs on multiple instances behind a load balancer. The state must be persisted across restarts. Which Azure service should they use?

A.Azure Table Storage

B.Azure SQL Database

C.Azure Blob Storage

D.Azure Cache for Redis

AnswerD

Azure Cache for Redis is an in-memory data store based on the open-source Redis project, providing extremely low-latency access to data. It is specifically designed for caching, session state management, and message brokering, offering high performance and scalability. Its native support for various session state providers in frameworks like ASP.NET makes it an ideal, efficient, and cost-effective solution for storing volatile session data.

Why this answer

Azure Cache for Redis is the correct choice because it provides a high-performance, in-memory data store that supports session state persistence across multiple web app instances behind a load balancer. It offers built-in session state providers for ASP.NET and ASP.NET Core, ensuring state is preserved across restarts and scale-out scenarios with low-latency access.

Exam trap

The trap here is that candidates often confuse durable storage (like Table Storage or SQL Database) with the need for fast, in-memory session state, overlooking that Azure Cache for Redis is the only service purpose-built for this exact scenario with built-in session providers and low-latency access.

How to eliminate wrong answers

Option A is wrong because Azure Table Storage is a NoSQL key-value store designed for structured, non-relational data and lacks the low-latency, in-memory caching capabilities required for session state, making it unsuitable for high-throughput web apps. Option B is wrong because Azure SQL Database is a relational database that, while capable of persisting session state, introduces significant latency and overhead compared to an in-memory cache, and is not optimized for the frequent read/write patterns of session management. Option C is wrong because Azure Blob Storage is an object storage service for unstructured data like files and images, not designed for transactional, low-latency session state operations, and would result in poor performance and scalability issues.

Practice this question →

62

MCQmedium

A company uses Azure Functions with an HTTP trigger and Azure Cosmos DB. They need to securely store connection strings for Cosmos DB and rotate them automatically every 90 days. Which service should they use?

A.Azure Key Vault

B.Managed Identity

C.Azure App Configuration

D.Microsoft Entra ID

AnswerA

Azure Key Vault is the correct solution for securely storing secrets and managing their lifecycle, including automatic rotation. It provides a centralized, highly secure repository for cryptographic keys, certificates, and secrets like API keys or database connection strings. Azure Functions can securely retrieve these secrets at runtime, and Key Vault's integration capabilities allow for automated secret rotation, enhancing security posture by regularly changing sensitive credentials without manual intervention.

Why this answer

Azure Key Vault is the correct service because it provides a centralized, secure store for secrets like connection strings and supports automatic rotation policies. By storing the Cosmos DB connection string in Key Vault and configuring a rotation policy (e.g., every 90 days), the Azure Function can retrieve the latest secret at runtime via a Key Vault reference in its application settings, ensuring the secret is rotated without code changes or downtime.

Exam trap

The trap here is that candidates often confuse Managed Identity with a secret storage solution, thinking it can store and rotate connection strings, when in reality it only provides an identity for authentication and cannot manage or rotate secrets like a connection string.

How to eliminate wrong answers

Option B is wrong because Managed Identity provides an identity for the Azure Function to authenticate to Azure services without storing credentials, but it does not store or rotate connection strings—it only enables token-based access to resources like Cosmos DB via Azure RBAC, which is not the same as rotating a connection string. Option C is wrong because Azure App Configuration is designed for managing application configuration settings and feature flags, not for securely storing secrets with automatic rotation; it lacks built-in secret rotation policies and should not be used for sensitive connection strings. Option D is wrong because Microsoft Entra ID (formerly Azure AD) is an identity and access management service that provides authentication and authorization, but it does not store secrets like connection strings or offer automatic rotation capabilities—it can be used to grant access to Key Vault but is not the secret store itself.

Practice this question →

63

MCQmedium

Your application uses Azure Cosmos DB for NoSQL. You need to query items by a property that is not the partition key. The container has 10,000 RU/s. How can you optimize this query to minimize cost and latency?

A.Increase the RU/s to handle cross-partition queries.

B.Create a composite index that includes the property and the partition key.

C.Change the partition key to the property you query on.

D.Enable analytical store and use Synapse Link.

AnswerB

Creating a composite index that includes both the queried property and the partition key is crucial for optimizing cross-partition queries. This index allows the Cosmos DB query engine to efficiently seek and filter documents within each partition based on the specified property, rather than performing a full scan of all documents across all partitions. This significantly reduces RU consumption and improves query latency by leveraging the index for efficient data retrieval.

Why this answer

Creating a composite index that includes the queried property and the partition key allows the query to be served efficiently from a single physical partition, avoiding a costly cross-partition fan-out. This reduces both RU consumption and latency, as the query can use the index without scanning all partitions.

Exam trap

The trap here is that candidates often assume increasing RU/s (Option A) is the only way to handle cross-partition queries, but the exam tests the understanding that indexing strategy—specifically composite indexes—can eliminate the need for cross-partition fan-out, which is a more cost-effective and latency-optimizing approach.

How to eliminate wrong answers

Option A is wrong because increasing RU/s does not optimize the query itself; it only increases throughput capacity, which may reduce throttling but does not address the root cause of cross-partition query overhead. Option C is wrong because changing the partition key to the queried property would require recreating the container and re-ingesting all data, which is disruptive and not an optimization for the existing schema. Option D is wrong because enabling analytical store and using Synapse Link is designed for large-scale analytical workloads (OLAP), not for optimizing point or small-range queries on operational data (OLTP); it adds cost and complexity without improving query latency or RU cost for the described scenario.

Practice this question →

64

MCQmedium

You are implementing a custom API that calls a downstream API secured with OAuth 2.0. The downstream API requires a client credentials grant flow. You need to securely store the client secret and obtain an access token. What should you use?

A.Azure App Configuration to store the secret and the Azure Identity SDK to obtain the token

B.Managed identity to access the downstream API directly

C.Azure Key Vault to store the secret and MSAL to obtain the token

D.Azure Certificate Manager to store the secret and the HttpClient to obtain the token

AnswerC

Azure Key Vault is the recommended and secure service for storing cryptographic keys, certificates, and sensitive secrets like API client secrets. It provides robust access control, auditing, and encryption at rest and in transit, ensuring the secret's confidentiality. The Microsoft Authentication Library (MSAL) is the appropriate SDK for acquiring tokens from Microsoft identity platform, including implementing the client credentials flow where an application uses its own identity (client ID and secret retrieved from Key Vault) to obtain an access token for a downstream API.

Why this answer

Azure Key Vault provides secure, auditable storage for client secrets, and MSAL (Microsoft Authentication Library) is the recommended SDK for implementing OAuth 2.0 client credentials grant flows in Azure. MSAL handles token acquisition, caching, and renewal, while Key Vault ensures the secret is never exposed in code or configuration files.

Exam trap

The trap here is that candidates often confuse Azure App Configuration with Azure Key Vault, assuming App Configuration's encryption is sufficient for secrets, or they mistakenly believe managed identity can be used to authenticate to any OAuth 2.0-secured API, when in fact managed identity only works with Azure AD-integrated services and not arbitrary downstream APIs.

How to eliminate wrong answers

Option A is wrong because Azure App Configuration is designed for managing application settings and feature flags, not for securely storing secrets; it lacks the encryption-at-rest and access policy features of Key Vault, and the Azure Identity SDK is used for managed identity or default credential flows, not for client credentials grant with a stored secret. Option B is wrong because managed identity is intended for Azure resources to authenticate to Azure services without secrets, but the downstream API is a custom API secured with OAuth 2.0, not an Azure service that supports managed identity authentication directly. Option D is wrong because Azure Certificate Manager does not exist as an Azure service; the correct service for certificate management is Azure Key Vault, and using HttpClient directly to obtain a token would require manually implementing the OAuth 2.0 protocol, which is error-prone and not recommended over using MSAL.

Practice this question →

65

Multi-Selectmedium

Which THREE services can be used to implement a pub/sub messaging pattern in Azure?

Select 3 answers

A.Azure Service Bus Topics

B.Azure Notification Hubs

C.Azure Queue Storage

D.Azure Event Grid

E.Azure Event Hubs

AnswersA, D, E

Topics support multiple subscribers.

Why this answer

Azure Service Bus Topics supports a pub/sub pattern by allowing multiple subscriptions to receive copies of messages sent to a topic. Each subscription acts as a logical queue, and messages are automatically routed to all subscriptions that match the filtering rules, enabling decoupled communication between publishers and subscribers.

Exam trap

The trap here is that candidates often confuse Azure Queue Storage (point-to-point) with a pub/sub service, or mistakenly think Notification Hubs supports pub/sub because it broadcasts to many devices, but it lacks subscriber-managed subscriptions and message retention for independent consumption.

Practice this question →

66

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

A.Azure DNS

B.Azure Event Grid

C.Azure Files

D.Azure Service Bus queue

AnswerB

Azure Event Grid is a highly scalable, fully managed event routing service that enables reactive programming by delivering events from various sources to different handlers. It operates on a publish-subscribe model, allowing applications to subscribe to specific event types from Azure services like Storage Accounts, Resource Groups, or custom topics. Its design specifically caters to high-volume event notifications, providing low-latency delivery and robust filtering capabilities, making it ideal for scenarios requiring immediate processing of discrete events.

Why this answer

Azure Event Grid is a fully managed event routing service that uses a publish-subscribe model to deliver lightweight, high-volume events from Azure resources to registered handlers like Azure Functions or webhooks. It supports native event routing without requiring custom polling scripts or infrastructure, making it ideal for serverless event-driven architectures.

Exam trap

The trap here is that candidates often confuse Azure Event Grid with Azure Service Bus, but Event Grid is designed for reactive event routing (push model) with no need for polling or custom scripts, whereas Service Bus is for message queuing with explicit consumer processing.

How to eliminate wrong answers

Option A is wrong because Azure DNS is a domain name resolution service that translates domain names to IP addresses; it does not route events or handle event notifications. Option C is wrong because Azure Files provides fully managed file shares in the cloud, used for storing and accessing files via SMB or NFS protocols, not for event routing. 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 requires custom polling or message processing logic and is not optimized for lightweight, native event routing without operational scripts.

Practice this question →

67

MCQeasy

A company uses Azure Service Bus to decouple microservices. They need to ensure that messages are processed in the order they are received, and that each message is handled by exactly one consumer instance even when the system scales out. Which feature should they enable?

A.Sessions

B.Topics

C.Dead-letter queue

D.Duplicate detection

AnswerA

Azure Service Bus Sessions provide guaranteed ordered delivery (FIFO) and single-consumer processing for related messages. Messages belonging to the same session, identified by a `SessionId` property, are delivered exclusively to a single receiver. This receiver acquires an exclusive lock on the session, ensuring that all messages within that session are processed sequentially by only one consumer at a time, preventing out-of-order processing or concurrent handling of related messages.

Why this answer

Sessions in Azure Service Bus enforce first-in-first-out (FIFO) ordering and guarantee that all messages with the same session ID are processed by a single consumer instance. This ensures strict message ordering and exactly-once processing per session, even when multiple consumers are scaled out. Without sessions, competing consumers would break ordering because messages could be processed by different instances concurrently.

Exam trap

The trap here is that candidates often confuse topics (which support multiple subscribers) with the need for ordering and single-consumer processing, overlooking that sessions are the specific feature designed for FIFO and exclusive consumption in a competing-consumers pattern.

How to eliminate wrong answers

Option B (Topics) is wrong because topics implement a publish/subscribe pattern where each subscription receives a copy of every message, allowing multiple consumers to process the same message, which violates the 'exactly one consumer' requirement. Option C (Dead-letter queue) is wrong because dead-letter queues are used to hold messages that cannot be processed normally (e.g., due to exceeding max delivery count or TTL), not to enforce ordering or single-consumer processing. Option D (Duplicate detection) is wrong because duplicate detection prevents duplicate message delivery within a specified time window but does not guarantee message ordering or ensure single-consumer processing.

Practice this question →

68

MCQmedium

You are configuring an Azure Event Grid subscription to trigger an Azure Function when a blob is created in a storage account. However, the function is not being triggered. You have verified that the function endpoint is reachable and the storage account is in the same region. What is the most likely cause?

A.The storage account has public network access disabled.

B.The AzureWebJobsStorage connection string is missing from the function app settings.

C.Blob versioning is not enabled on the storage account.

D.The Event Grid subscription does not have the required RBAC role on the function.

AnswerD

For an Event Grid subscription to successfully deliver events to an Azure Function app, the Event Grid system topic's managed identity or service principal requires appropriate permissions on the target function. Specifically, the 'Event Grid Data Sender' role must be assigned to the function app or its containing resource group. Without this role, Event Grid lacks the necessary authorization to invoke the function's HTTP endpoint, resulting in delivery failures even if the endpoint is otherwise accessible. This RBAC assignment ensures secure communication and event delivery.

Why this answer

If the Azure Function app is secured with Azure AD authentication, and the Event Grid subscription is configured to use a managed identity for delivery, then that managed identity requires an appropriate RBAC role (e.g., 'Azure Function Data Sender' or a custom role allowing `Microsoft.Web/sites/functions/invoke/action`) on the function app to successfully invoke the function. Without this role, Event Grid cannot authorize its call to the function, even if the endpoint is network reachable. This is a common misconfiguration when the function is protected by Azure AD authentication.

Exam trap

The trap here is that candidates often focus on storage account networking or function app settings (like AzureWebJobsStorage) instead of recognizing that Event Grid requires explicit RBAC permissions when the function endpoint is secured with Azure AD authentication.

How to eliminate wrong answers

Option A is wrong because disabling public network access on the storage account affects data plane operations (e.g., blob read/write), not the Event Grid event delivery path; Event Grid uses its own internal HTTPS calls to the function endpoint, not the storage account's network. Option B is wrong because the AzureWebJobsStorage connection string is used by the function runtime for internal storage (e.g., checkpointing, logs), not for receiving Event Grid triggers; the trigger binding itself does not depend on this setting. Option C is wrong because blob versioning is a feature for preserving previous blob versions and is not required for Event Grid to detect a blob creation event; Event Grid uses storage account event notifications (e.g., BlobCreated) which work independently of versioning.

Practice this question →

69

MCQmedium

Your company uses Azure Blob Storage to store sensitive documents. You need to ensure that all access to the storage account is encrypted in transit and that clients must use TLS 1.2 or higher. Which configuration should you enforce?

A.Use a private endpoint for the storage account.

B.Set the 'Minimum TLS version' to 1.2 in the storage account's configuration.

C.Configure network rules to allow only from trusted IPs.

D.Enable 'Secure transfer required' (HTTPS only).

AnswerB

Setting the 'Minimum TLS version' to 1.2 in the storage account's configuration directly addresses the requirement to enforce a specific encryption standard. This configuration ensures that Azure Storage will reject any connection attempts that utilize older, less secure TLS versions (such as TLS 1.0 or TLS 1.1). Consequently, all data in transit to and from the storage account will be encrypted using the more robust and secure TLS 1.2 or later protocols, meeting compliance and security best practices.

Why this answer

Setting the 'Minimum TLS version' to 1.2 in the storage account's configuration explicitly enforces that all client connections must use TLS 1.2 or higher, rejecting any requests using older, less secure TLS versions. This directly addresses the requirement to ensure encryption in transit with a specific minimum TLS version, as Azure Blob Storage supports TLS 1.0, 1.1, and 1.2 by default, and this setting overrides that default to enforce the higher standard.

Exam trap

The trap here is that candidates often confuse 'Secure transfer required' (which only enforces HTTPS) with the 'Minimum TLS version' setting, mistakenly believing that enabling HTTPS alone guarantees a specific TLS version, when in fact HTTPS can be negotiated over TLS 1.0, 1.1, or 1.2 unless explicitly restricted.

How to eliminate wrong answers

Option A is wrong because using a private endpoint restricts network access to the storage account over a private IP within a virtual network, but it does not enforce encryption in transit or a specific TLS version; traffic over a private endpoint still uses HTTPS but the TLS version is not controlled by this configuration. Option C is wrong because configuring network rules to allow only from trusted IPs controls which source IP addresses can access the storage account, but it does not enforce encryption in transit or mandate TLS 1.2; traffic from allowed IPs could still use HTTP or older TLS versions. Option D is wrong because enabling 'Secure transfer required' (HTTPS only) ensures that all requests must use HTTPS, but it does not enforce a minimum TLS version; clients could still connect using TLS 1.0 or 1.1 over HTTPS, which does not meet the requirement for TLS 1.2 or higher.

Practice this question →

70

MCQmedium

Refer to the exhibit. The APIM policy is applied to an API. What is the effect of this policy?

A.Each subscription can make up to 10 calls per minute.

B.Each subscription can make up to 10 calls total.

C.Each IP address can make up to 10 calls per minute.

D.All calls from a single IP are blocked after 10 requests.

AnswerA

The `rate-limit` policy, when applied without a `by-key` attribute, defaults to limiting requests per subscription key. With `calls='10'` and `renewal-period='60'`, it precisely means that a single subscription is permitted to make a maximum of 10 API calls within any 60-second window. This ensures fair usage and prevents individual subscriptions from overwhelming the API backend.

Why this answer

The policy snippet uses the `rate-limit` policy, which enforces a per-subscription key rate limit. The `calls` attribute is set to 10 and the `renewal-period` is 60 seconds, meaning each subscription key is allowed up to 10 API calls within any 60-second sliding window. This matches option A exactly.

Exam trap

The trap here is confusing `rate-limit` (per-subscription, sliding window) with `rate-limit-by-key` (per-IP or custom key) or with a hard total quota, leading candidates to mistakenly choose IP-based or total-call options.

How to eliminate wrong answers

Option B is wrong because the `rate-limit` policy does not enforce a total lifetime cap; it resets every 60 seconds, so calls are not limited to a total of 10. Option C is wrong because the `rate-limit` policy operates on subscription keys, not IP addresses; IP-based rate limiting would use the `rate-limit-by-key` policy with a different context variable. Option D is wrong because the policy does not block calls after 10 requests; it allows up to 10 calls per minute and then returns a 429 Too Many Requests status for additional calls within that minute, but the counter resets after the renewal period.

Practice this question →

71

MCQeasy

A developer is building a solution that sends emails via SendGrid from Azure. Which Azure service should they use to integrate with SendGrid?

A.Azure Logic Apps

B.Azure API Management

C.Azure Functions

D.Azure Event Grid

AnswerA

Azure Logic Apps is a cloud-based service designed for automating workflows and integrating systems across various applications and services. It provides a rich gallery of pre-built connectors, including a dedicated one for SendGrid, which significantly simplifies the process of sending emails without requiring extensive custom code. This low-code/no-code approach makes Logic Apps an ideal choice for orchestrating email delivery as part of a larger business process or in response to specific events, directly handling the API interaction with SendGrid.

Why this answer

Azure Logic Apps provides a managed connector for SendGrid that simplifies integration by offering pre-built triggers and actions for sending emails. This allows developers to create automated workflows without writing custom code, making it the ideal choice for integrating SendGrid with Azure services.

Exam trap

The trap here is that candidates often choose Azure Functions because they think 'custom code is needed for email sending,' but the exam emphasizes using managed services with minimal code, making Logic Apps the correct choice for integration with third-party services like SendGrid.

How to eliminate wrong answers

Option B is wrong because Azure API Management is used to publish, secure, and analyze APIs, not to directly integrate with third-party email services like SendGrid. Option C is wrong because Azure Functions can send emails via SendGrid using custom code, but it requires manual implementation of HTTP calls or SDK usage, lacking the built-in connector and workflow automation that Logic Apps provides. Option D is wrong because Azure Event Grid is an event routing service that delivers events to subscribers, but it does not include native SendGrid integration or email-sending capabilities.

Practice this question →

72

MCQmedium

You are building an Azure Logic App that must call an external API secured with OAuth 2.0 Client Credentials flow. The external API is registered in a different Microsoft Entra ID tenant. You need to obtain an access token and add it to the request headers. Which action and authentication configuration should you use?

A.Use the HTTP action with Managed Identity authentication.

B.Use the HTTP + Swagger connector to import the API definition.

C.Use the HTTP action with Active Directory OAuth authentication, providing the tenant ID, client ID, and client secret.

D.Use the Azure Key Vault - Get secret action to retrieve a token.

AnswerC

This configuration correctly leverages the OAuth 2.0 Client Credentials flow, where the Logic App acts as a confidential client. By providing the external API's Microsoft Entra ID tenant ID, a registered application's client ID, and its corresponding client secret, the Logic App can directly request an access token from the external tenant's token endpoint. This token is then automatically attached to the HTTP request, authorizing access to the external API even across different tenants.

Why this answer

The HTTP action's Active Directory OAuth authentication type directly supports the OAuth 2.0 Client Credentials flow for cross-tenant scenarios. By providing the tenant ID, client ID, and client secret, the Logic App runtime can obtain an access token from the external tenant's token endpoint and automatically inject it into the Authorization header as a Bearer token. This is the only built-in authentication option in the HTTP action that handles the client credentials grant without custom code.

Exam trap

The trap here is that candidates often confuse Managed Identity with cross-tenant authentication, assuming it works across tenants, when in fact Managed Identity is strictly scoped to the resource's home tenant.

How to eliminate wrong answers

Option A is wrong because Managed Identity authentication only works within the same tenant as the Logic App; it cannot be used to obtain tokens from a different Microsoft Entra ID tenant. Option B is wrong because the HTTP + Swagger connector is used to import an API definition for design-time validation and does not provide any OAuth 2.0 Client Credentials token acquisition capability. Option D is wrong because the Azure Key Vault - Get secret action retrieves a stored secret (like a client secret) but does not perform the OAuth 2.0 token exchange; you would still need a separate action to call the token endpoint and construct the Bearer token.

Practice this question →

73

MCQmedium

Your company has a set of REST APIs that are exposed through Azure API Management (APIM). One of the backend APIs is secured and requires an OAuth 2.0 access token from Microsoft Entra ID. The APIM instance has a system-assigned managed identity with permissions to request tokens for the backend API's scope. You need to configure APIM to automatically obtain a token and pass it to the backend API when requests come in. What should you do?

A.Add a set-backend-service policy with the authentication-managed-identity attribute

B.Configure the backend API's subscription key in policy

C.Use a validate-jwt policy to check incoming token

D.Create a named value with the token and reference it in policy

AnswerA

The `set-backend-service` policy with the `authentication-managed-identity` attribute is the correct approach for API Management to securely authenticate to an Azure AD-protected backend. This policy instructs APIM to use its assigned managed identity to automatically acquire an OAuth 2.0 access token from Azure Active Directory. The obtained token is then seamlessly added as a `Bearer` token in the `Authorization` header of the request forwarded to the backend API, eliminating the need for manual credential management.

Why this answer

The `set-backend-service` policy with the `authentication-managed-identity` attribute allows APIM to use its system-assigned managed identity to obtain an OAuth 2.0 access token from Microsoft Entra ID for the specified backend API scope. This token is automatically attached to the backend request as an Authorization header, enabling secure access without manual token management.

Exam trap

The trap here is that candidates confuse `validate-jwt` (which checks client tokens) with the need to obtain a new token for the backend, or they assume a static token stored in a named value is sufficient, ignoring the dynamic nature of OAuth 2.0 token expiry and managed identity capabilities.

How to eliminate wrong answers

Option B is wrong because subscription keys are used for APIM-level authentication and rate limiting, not for obtaining OAuth 2.0 tokens for backend APIs. Option C is wrong because `validate-jwt` only validates an incoming token from the client; it does not obtain or attach a token for the backend. Option D is wrong because named values store static secrets or configuration strings, not dynamically obtained tokens; manually storing a token would require frequent updates and defeats the purpose of managed identity.

Practice this question →

74

MCQhard

A company has an Azure App Service web app that reads from Azure Blob Storage. The app uses a connection string stored in app settings. Recently, the storage account key was rotated, and the app started throwing authentication errors. What should the developer do to resolve this issue without redeploying the app?

A.Change the app to use managed identity

B.Rotate the storage account key again

C.Update the connection string in the app settings to use the new key

D.Restart the app service

AnswerC

Updating the app settings will automatically restart the app with the new connection string.

Why this answer

Updating the connection string in the App Service app settings (e.g., via Azure portal or Azure CLI) automatically restarts the app, applying the new key without requiring a redeployment. Option A (managed identity) would require code changes and is not necessary if connection strings are acceptable. Option B (rotating the key again) does not fix the mismatch if the app retains the old key.

Option D (restarting the app) alone does not update the stored connection string.

Practice this question →

75

MCQeasy

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

A.Add a 'Get secret' action from Key Vault to retrieve the secret, then use the 'HTTP' action and set the 'X-API-Key' header to the secret value using a dynamic expression.

B.Configure the HTTP action to use managed identity authentication and set the 'Audience' to the Key Vault URL. This will automatically pass the API key as the Authorization header.

C.Store the API key in an Azure App Service application setting and reference it from the Logic App using the 'appsetting' function.

D.Use the 'Invoke an HTTP endpoint' action with Application Insights dependency tracking enabled. The API key is automatically logged by Application Insights.

AnswerA

This is the correct approach. The Logic App can use a managed identity to authenticate to Key Vault, retrieve the secret via the 'Get secret' action, and then use that value in the HTTP request header.

Why this answer

It uses the native 'Get secret' action from Azure Key Vault to securely retrieve the API key at runtime, leveraging the Logic App's managed identity for authentication. The secret value can then be dynamically injected into the 'X-API-Key' header of the subsequent HTTP action using an expression like `@{outputs('Get_secret')?['value']}`. This approach follows the principle of least privilege and avoids hardcoding secrets or exposing them in configuration.

Exam trap

The trap here is that candidates may confuse managed identity authentication on an HTTP action (which is for authenticating to the target API) with the mechanism to retrieve secrets from Key Vault, leading them to incorrectly select Option B.

How to eliminate wrong answers

Option B is wrong because managed identity authentication on an HTTP action is used to authenticate the Logic App to the target API (e.g., using OAuth 2.0), not to retrieve a secret from Key Vault; setting the 'Audience' to the Key Vault URL would attempt to authenticate to Key Vault, not pass the API key in the header. Option C is wrong because Azure App Service application settings are not accessible from a Logic App via the 'appsetting' function; that function is specific to Azure Functions and App Service code, not Logic App workflow expressions. Option D is wrong because the 'Invoke an HTTP endpoint' action with Application Insights dependency tracking does not automatically retrieve or inject API keys; it only enables telemetry logging of the HTTP call, and the API key would still need to be manually provided and could be exposed in logs.

Practice this question →

Page 1 of 4 · 229 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Connect to and consume Azure services and third-party services questions.

Start 20-question session