Microsoft Azure Developer Associate AZ-204 AZ-204 Questions 751–825 | Page 11/12

751

MCQeasy

You need to execute a PowerShell script every night to clean up unused resources in your Azure subscription. The script should run with a specific service principal identity that has the necessary permissions. You want a serverless solution with minimal management overhead. Which Azure service should you use?

A.Azure Functions with a timer trigger running PowerShell.

B.Azure Automation with a scheduled runbook.

C.Azure Logic Apps with a recurrence trigger running a PowerShell action.

D.Set up a scheduled task on an Azure VM to run the script.

AnswerB

Azure Automation is purpose-built for executing PowerShell scripts (runbooks) on a schedule without managing underlying infrastructure. It natively supports PowerShell, allowing you to upload scripts, define schedules, and use Managed Identities or Run As accounts for secure authentication to Azure resources. This provides a truly serverless and low-management solution ideal for routine administrative tasks like nightly cleanup scripts.

Why this answer

Azure Automation with a scheduled runbook is the correct choice because it is designed specifically for running PowerShell scripts on a recurring schedule using a service principal identity, with built-in support for Azure authentication via managed identities or Run As accounts. This provides a serverless solution with minimal management overhead, as Azure Automation handles the scheduling, execution, and identity management without requiring you to maintain any infrastructure.

Exam trap

The trap here is that candidates often choose Azure Functions (Option A) because it is a popular serverless compute option, but they overlook that Azure Automation is the dedicated service for scheduled PowerShell administration in Azure, with built-in identity management and longer execution time limits.

How to eliminate wrong answers

Option A is wrong because Azure Functions with a timer trigger can run PowerShell, but it is not optimized for long-running administrative scripts (default timeout of 5-10 minutes) and requires more manual setup for service principal authentication and module management compared to Azure Automation. Option C is wrong because Azure Logic Apps with a recurrence trigger can orchestrate workflows but does not natively run PowerShell scripts; it would require an Azure Function or Hybrid Worker to execute PowerShell, adding complexity and defeating the 'minimal management overhead' requirement. Option D is wrong because setting up a scheduled task on an Azure VM is not serverless—it requires provisioning, patching, and managing a VM, which contradicts the 'serverless solution with minimal management overhead' requirement.

Full explanation →

752

MCQmedium

You are deploying a Node.js application to Azure Web Apps for Containers. The application needs to read configuration settings from Azure App Configuration. What is the recommended method to securely connect the app to the configuration store?

A.Store connection string in environment variables.

B.Use Key Vault references in App Settings.

C.Use managed identity.

D.Hardcode the connection string.

AnswerC

Managed identities provide an Azure Active Directory identity for Azure resources, such as an Azure Web App for Containers. This allows the application to authenticate securely to other Azure services, like Azure App Configuration, without requiring any explicit credentials or connection strings to be stored in the application code or configuration. The Azure platform automatically manages the identity's lifecycle and authentication tokens, enabling secure, secret-less access based on assigned Azure RBAC roles.

Why this answer

Using a managed identity allows the Node.js application running in Azure Web Apps for Containers to authenticate to Azure App Configuration without storing any secrets. Managed identities provide an automatically managed service principal in Azure AD, enabling secure, code-free access to the configuration store via Azure AD authentication, which is the recommended approach for production workloads.

Exam trap

The trap here is that candidates often confuse Key Vault references (which are for retrieving secrets from Key Vault) with the method to connect to App Configuration, leading them to choose Option B, but managed identity is the recommended and most secure way to authenticate to App Configuration directly.

How to eliminate wrong answers

Option A is wrong because storing the connection string in environment variables still exposes a secret (the connection string) in the app settings, which can be leaked or misconfigured, and it does not leverage Azure AD authentication. Option B is wrong because Key Vault references in App Settings are used to reference secrets stored in Azure Key Vault, not to directly connect to Azure App Configuration; they solve a different problem (retrieving secrets) and still require a connection string or managed identity for the App Configuration client. Option D is wrong because hardcoding the connection string is a severe security anti-pattern that exposes credentials in source code, violates security best practices, and is never recommended.

Full explanation →

753

Multi-Selectmedium

Which TWO of the following are valid use cases for Azure Queue Storage? (Choose TWO.)

Select 2 answers

A.Building a reliable messaging layer between microservices.

B.Broadcasting messages to multiple subscribers.

C.Storing large JSON documents for later retrieval.

D.Streaming high-volume telemetry data for real-time analytics.

E.Decoupling components of a distributed application for asynchronous processing.

AnswersA, E

Azure Queue Storage offers a robust, asynchronous messaging solution critical for microservice communication. Messages are durable and persist until processed and deleted, ensuring "at-least-once" delivery semantics. This reliability prevents data loss even if a consuming microservice temporarily fails or becomes unavailable, making it ideal for inter-service communication where message integrity is paramount.

Why this answer

Azure Queue Storage provides a reliable, persistent message queue that enables asynchronous communication between microservices. It guarantees at-least-once delivery and supports message visibility timeouts, making it ideal for decoupling components in a distributed architecture.

Exam trap

The trap here is that candidates confuse Azure Queue Storage with pub/sub messaging patterns (like Service Bus Topics) or assume it can handle large payloads or real-time streaming, when it is strictly a point-to-point, durable queue with size and throughput limitations.

Full explanation →

754

MCQhard

You are developing a microservices application deployed on Azure Kubernetes Service (AKS). You need to ensure that service-to-service communication is encrypted using mutual TLS (mTLS) without modifying application code. What should you do?

A.Deploy Azure Service Mesh and enable mTLS.

B.Use Azure Application Gateway Ingress Controller with mTLS.

C.Enable Azure Kubernetes Service (AKS) pod-to-pod encryption.

D.Configure Azure Network Security Groups to enforce encryption.

AnswerA

Deploying an Azure Service Mesh, such as Open Service Mesh (OSM) or Istio on AKS, provides a robust solution for enabling mutual TLS (mTLS) transparently across microservices. A service mesh injects sidecar proxies alongside each application container, which intercept all network traffic. These proxies then handle certificate issuance, rotation, and the establishment of mTLS connections, ensuring all service-to-service communication is encrypted and authenticated without requiring application code changes.

Why this answer

Azure Service Mesh (e.g., Open Service Mesh or Istio-based) provides a transparent infrastructure layer that can automatically inject sidecar proxies into pods and enforce mTLS for all service-to-service communication without requiring any changes to application code. This meets the requirement of encrypting traffic with mutual TLS while keeping the application code untouched.

Exam trap

The trap here is that candidates may confuse ingress-level mTLS (option B) with internal service-to-service mTLS, or assume that AKS has a built-in pod encryption feature (option C) when it does not.

How to eliminate wrong answers

Option B is wrong because Azure Application Gateway Ingress Controller handles ingress traffic from outside the cluster, not internal service-to-service communication, and its mTLS feature applies to client-to-ingress, not pod-to-pod. Option C is wrong because AKS does not have a native 'pod-to-pod encryption' feature; encryption between pods must be implemented via a service mesh or other overlay network. Option D is wrong because Network Security Groups (NSGs) filter traffic based on IP/port rules and cannot enforce encryption or mTLS at the application layer.

Full explanation →

755

MCQeasy

You need to deploy a containerized application to Azure Container Instances (ACI) with a public IP address and DNS name label. The container must restart automatically if it exits unexpectedly. Which configuration should you use?

A.Deploy the container into an Azure Virtual Network.

B.Set restart policy to Never and configure a public IP.

C.Set restart policy to OnFailure and use a private IP address.

D.Set restart policy to Always and assign a DNS name label.

AnswerD

The 'Always' restart policy ensures that the container instance continuously runs, automatically restarting the container whenever it stops, regardless of the exit code. This is crucial for maintaining application availability for long-running services. Assigning a DNS name label to the public IP address provides a user-friendly, resolvable hostname (e.g., myapp.eastus.azurecontainer.io), making the containerized application easily accessible and discoverable from the internet.

Why this answer

Setting the restart policy to Always ensures the container automatically restarts if it exits unexpectedly, which is the required behavior. Assigning a DNS name label to the container group makes it accessible via a public IP address and a fully qualified domain name (FQDN) in the format <dns-name-label>.<region>.azurecontainer.io, meeting the requirement for a public IP address and DNS name label.

Exam trap

Candidates might consider 'OnFailure' for unexpected exits, which is a valid policy for that scenario. However, 'Always' also fulfills the requirement and is correctly paired with the public IP/DNS name label in option D. A common mistake is also assuming a virtual network is required for public IP assignment, when ACI assigns a public IP by default unless configured otherwise.

How to eliminate wrong answers

Option A is wrong because deploying the container into an Azure Virtual Network does not affect the restart policy or the assignment of a public IP address and DNS name label; it only provides network isolation. Option B is wrong because setting the restart policy to Never means the container will not restart automatically if it exits unexpectedly, which directly contradicts the requirement. Option C is wrong because setting the restart policy to OnFailure only restarts the container if it exits with a non-zero exit code, not for all unexpected exits, and using a private IP address does not provide public accessibility or a DNS name label.

Full explanation →

756

Multi-Selectmedium

Which TWO of the following are valid ways to authenticate an Azure function to an Azure SQL database using managed identity?

Select 2 answers

A.Create a service principal and assign it to the function app.

B.Use the function app's default connection string with a username and password.

C.Create a user-assigned managed identity, assign it to the function app, and use its client ID in the connection string.

D.Upload a client certificate to the function app and use it to authenticate.

E.Enable system-assigned managed identity on the function app and set the SQL connection string with 'Authentication=Active Directory Managed Identity'.

AnswersC, E

A user-assigned managed identity is an independent Azure resource that can be explicitly created and then assigned to one or more Azure resources, including a Function App. Once assigned, the Function App can leverage this identity to obtain Azure AD tokens, which are then used to authenticate to other Azure services like Azure SQL Database. Including the client ID of the user-assigned managed identity in the connection string explicitly directs the Function App to use that specific identity for authentication, enabling a secure and credential-free connection.

Why this answer

A user-assigned managed identity can be created, assigned to the function app, and then used in the SQL connection string by specifying the client ID (e.g., 'User ID=<client_id>;Authentication=Active Directory Managed Identity;'). This allows the function to authenticate to Azure SQL without storing credentials. Option E is also correct because enabling a system-assigned managed identity and setting the connection string with 'Authentication=Active Directory Managed Identity' lets the function app authenticate using its own identity, which is automatically managed by Azure.

Exam trap

The trap here is that candidates often confuse service principals (Option A) with managed identities, or think that certificate-based authentication (Option D) is a form of managed identity, when in fact managed identities are specifically Azure AD identities tied to the resource itself without manual credential or certificate management.

Full explanation →

757

MCQeasy

You are deploying an application to Azure App Service that requires a custom startup script to initialize the environment. Where should you place the startup script in the application code?

A.In the 'web.config' file

B.In a 'docker-compose.yml' file

C.In the root of the application code as 'startup.sh'

D.As a startup command in the App Service configuration

AnswerD

Azure App Service provides a dedicated configuration setting to specify the exact command or script that should be executed when the application instance starts. This can be configured through the Azure portal under 'Configuration' -> 'General settings' -> 'Startup Command,' or programmatically via Azure CLI using `az webapp config set --startup-file`. This mechanism allows for executing custom shell scripts (e.g., `./startup.sh`) or direct application commands (e.g., `npm start`, `gunicorn app:app`) to properly initialize the application environment.

Why this answer

Azure App Service allows you to specify a custom startup command or script in the App Service configuration (under 'General settings' or via the Azure CLI with `--startup-file`). This startup command runs before the application starts, enabling you to initialize the environment, run pre-deployment tasks, or set up dependencies. Placing the startup script in the configuration ensures it is executed by the App Service platform, which handles the runtime environment (Windows or Linux) and integrates with the application lifecycle.

Exam trap

The trap here is that candidates assume placing a script file in the application root is sufficient for execution, but Azure App Service requires explicit configuration to designate a startup file or command, as the platform does not automatically scan for or execute arbitrary scripts.

How to eliminate wrong answers

Option A is wrong because the 'web.config' file is used for configuring IIS settings and ASP.NET modules, not for executing custom startup scripts; it cannot run shell commands or scripts. Option B is wrong because 'docker-compose.yml' is used for multi-container Docker applications, but Azure App Service does not natively support Docker Compose; it uses single-container deployments or App Service on Linux with a Dockerfile, not a compose file. Option C is wrong because placing 'startup.sh' in the root of the application code does not automatically cause Azure App Service to execute it; the platform requires explicit configuration to run a startup script, and simply having the file present does not trigger execution.

Full explanation →

758

MCQhard

You are designing a solution that uses Azure File Shares. The application requires low-latency access to files from multiple Azure virtual machines in the same region. The files are accessed frequently and must support SMB protocol. Which storage account type and tier should you recommend?

A.Standard general-purpose v2 with cool tier.

B.Standard general-purpose v2 with transaction-optimized tier.

C.BlobStorage with hot tier.

D.FileStorage (premium file shares).

AnswerD

FileStorage accounts are specifically designed to host premium Azure file shares, which are backed by solid-state drives (SSDs). This dedicated storage account type provides consistently low latency and high performance, making it ideal for demanding enterprise workloads that require high IOPS and throughput. Premium file shares allow for provisioning a specific amount of storage, which directly correlates to guaranteed IOPS and throughput, ensuring predictable performance for critical applications.

Why this answer

Azure premium file shares (FileStorage) provide low-latency, high-performance access using the SMB protocol, which is required for frequently accessed files from multiple VMs in the same region. Standard tiers (cool or transaction-optimized) do not meet the low-latency requirement, and BlobStorage does not support SMB protocol natively.

Exam trap

The trap here is that candidates often confuse the transaction-optimized tier with performance optimization, but it only optimizes for cost per transaction, not latency, while BlobStorage is mistakenly thought to support SMB via NFS or other protocols, which it does not natively.

How to eliminate wrong answers

Option A is wrong because Standard general-purpose v2 with cool tier is designed for infrequently accessed data with higher latency, not for low-latency, frequently accessed files. Option B is wrong because Standard general-purpose v2 with transaction-optimized tier is optimized for high transaction costs, not for low-latency performance, and still uses standard HDD-based storage. Option C is wrong because BlobStorage does not support the SMB protocol; it uses REST APIs or SDKs for access, not SMB, and is not suitable for file share scenarios requiring SMB.

Full explanation →

759

MCQeasy

You need to call a third-party REST API from your Azure Function app. The API requires an API key in the header. Where should you store the API key to keep it secure?

A.Environment variable in the hosting plan

B.Azure Key Vault

C.Connection string in the Function app

D.App settings in the Function app configuration

AnswerB

Azure Key Vault is the recommended and most secure solution for storing secrets like API keys, connection strings, and certificates. It provides hardware security module (HSM)-backed protection, fine-grained access control through Azure RBAC or Key Vault access policies, and comprehensive audit logging, ensuring secrets are encrypted at rest and in transit, and only authorized identities can retrieve them. Azure Functions can integrate with Key Vault using managed identities, eliminating the need to store any secrets directly in the function app configuration.

Why this answer

Azure Key Vault is the correct choice because it provides a centralized, secure store for secrets like API keys, with access control via Azure AD and automatic rotation capabilities. The Function app can securely retrieve the key at runtime using a managed identity, avoiding hardcoding or exposing the secret in configuration files or environment variables.

Exam trap

The trap here is that candidates often confuse 'app settings' or 'environment variables' as secure storage, but Azure explicitly recommends Key Vault for secrets, and the exam tests this distinction by making the other options appear convenient but insecure.

How to eliminate wrong answers

Option A is wrong because environment variables in the hosting plan are not encrypted at rest and can be exposed through portal access or logs, failing to meet security best practices. Option C is wrong because connection strings are designed for database connections, not API keys, and they are stored in plaintext in the Function app configuration unless encrypted by Key Vault references. Option D is wrong because app settings in the Function app configuration are stored as plaintext in the Azure portal and can be viewed by anyone with contributor access, lacking the encryption and access control provided by Key Vault.

Full explanation →

760

MCQeasy

You are processing messages from an Azure Storage queue in a worker role. To handle messages that repeatedly fail, you want to move them to a separate 'poison' queue after 5 delivery attempts. Which property of the received message should you check to determine the number of attempts?

A.MessageId

B.DequeueCount

C.ExpirationTime

D.PopReceipt

AnswerB

The DequeueCount property is incremented by Azure Queue Storage each time a message is successfully retrieved using the GetMessages operation. This count directly reflects the number of times a message has been made visible to a consumer, even if it's subsequently put back into the queue due to processing failure or timeout. It is the primary mechanism for identifying 'poison messages' that repeatedly fail to process, enabling robust error handling strategies like moving them to a dead-letter queue after a predefined threshold.

Why this answer

The DequeueCount property tracks how many times a message has been dequeued from the queue. Each time a worker role retrieves the message but fails to process it (and does not delete it), the message becomes visible again after the visibility timeout expires, incrementing DequeueCount. By checking this property, you can implement a retry policy that moves the message to a poison queue after a threshold (e.g., 5 attempts).

Exam trap

The trap here is that candidates confuse PopReceipt (which changes with each dequeue and is used for deletion) with DequeueCount, assuming a new PopReceipt indicates a new attempt, but PopReceipt does not provide a cumulative count of attempts.

How to eliminate wrong answers

Option A is wrong because MessageId is a unique identifier for the message within the queue and does not change with retries; it cannot indicate delivery attempts. Option C is wrong because ExpirationTime defines when the message will be automatically deleted from the queue, not how many times it has been dequeued. Option D is wrong because PopReceipt is a receipt required to delete or update the message after a successful dequeue; it changes with each dequeue operation but does not track the count of attempts.

Full explanation →

761

MCQhard

You need to reduce costs for an Azure Functions app that runs intermittently. The current Consumption plan bills for execution time. Which change would be MOST cost-effective?

A.Switch to Premium plan with pre-warmed instances

B.Migrate to Flex Consumption plan with higher memory

C.Use an App Service plan with Always On

D.Deploy to Azure Container Instances

AnswerB

Migrating to an Azure Functions Flex Consumption plan with higher memory is an effective strategy for cost reduction. This plan offers a consumption-based model with more granular control over resource allocation, allowing you to optimize memory for specific function needs. By providing sufficient memory, execution times can be significantly reduced, directly lowering the billed duration and overall cost, especially for memory-intensive or CPU-bound functions, while maintaining serverless benefits.

Why this answer

The Flex Consumption plan allows you to configure per-instance memory and concurrency settings, which can reduce costs for intermittent workloads by optimizing resource usage. Unlike the standard Consumption plan, Flex Consumption lets you set higher memory limits without paying for idle time, making it more cost-effective for functions that run sporadically but require more memory when active.

Exam trap

The trap here is that candidates often assume higher memory always increases cost, but in Flex Consumption, higher memory can reduce execution time and overall cost for intermittent workloads, while options like Premium or App Service plans introduce fixed costs that are wasteful for sporadic usage.

How to eliminate wrong answers

Option A is wrong because the Premium plan with pre-warmed instances incurs higher baseline costs due to reserved instances and always-on features, which are not cost-effective for intermittent workloads. Option C is wrong because an App Service plan with Always On keeps the app continuously running, leading to constant billing even when functions are idle, increasing costs. Option D is wrong because Azure Container Instances bill per second of container runtime and require manual scaling or orchestration, which adds complexity and cost for intermittent function execution without the serverless benefits of Azure Functions.

Full explanation →

762

MCQhard

You have an Azure Storage account with cool tier blobs. You need to implement lifecycle management to move blobs to the archive tier after 30 days if they have not been accessed, and delete them after 365 days. Which lifecycle management rule action should you configure?

A.Use a rule with condition 'daysAfterLastAccessTimeGreaterThan' to tier and delete, and enable blob access tracking.

B.Use a rule with condition 'daysAfterLastAccessTimeGreaterThan' to tier and delete.

C.Use a rule with condition 'daysAfterSnapshotCreationGreaterThan' to tier and delete.

D.Use a rule with condition 'daysAfterModificationGreaterThan' to tier after 30 days and delete after 365 days.

AnswerA

Correct. This option includes the condition 'daysAfterLastAccessTimeGreaterThan' which tracks when the blob was last read, and also enables blob access tracking, which is required for that condition to work. This aligns with the requirement to move blobs that have not been accessed.

Why this answer

The requirement specifies 'if they have not been accessed', which requires tracking last access time. Lifecycle management rules support the 'daysAfterLastAccessTimeGreaterThan' condition, but blob access tracking must be enabled for this condition to work. Option A includes both the condition and enabling access tracking, making it the correct choice.

Option D uses 'daysAfterModificationGreaterThan', which tracks last modification time, not access time, so it does not meet the requirement.

Exam trap

The trap is that 'daysAfterModificationGreaterThan' is a common condition, but for access-based rules, you must use 'daysAfterLastAccessTimeGreaterThan' and explicitly enable blob access tracking on the storage account.

How to eliminate wrong answers

Option A is wrong because it requires enabling blob access tracking, which is an additional feature that must be explicitly enabled and incurs extra cost; the question does not specify enabling access tracking. Option B is wrong because 'daysAfterLastAccessTimeGreaterThan' also requires blob access tracking to be enabled, and without it, the condition cannot be evaluated. Option C is wrong because 'daysAfterSnapshotCreationGreaterThan' applies only to blob snapshots, not to base blobs, and the requirement is about base blobs, not snapshots.

Full explanation →

763

MCQmedium

You are developing an application that runs on Azure App Service. The application needs to store session state. The session state must be shared across multiple instances of the app and survive restarts. You need to choose a session state provider. What should you use?

A.Use Azure Table Storage for session state.

B.Use a SQL Database to store session data.

C.Use the in-memory session state provider.

D.Use Azure Redis Cache as a session state provider.

AnswerD

Azure Redis Cache is an in-memory data store based on the open-source Redis project, specifically designed for high-performance caching and session state management. It offers extremely low-latency access, supports data persistence (optional), and provides built-in features like automatic expiration (Time-To-Live) for session keys. Its distributed nature allows session data to be shared across multiple application instances, ensuring scalability and high availability, making it an ideal choice for robust and performant web applications.

Why this answer

Azure Redis Cache provides a distributed, in-memory data store that can be shared across multiple instances of an App Service application and persists data through restarts. It is the recommended session state provider for Azure App Service when high availability and scalability are required, as it stores session data externally from the application's memory.

Exam trap

The trap here is that candidates often choose the in-memory provider (Option C) because it is the simplest default in ASP.NET, forgetting that it fails the cross-instance sharing and restart survival requirements explicitly stated in the question.

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 does not provide the low-latency, in-memory access required for session state; it also lacks built-in expiration and eviction policies for session data. Option B is wrong because SQL Database, while persistent and shareable, introduces higher latency and overhead for session state operations compared to an in-memory cache, and is not optimized for the high-throughput, short-lived nature of session data. Option C is wrong because the in-memory session state provider stores session data within the memory of a single application instance, so it is not shared across multiple instances and is lost when the app restarts or scales out.

Full explanation →

764

MCQeasy

Refer to the exhibit. You run the Azure CLI command to store a secret in Key Vault. Later, you run 'az keyvault secret show --vault-name myvault --name MySecret'. What will be displayed?

A.The secret's metadata only, without the value.

B.The secret's metadata with the value masked as '*****'.

C.The secret's metadata and the value 'P@ssw0rd123'.

D.An error because you cannot retrieve a secret after it is set.

AnswerC

The `az keyvault secret show` command correctly retrieves the full secret object, encompassing both its comprehensive metadata and the actual plaintext value, 'P@ssw0rd123'. This functionality is fundamental for applications and administrators needing to access the secret's content for operational purposes. The command's output provides all necessary details, including the secret's attributes and its sensitive value, as intended for authorized retrieval.

Why this answer

The `az keyvault secret show` command retrieves the secret's metadata along with its value in plaintext. When you store a secret using `az keyvault secret set`, the value is stored securely, and the `show` command returns the full secret object, including the `value` field, as demonstrated in the exhibit where the stored value is 'P@ssw0rd123'.

Exam trap

The trap here is that candidates may confuse the Azure CLI's `show` command with the Azure Portal's secret display, which masks the value by default, leading them to incorrectly assume the CLI also masks the output.

How to eliminate wrong answers

Option A is wrong because `az keyvault secret show` returns both metadata and the secret value, not just metadata. Option B is wrong because the Azure CLI does not mask the secret value with asterisks; it returns the actual value in plaintext (though the output may be truncated in the console, the full value is accessible). Option D is wrong because there is no restriction on retrieving a secret after it is set; the `show` command is specifically designed for retrieval, and secrets remain accessible until deleted or their expiration date passes.

Full explanation →

765

MCQhard

You are deploying a Java application to Azure App Service on Linux. The application requires a specific JDK version not available in the built-in stack. You need to provide the JDK without creating a custom container. What should you do?

A.Mount an Azure Files share containing the JDK

B.Use the Azure App Service Windows stack with a custom JDK

C.Use a startup script to download and set JAVA_HOME

D.Create a custom Docker container and deploy to App Service

AnswerC

Azure App Service on Linux allows you to specify a custom startup command or script that executes before your application starts. This script provides a robust mechanism to download a specific JDK version (e.g., from a trusted URL or Azure Blob Storage), install it into the container's file system, and then correctly configure critical environment variables such as JAVA_HOME and PATH. This approach offers significant flexibility to use a precise JDK version not pre-installed on the base image, ensuring application compatibility without the overhead of a full custom Docker image.

Why this answer

Azure App Service on Linux allows you to use a startup script to download a custom JDK and set the JAVA_HOME environment variable before the application starts. This approach avoids the need for a custom container while providing the specific JDK version required by the application.

Exam trap

The trap here is that candidates may think mounting a file share (Option A) is the simplest way to provide custom binaries, but they overlook that App Service on Linux does not support mounting Azure Files for executable files, and the startup script approach is the documented method for custom runtimes.

How to eliminate wrong answers

Option A is wrong because mounting an Azure Files share containing the JDK would require the JDK to be accessible at runtime, but App Service on Linux does not support mounting Azure Files shares for custom executables in the same way as Windows; the JDK must be installed in the container's file system. Option B is wrong because the question specifies deploying to Azure App Service on Linux, and using the Windows stack would change the underlying OS, which is not allowed per the requirement. Option D is wrong because creating a custom Docker container is unnecessary and contradicts the requirement to avoid a custom container; the startup script approach achieves the same result without containerization overhead.

Full explanation →

766

MCQmedium

You are deploying a containerized application to Azure Container Instances. The application requires writing temporary files to a local filesystem. You need to ensure that the files persist if the container restarts. What should you do?

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

B.Use the container's writable layer to store files.

C.Use Azure Blob Storage and mount it as a volume.

D.Configure a Docker volume in the container image.

AnswerA

Mounting an Azure Files share as a volume within an Azure Container Instance (ACI) container group provides a robust solution for persistent and shared storage. This approach leverages the Server Message Block (SMB) or Network File System (NFS) protocol to connect the container to a managed file share, ensuring that data persists across container restarts and can be accessed by multiple containers within the same group or even different container groups. It is the recommended method for stateful applications requiring durable storage in ACI.

Why this answer

Azure Container Instances (ACI) supports mounting Azure Files shares as volumes. When a container restarts, its writable layer is ephemeral and lost, but an Azure Files share persists independently. By mounting the share, temporary files written to the mount point survive container restarts, meeting the persistence requirement.

Exam trap

The trap here is that candidates confuse Azure Blob Storage (object storage) with Azure Files (SMB file share) and assume both can be mounted as volumes in ACI, but only Azure Files is supported for volume mounts in container groups.

How to eliminate wrong answers

Option B is wrong because the container's writable layer is ephemeral and is destroyed when the container restarts, so files stored there do not persist. Option C is wrong because Azure Blob Storage cannot be mounted as a volume in ACI; only Azure Files (SMB) shares are supported for volume mounts. Option D is wrong because Docker volumes are configured at the container runtime level, not in the container image, and ACI does not support Docker volumes; it uses its own volume mounting mechanism.

Full explanation →

767

Multi-Selecthard

A report export service in Azure App Service must safely access Key Vault secrets without connection strings in configuration. Which two steps are required?

Select 2 answers

A.Enable anonymous access on the vault

B.Store the Key Vault access key in app settings

C.Grant the identity permission to read the required secrets

D.Enable a managed identity for the web app

AnswersC, D

After an identity (such as a managed identity) is established for the Azure App Service, it must be explicitly authorized to perform specific operations within Azure Key Vault. This authorization is achieved by assigning appropriate permissions, typically through Azure Role-Based Access Control (RBAC) roles like "Key Vault Secrets User" or by configuring an access policy directly on the Key Vault, granting "Get" and "List" secret permissions to the service principal. This ensures the principle of least privilege is followed.

Why this answer

Granting the managed identity permission to read secrets in Key Vault via Azure RBAC or access policies ensures that the App Service can authenticate without storing any secrets in configuration. This follows the principle of least privilege and eliminates the risk of credential leakage from app settings or connection strings.

Exam trap

The trap here is that candidates often think storing the Key Vault URI or a reference in app settings is sufficient, but the question explicitly requires 'without connection strings in configuration,' so the correct path is to use managed identity plus granting permissions, not storing any key material.

Full explanation →

768

MCQhard

You are reviewing an ARM template that deploys a network security group (NSG) for a web application. The exhibit shows the security rules. The web application runs on port 443. You need to ensure that HTTPS traffic from the internet can reach the web servers. What is the issue with the current configuration?

A.The SSH rule is allowing SSH from the internet, which is a security risk.

B.The SSH rule should have a higher priority (lower number) to ensure SSH access.

C.The DenyAll rule should have a lower priority (higher number) to allow more specific rules.

D.There is no rule to allow HTTPS traffic (port 443) from the internet.

AnswerD

For an application to be accessible via HTTPS from the internet, a specific Network Security Group rule must exist that explicitly permits inbound traffic on destination port 443 (HTTPS) from a source of 'Internet' or `*`. Without such an explicit 'Allow' rule, any incoming HTTPS requests will inevitably be blocked by the implicit 'DenyAllInbound' rule or an explicit, higher-priority 'DenyAll' rule. This omission prevents critical web traffic from reaching the application, highlighting a significant functional gap.

Why this answer

The ARM template's security rules do not include an inbound rule that allows HTTPS traffic (TCP port 443) from the internet. Without such a rule, the default DenyAll inbound rule will block all HTTPS requests, preventing the web application from being accessible over the internet. NSG rules are evaluated in priority order, and if no explicit allow rule exists for port 443, traffic is denied.

Exam trap

The trap here is that candidates may focus on the SSH rule's security implications or priority ordering, overlooking the fundamental absence of an HTTPS allow rule, which is the direct cause of the web application being unreachable.

How to eliminate wrong answers

Option A is wrong because while allowing SSH from the internet is indeed a security risk, the question specifically asks about ensuring HTTPS traffic reaches the web servers, not about SSH security. Option B is wrong because the SSH rule's priority is irrelevant to the HTTPS issue; the problem is the absence of an HTTPS allow rule, not the priority of the SSH rule. Option C is wrong because the DenyAll rule already has the lowest priority (highest number) by convention, and lowering its priority further would not create an allow rule for HTTPS; the core issue is the missing allow rule for port 443.

Full explanation →

769

MCQeasy

A company stores archival data in Azure Blob Storage. The data is accessed only a few times per year, and retrieval can take up to 15 hours. Which blob access tier minimizes storage costs while meeting these requirements?

A.Hot tier

B.Cool tier

C.Archive tier

D.Premium tier

AnswerC

Archive tier is the lowest-cost blob tier, designed for data rarely accessed with retrieval latency measured in hours. The stated few-times-per-year access and tolerance of up to 15 hours retrieval match its rehydration model exactly.

Why this answer

The Archive tier is the correct choice because it is designed for data that is rarely accessed (a few times per year) and has a retrieval latency of up to 15 hours, which matches the requirement. It offers the lowest storage cost among Azure Blob Storage tiers, making it optimal for long-term archival data where infrequent access and delayed retrieval are acceptable.

Exam trap

The trap here is that candidates often confuse the Cool tier's 'infrequent access' with 'archival access,' failing to recognize that Cool tier still provides millisecond retrieval and higher storage costs, while the Archive tier alone meets the 15-hour retrieval requirement and minimizes storage costs.

How to eliminate wrong answers

Option A is wrong because the Hot tier is optimized for frequent access (multiple times per day) and has higher storage costs, making it unsuitable for archival data accessed only a few times per year. Option B is wrong because the Cool tier is intended for data accessed infrequently (about once per month) and has a retrieval latency of milliseconds, not up to 15 hours, and its storage cost is higher than the Archive tier. Option D is wrong because the Premium tier is designed for low-latency, high-performance scenarios (e.g., sub-10ms access) and has the highest storage cost, which is inappropriate for archival data with a 15-hour retrieval tolerance.

Full explanation →

770

MCQhard

A workflow must process 500 customer records in parallel and then aggregate all results into a single summary report. The team wants to use Azure Durable Functions so the orchestration state is durable and the solution can resume after a Function App restart. Which Durable Functions pattern matches this requirement?

A.Fan-out/fan-in: start 500 activity functions in parallel with Task.WhenAll inside the orchestrator, then aggregate all returned results

B.Function chaining: call each activity function sequentially, collecting each result before starting the next

C.Async HTTP API: start the workflow with an HTTP trigger, return a 202 with a status URL, and have the client poll for completion

D.Monitor: use a Durable timer loop that checks a status table every 60 seconds until all records are marked processed

AnswerA

Task.WhenAll fires all 500 activities simultaneously (constrained by the configured max concurrency). The orchestrator yields at the await statement, checkpointing its state. When all activities complete, the orchestrator resumes and aggregates results. Durable state management handles host restarts transparently.

Why this answer

The fan-out/fan-in pattern in Durable Functions is specifically designed to execute multiple activity functions in parallel using Task.WhenAll inside an orchestrator, then aggregate their results. This matches the requirement to process 500 customer records concurrently and produce a single summary report, while the orchestration state is durably persisted and can resume after a Function App restart.

Exam trap

The trap here is that candidates may confuse the fan-out/fan-in pattern with the Async HTTP API pattern, thinking that the HTTP trigger and status polling are required for parallel processing, but the key distinction is that fan-out/fan-in handles the parallel execution and aggregation within the orchestrator itself, not via external polling.

How to eliminate wrong answers

Option B is wrong because function chaining executes activity functions sequentially, which would not process 500 records in parallel and would be inefficient for this workload. Option C is wrong because the Async HTTP API pattern is about starting a workflow and providing a status endpoint for polling, not about parallel execution and aggregation of results. Option D is wrong because the Monitor pattern uses a timer loop to check a status table periodically, which is designed for polling external state changes, not for parallel processing and aggregation of customer records.

Full explanation →

771

MCQmedium

You are developing a .NET Core application that stores user profile images in Azure Blob Storage. The images are accessed frequently in the first week after upload, then rarely afterwards. You need to minimize storage costs while maintaining immediate access for the first week. What should you do?

A.Manually change the blob tier to Cool after 7 days using a scheduled job.

B.Set the default access tier of the storage account to Cool.

C.Store blobs in Archive tier and use rehydration when needed.

D.Implement a lifecycle management policy to move blobs to Cool tier 7 days after creation.

AnswerD

Cool tier retains millisecond access while costing less than Hot, so immediate retrieval during the first week is preserved. The lifecycle policy automatically transitions blobs after seven days, directly satisfying the requirement to minimise cost once access becomes infrequent.

Why this answer

Azure Blob Storage lifecycle management policies allow you to automatically transition blobs to a cooler tier (Cool) after a specified number of days, minimizing storage costs while maintaining immediate access for the first week. This policy is applied at the storage account level and requires no manual intervention or scheduled jobs, ensuring that blobs remain in the Hot tier for the first 7 days (frequent access) and then move to Cool tier (lower cost, still immediate access).

Exam trap

The trap here is that candidates often confuse 'default access tier' (which applies to all new blobs immediately) with 'lifecycle management' (which applies rules after creation), leading them to incorrectly choose Option B or A, while overlooking the automated, policy-driven approach in Option D.

How to eliminate wrong answers

Option A is wrong because manually changing the blob tier using a scheduled job introduces operational overhead and potential for errors, whereas Azure provides a built-in, automated lifecycle management feature that is more reliable and cost-effective. Option B is wrong because setting the default access tier of the storage account to Cool would place all new blobs in the Cool tier immediately, violating the requirement for immediate access during the first week (Cool tier has slightly higher latency and lower throughput compared to Hot tier). Option C is wrong because storing blobs in the Archive tier requires rehydration (which can take up to 15 hours) to access them, making it unsuitable for the requirement of immediate access within the first week; Archive is intended for rarely accessed data with flexible retrieval times.

Full explanation →

772

MCQhard

You are designing a disaster recovery plan for a storage account containing critical data. The storage account is in the West US region. You need to ensure that if West US becomes unavailable, read access to the data is still possible with minimal latency. The data must be replicated asynchronously. Which replication strategy should you choose?

A.Read-access geo-zone-redundant storage (RA-GZRS)

B.Locally redundant storage (LRS)

C.Read-access geo-redundant storage (RA-GRS)

D.Geo-redundant storage (GRS)

AnswerC

Read-access geo-redundant storage (RA-GRS) asynchronously replicates your data to a secondary region hundreds of miles away, maintaining three copies in each region. Crucially, RA-GRS provides a separate read-only endpoint to the secondary region, allowing applications to directly read data from the secondary location even if the primary region becomes unavailable. This capability ensures high availability for read operations with minimal latency during a primary region outage, without requiring a manual failover.

Why this answer

RA-GRS (Read-access geo-redundant storage) is the correct choice because it provides asynchronous replication to a secondary region (paired region) and enables read access to the secondary endpoint even if the primary region fails. This meets the requirement for minimal latency read access during a West US outage, as RA-GRS allows reading from the secondary region while data is asynchronously replicated.

Exam trap

The trap here is that candidates often confuse GRS with RA-GRS, overlooking that GRS does not provide read access to the secondary region until a failover is initiated, which fails the 'read access with minimal latency' requirement.

How to eliminate wrong answers

Option A (RA-GZRS) is wrong because it uses zone-redundant storage within the primary region, which does not provide a secondary region for failover; it only protects against zone failures, not regional outages. Option B (LRS) is wrong because it replicates data only within a single data center, offering no protection against a regional disaster like West US becoming unavailable. Option D (GRS) is wrong because while it replicates asynchronously to a secondary region, it does not enable read access to the secondary endpoint during a primary region outage; read access is only available after a failover, which introduces latency and manual intervention.

Full explanation →

773

MCQhard

A developer accidentally deleted a secret from Azure Key Vault. Soft-delete is enabled with a retention period of 90 days. After 60 days, you attempt to recover the secret. What should you do?

A.Run the Azure CLI command: az keyvault secret recover

B.Enable purge protection on the Key Vault first, then recover the secret.

C.Recover is not possible because the retention period of 90 days has not elapsed.

D.Run the Azure CLI command: az keyvault secret undelete

AnswerA

Azure Key Vault's soft-delete feature automatically retains deleted secrets for a configurable period, typically 90 days. During this retention window, the secret transitions to a soft-deleted state, not permanently removed from the Key Vault. The `az keyvault secret recover` command is specifically designed to restore a soft-deleted secret to an active state, making it accessible again, provided the retention period has not yet expired. This command directly addresses the scenario of an accidentally deleted secret.

Why this answer

When soft-delete is enabled on Azure Key Vault, deleted secrets are retained for the specified retention period (90 days in this case). Since only 60 days have passed, the secret is still in a soft-deleted state and can be recovered using the `az keyvault secret recover` command, which restores the secret to an active state.

Exam trap

The trap here is that candidates may confuse the retention period with a mandatory waiting period before recovery, or mistakenly think that purge protection must be enabled first, when in fact recovery is available immediately after deletion as long as soft-delete is enabled.

How to eliminate wrong answers

Option B is wrong because purge protection is not required to recover a soft-deleted secret; it only prevents permanent deletion before the retention period ends. Option C is wrong because the retention period defines the maximum time the secret is kept before being purged, not a waiting period before recovery; recovery is possible at any point during the retention period. Option D is wrong because `az keyvault secret undelete` is not a valid Azure CLI command; the correct command is `az keyvault secret recover`.

Full explanation →

774

MCQhard

You are designing a solution that stores large media files (up to 5 GB each) in Azure Blob Storage. The application must support concurrent uploads with the ability to pause and resume. You need to ensure efficient use of network bandwidth and provide progress reporting. Which approach should you use?

A.Use AzCopy with the --resume parameter.

B.Use Page blobs with 512-byte pages.

C.Use the Azure Storage SDK to upload blobs in blocks, and implement pause/resume logic using block IDs.

D.Use Append blobs and append data in chunks.

AnswerC

The Azure Storage SDK, when used with Block blobs, provides the most suitable mechanism for uploading large media files with pause/resume functionality. Block blobs allow files to be broken into smaller, independently uploaded blocks, each identified by a unique block ID. The SDK enables uploading these blocks concurrently, and by tracking which blocks have been successfully committed, an application can pause an upload and later resume by only re-uploading the uncommitted or missing blocks, ensuring data integrity and efficiency.

Why this answer

Azure Blob Storage supports block blobs, which allow you to upload large files in independent blocks. By using the Azure Storage SDK, you can assign unique block IDs to each block, enabling pause/resume by tracking which block IDs have been committed. This approach also provides fine-grained progress reporting per block and efficient network bandwidth usage through parallel uploads.

Exam trap

The trap here is that candidates confuse AzCopy's resume capability with programmatic pause/resume, or assume Append blobs are suitable for large file uploads because they support chunking, but they lack the block-level control needed for concurrent uploads and progress tracking.

How to eliminate wrong answers

Option A is wrong because AzCopy is a command-line tool for bulk data transfer, not designed for programmatic pause/resume within an application; the --resume parameter works for interrupted AzCopy jobs, not for concurrent uploads with custom progress reporting. Option B is wrong because Page blobs are optimized for random read/write access (e.g., VHDs) with 512-byte pages, not for large media files requiring concurrent uploads and pause/resume; they lack block-level management. Option D is wrong because Append blobs are designed for append-only operations (e.g., logging), not for uploading large files with pause/resume; they do not support block-level parallelism or independent block IDs.

Full explanation →

775

MCQmedium

Refer to the exhibit. You run this KQL query in Azure Monitor Logs. What does the timechart display?

A.Multiple lines, one for each result code, showing request count over time

B.A single line of total requests over time

C.Total requests per 5 minutes

D.Requests grouped by result code only

AnswerA

The `summarize count() by bin(timestamp, 5m), resultCode` clause explicitly groups the request counts by both 5-minute time intervals and distinct `resultCode` values. Consequently, the `render timechart` operator will generate a separate line for each unique `resultCode` encountered within the dataset, plotting its count over the binned time periods. This provides a clear visualization of how the volume of requests for each specific result code changes over time.

Why this answer

The KQL query uses `summarize count() by ResultCode, bin(TimeGenerated, 5m)` which groups requests by both `ResultCode` and 5-minute time bins. When rendered with `render timechart`, each distinct `ResultCode` value produces a separate series (line) on the chart, showing the request count over time for that result code. This is why multiple lines appear, one per result code.

Exam trap

The trap here is that candidates often overlook the `by ResultCode` clause and assume the query simply counts all requests over time, leading them to choose a single-line option (B or C) instead of recognizing that each distinct result code generates its own series.

How to eliminate wrong answers

Option B is wrong because the query does not summarize total requests; it groups by `ResultCode`, so the timechart shows separate lines per result code, not a single aggregated line. Option C is wrong because while the query bins time into 5-minute intervals, the timechart displays multiple lines (one per result code) rather than a single line of total requests per 5 minutes. Option D is wrong because the query includes a time bin (`bin(TimeGenerated, 5m)`) and renders a timechart, which shows trends over time, not just a static grouping by result code.

Full explanation →

776

MCQmedium

You have an Azure Web App that uses Azure SQL Database. You need to securely connect to the database using Managed Identity. Which connection string setting should you use?

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

B.Server=tcp:myserver.database.windows.net;Database=mydb;Integrated Security=True;

C.Server=tcp:myserver.database.windows.net;Database=mydb;Authentication=Active Directory Password;User Id=myuser@domain.com;Password=...;

D.Server=tcp:myserver.database.windows.net;Database=mydb;Authentication=Active Directory Managed Identity;User Id=myapp;

AnswerD

This is the correct and recommended connection string for an Azure Web App to connect to Azure SQL Database using a managed identity. The `Authentication=Active Directory Managed Identity` parameter instructs the client library to automatically acquire an access token for the web app's assigned managed identity. This eliminates the need for any secrets in the connection string, enhancing security and simplifying credential management.

Why this answer

It uses the 'Authentication=Active Directory Managed Identity' keyword, which tells the SQL client to acquire an access token from Azure AD via the managed identity endpoint. The 'User Id' is set to the name of the managed identity (the app's system-assigned or user-assigned identity), and no password is needed because the token is obtained automatically. This enables a passwordless, secure connection to Azure SQL Database without storing credentials.

Exam trap

The trap here is that candidates often confuse 'Integrated Security=True' (Windows auth) with Azure AD Managed Identity, or they think a password-based Azure AD option (like Active Directory Password) is sufficient, missing the key requirement of a passwordless, identity-based connection.

How to eliminate wrong answers

Option A is wrong because it uses a SQL admin username and password, which requires storing secrets and does not leverage Managed Identity at all. Option B is wrong because 'Integrated Security=True' is a Windows authentication mechanism for on-premises Active Directory and does not work with Azure SQL Database or Azure AD Managed Identity. Option C is wrong because 'Authentication=Active Directory Password' still requires a password and a user principal name, which defeats the purpose of using a managed identity and introduces credential management overhead.

Full explanation →

777

MCQhard

A financial services company uses Azure Container Instances (ACI) to run batch processing jobs. Each job processes sensitive financial data and must use a custom container image stored in Azure Container Registry (ACR). The security requirements are: the ACI container must authenticate to ACR using a managed identity, the container must run as a non-root user, and all secrets must be injected via environment variables from Azure Key Vault using the managed identity. The ACI instance must also be deployed into a virtual network (VNet) to restrict network access. What configuration should you use?

A.Create a system-assigned managed identity for ACI, assign AcrPull role to the identity, and grant it Key Vault access. Deploy ACI with VNet integration.

B.Create a user-assigned managed identity, assign it to both ACI and ACR (with AcrPull role), grant it Key Vault access, and deploy ACI with the identity and VNet integration.

C.Enable ACR admin account, use admin credentials in ACI, and store secrets in Key Vault with a system-assigned managed identity for ACI.

D.Create a service principal, assign AcrPull role and Key Vault access, store the service principal secret in Key Vault, and configure ACI to use the service principal.

AnswerB

Correct. A user-assigned managed identity provides a persistent identity that can be pre-created, assigned to the ACI container group, and granted AcrPull on ACR and appropriate permissions on Key Vault. This fulfills all security requirements: managed identity authentication to ACR, non-root execution (configured separately), secret injection from Key Vault, and VNet integration.

Why this answer

Using a user-assigned managed identity provides a persistent identity that can be assigned to both Azure Container Instances (ACI) and granted access to Azure Container Registry (ACR) and Azure Key Vault. This satisfies all security requirements: authentication to ACR via managed identity, non-root user execution (configured separately), and secret injection from Key Vault. VNet integration restricts network access.

Option A is incorrect because a system-assigned managed identity is tied to the ACI lifecycle and cannot be shared across resources; while you can assign permissions to that identity on ACR, it does not provide the same level of control and persistence as a user-assigned identity. Option C is incorrect because using admin credentials for ACR is not secure and defeats the purpose of managed identities. Option D is incorrect because a service principal requires managing credentials, introducing security risks and additional overhead.

Full explanation →

778

MCQmedium

Refer to the exhibit. You are configuring Azure Monitor autoscale for a virtual machine scale set using the above JSON metric configuration. The autoscale rule is supposed to scale out when average memory usage exceeds 80%. However, autoscale is not triggering even when memory usage is consistently above 90%. What is the most likely cause?

A.The aggregation interval is too long; it should be set to 1 minute.

B.The metric name is incorrect; it should be 'Percentage Memory'.

C.The aggregation type should be 'Maximum' instead of 'Average'.

D.The autoscale rule condition is not configured to use this metric.

AnswerD

The exhibit might demonstrate the successful definition or collection of a custom metric, but this alone does not automatically link it to an autoscale action. For Azure Autoscale to react to any metric, whether platform or custom, a specific autoscale rule must be explicitly configured within an autoscale setting. This rule must reference the exact metric name, its aggregation type, time grain, operator, and a threshold to define the conditions under which scaling actions should occur.

Why this answer

The exhibit shows a metric configuration, but the autoscale rule itself must explicitly reference that metric in its condition. Without a rule condition that uses this metric, autoscale will not evaluate it, regardless of how the metric is configured. The JSON snippet only defines the metric source, not the scaling rule logic.

Exam trap

The trap here is that candidates assume defining a metric in the configuration automatically creates a scaling rule, but Azure requires an explicit rule condition to link the metric to a scale action.

How to eliminate wrong answers

Option A is wrong because the aggregation interval (e.g., 5 minutes) is not inherently too long; autoscale uses the configured duration to evaluate the metric, and a longer interval can still trigger if the threshold is exceeded consistently. Option B is wrong because the metric name 'Memory Percentage' is correct for Azure Monitor; 'Percentage Memory' is not a valid metric name. Option C is wrong because changing the aggregation type to 'Maximum' would make the rule more sensitive to spikes, not fix the issue of the rule not triggering at all; the problem is that the rule is not configured to use this metric.

Full explanation →

779

MCQhard

A company uses Azure SQL Database and needs to encrypt sensitive columns (e.g., credit card numbers) at rest and in transit, with the ability to allow specific applications to decrypt. They want to manage encryption keys centrally in Azure Key Vault and avoid managing certificates. Which technology should they use?

A.Always Encrypted with column master key in Azure Key Vault.

B.Transparent Data Encryption (TDE) with Azure Key Vault.

C.Dynamic Data Masking (DDM) with Azure Key Vault.

D.Row-Level Security (RLS) with Azure Key Vault.

AnswerA

Always Encrypted is a client-side encryption technology designed to protect sensitive data, ensuring it is encrypted before leaving the client application and remains encrypted while stored in the database. It uses column encryption keys, protected by a column master key stored securely in Azure Key Vault, to encrypt specific database columns. This approach ensures that sensitive data is never exposed in plaintext to the SQL Database engine or privileged users like database administrators, only being decrypted by authorized client applications.

Why this answer

Always Encrypted with a column master key stored in Azure Key Vault is the correct choice because it encrypts sensitive columns (like credit card numbers) at rest and in transit, ensuring data remains encrypted throughout the entire pipeline, including during query processing. The column master key in Azure Key Vault allows centralized key management without handling certificates, and only applications with access to the corresponding column encryption key can decrypt the data, meeting the requirement for application-specific decryption.

Exam trap

The trap here is that candidates confuse Transparent Data Encryption (TDE) with column-level encryption, assuming TDE's integration with Azure Key Vault provides the same granular control and in-transit protection as Always Encrypted, but TDE only protects data at rest and does not support client-side decryption control.

How to eliminate wrong answers

Option B (TDE with Azure Key Vault) is wrong because TDE encrypts the entire database at rest but does not protect data in transit or allow column-level granularity; it also does not enable application-specific decryption control. Option C (Dynamic Data Masking with Azure Key Vault) is wrong because DDM only obfuscates data at query results for unauthorized users, does not encrypt data at rest or in transit, and does not use Azure Key Vault for key management. Option D (Row-Level Security with Azure Key Vault) is wrong because RLS restricts row access based on user predicates but does not encrypt data or protect it in transit, and it does not involve Azure Key Vault for key management.

Full explanation →

780

MCQmedium

Your company is developing a real-time dashboard that displays live metrics from IoT devices. The backend processes device data using Azure Functions with an Event Hubs trigger. The processed data is stored in Azure Cosmos DB. You need to ensure that the system can handle a sudden increase in device data without losing messages or overloading Cosmos DB. The solution must minimize latency and cost. What should you do?

A.Implement a buffer using Azure Blob storage: the Event Hubs triggered function writes raw data to blobs, and a separate timer-triggered function batches and writes to Cosmos DB at a controlled rate.

B.Configure the Event Hubs trigger to use a checkpointing strategy with a larger batch size to reduce the number of function invocations.

C.Use Azure Stream Analytics to process the Event Hubs data and write directly to Cosmos DB.

D.Increase the provisioned throughput (RU/s) on the Cosmos DB container to handle peak loads.

AnswerA

This strategy effectively decouples the high-ingestion rate of Event Hubs from the potentially lower write capacity of Cosmos DB. The Event Hubs triggered function rapidly writes raw, unbatched data to inexpensive Azure Blob storage, acting as a temporary buffer. A separate timer-triggered function then reads these blobs, aggregates data into larger batches, and writes them to Cosmos DB at a controlled, sustainable rate, preventing throttling and optimizing RU/s consumption. This approach ensures data durability and cost-efficiency by leveraging Blob storage for buffering and batching writes to Cosmos DB.

Why this answer

It decouples the ingestion rate from the write rate to Cosmos DB. By buffering raw data in Azure Blob storage and using a timer-triggered function to batch-write at a controlled rate, the system can absorb sudden spikes in device data without overwhelming Cosmos DB or losing messages. This approach minimizes latency by keeping the Event Hubs trigger processing fast (writing to blob) and reduces cost by avoiding the need to over-provision RU/s on Cosmos DB.

Exam trap

The trap here is that candidates often assume increasing throughput or batch size is the simplest solution, but the exam tests the understanding that decoupling ingestion from processing with a buffer is the correct way to handle sudden load spikes while minimizing cost and latency.

How to eliminate wrong answers

Option B is wrong because increasing the batch size in the Event Hubs trigger does not prevent Cosmos DB from being overloaded; it only reduces the number of function invocations but still writes the same volume of data per unit time, and larger batches can increase latency and risk of timeouts. Option C is wrong because Azure Stream Analytics writes directly to Cosmos DB without a built-in rate-limiting mechanism, so a sudden surge in data can still overwhelm the database or cause throttling, and it adds ongoing cost for the Stream Analytics job. Option D is wrong because simply increasing provisioned throughput (RU/s) on Cosmos DB addresses the symptom (throttling) but not the root cause (spiky load), leading to higher cost during normal operation and still risking message loss if the spike exceeds the provisioned RU/s.

Full explanation →

781

MCQhard

You are developing an application that stores sensitive user data in Azure Table Storage. You need to ensure that data is encrypted at rest and that only authorized users can access it. What should you implement?

A.Apply Azure Information Protection labels to the storage account.

B.Enable Azure Storage Service Encryption (SSE) and use Microsoft Entra ID for authentication.

C.Implement client-side encryption using the Azure Storage SDK and manage keys via Azure Key Vault.

D.Use shared access signatures (SAS) with a stored access policy to limit access to the data.

AnswerB

Enabling Azure Storage Service Encryption (SSE) ensures that all data written to Azure Storage is automatically encrypted at rest using Microsoft-managed keys or customer-managed keys via Azure Key Vault. Coupled with Microsoft Entra ID for authentication, this provides robust identity-based access control (RBAC) to the storage account and its contents. This combination offers a secure, scalable, and fully managed solution for protecting sensitive user data.

Why this answer

Azure Storage Service Encryption (SSE) automatically encrypts data at rest for Azure Table Storage using 256-bit AES encryption. By combining SSE with Microsoft Entra ID (formerly Azure AD) for authentication, you ensure both encryption at rest and role-based access control, meeting the requirement for authorized access without managing keys or encryption logic client-side.

Exam trap

The trap here is that candidates often confuse client-side encryption (Option C) as the only way to achieve encryption at rest, overlooking that Azure Storage Service Encryption (SSE) provides automatic, transparent server-side encryption without any code changes or key management burden.

How to eliminate wrong answers

Option A is wrong because Azure Information Protection is a classification and labeling service for documents and emails, not a mechanism for encrypting Azure Storage data at rest or controlling access to storage tables. Option C is wrong because client-side encryption, while valid for encrypting data before storage, introduces key management overhead and is not the simplest or most recommended approach for at-rest encryption in Azure Table Storage; SSE handles this automatically. Option D is wrong because shared access signatures (SAS) provide delegated access to storage resources but do not encrypt data at rest; they only control access at the request level and do not enforce encryption.

Full explanation →

782

MCQmedium

You manage a web application hosted on Azure App Service. You need to monitor the application's availability from multiple geographic locations. The test should check that the homepage loads successfully and returns HTTP 200 within 5 seconds. You want to receive an alert if the test fails from any location. Which type of Application Insights test should you create?

A.Multi-step web test

B.URL ping test

C.Custom availability test using TrackAvailability

D.Continuous export test

AnswerB

A URL ping test, provided by Azure Monitor Application Insights, is specifically designed to check the availability and responsiveness of a single URL from multiple global points of presence. It periodically sends a simple GET request to the specified endpoint, monitoring HTTP response codes, DNS resolution, SSL handshake, and overall response time. This perfectly matches the requirement for a simple, external availability check with alerting capabilities.

Why this answer

The URL ping test is the correct choice because it is a simple, single-URL availability test that checks whether a specific endpoint (the homepage) returns HTTP 200 within a specified timeout (5 seconds). It can be configured to run from multiple geographic locations and trigger an alert on failure, meeting all requirements without the complexity of multi-step or custom code.

Exam trap

The trap here is that candidates often confuse the URL ping test with the multi-step web test, assuming that any availability check requires a multi-step test, but the URL ping test is specifically designed for single-URL validation with geographic distribution and alerting.

How to eliminate wrong answers

Option A is wrong because a multi-step web test is designed to validate a sequence of user actions (e.g., login, navigate, submit) across multiple URLs, which is overkill and unnecessary for a simple homepage load check. Option C is wrong because TrackAvailability is a custom method used in code to report availability results manually, requiring you to write and deploy custom application logic, which is not needed for a basic HTTP 200 check. Option D is wrong because continuous export is a feature for exporting Application Insights telemetry data to storage or Event Hubs, not a mechanism for creating or running availability tests.

Full explanation →

783

Multi-Selecthard

Which THREE are valid ways to authenticate an Azure Functions app to an Azure Service Bus namespace?

Select 3 answers

A.Using an Azure AD token obtained via DefaultAzureCredential

B.Using a connection string with shared access policy

C.Using a system-assigned managed identity

D.Using a client certificate

E.Using a SAS key stored in code

AnswersA, B, C

Azure Functions can authenticate to other Azure services (like Key Vault, Storage, Cosmos DB) using Azure AD tokens. DefaultAzureCredential is part of the Azure Identity client library, providing a chain of credential types that attempt to authenticate in various environments (local development, Azure deployment) using the most appropriate method, such as a developer's logged-in account, environment variables, or a managed identity, ultimately acquiring an Azure AD token. This enables secure, token-based access without hardcoding secrets.

Why this answer

DefaultAzureCredential from the Azure Identity library can authenticate to Azure Service Bus using Azure AD tokens. This credential chain attempts multiple authentication sources (environment variables, managed identity, Visual Studio, etc.) to obtain a token, which is then used to authorize requests to the Service Bus namespace via Azure RBAC.

Exam trap

The trap here is that candidates might think client certificates are a valid authentication method for Service Bus, but Service Bus only supports Azure AD, SAS tokens, and connection strings—not certificate-based authentication.

Full explanation →

784

MCQhard

You are designing a serverless application using Azure Functions that processes high-volume events from Azure Event Hubs. The events are then written to Azure Cosmos DB. The function must guarantee at-least-once delivery and be resilient to failures. The Cosmos DB account uses the SQL API and is configured with a single write region. You need to design the function to handle transient failures when writing to Cosmos DB without losing events. What should you do?

A.Increase the Event Hubs trigger's batch size to reduce the number of writes.

B.Implement a poison message queue to store failed events and reprocess them later.

C.In the function code, manually write to Cosmos DB and then manually checkpoint the Event Hubs partition.

D.Use the Cosmos DB output binding with built-in retry policy and configure the trigger to checkpoint only after successful writes.

AnswerD

Utilizing the Cosmos DB output binding provides built-in retry capabilities, automatically attempting to write data multiple times in case of transient failures, significantly improving reliability. Crucially, configuring the Event Hubs trigger to checkpoint only after successful writes ensures that an event is not marked as processed in Event Hubs until it has been durably persisted to Cosmos DB. This combination guarantees at-least-once delivery, preventing data loss even if the function encounters transient issues.

Why this answer

Using the Cosmos DB output binding with its built-in retry policy automatically handles transient failures by retrying writes. By configuring the Event Hubs trigger to checkpoint only after a successful write, you ensure that events are not acknowledged until they are durably stored in Cosmos DB, guaranteeing at-least-once delivery and resilience to failures.

Exam trap

The trap here is that candidates often think manual checkpointing gives them more control, but it actually introduces a window for data loss if the checkpoint occurs before the write is confirmed, whereas the output binding's built-in retry and automatic checkpointing on success provide a safer, more reliable pattern.

How to eliminate wrong answers

Option A is wrong because increasing the batch size does not address transient failures; it only processes more events per invocation, which can increase memory pressure and the risk of losing a larger batch if a failure occurs. Option B is wrong because a poison message queue is used for handling malformed or unprocessable events, not for transient failures that can be retried; it adds unnecessary complexity and does not leverage the built-in retry capabilities of the Cosmos DB output binding. Option C is wrong because manually writing to Cosmos DB and then manually checkpointing introduces a risk of checkpointing before the write succeeds, leading to potential data loss; it also bypasses the automatic retry and consistency guarantees provided by the output binding.

Full explanation →

785

Multi-Selectmedium

Which THREE of the following are valid ways to authenticate an Azure Function to an Azure SQL Database using managed identities?

Select 3 answers

A.Enable system-assigned managed identity on the function app and grant it access to the SQL database.

B.Assign the managed identity directly to the Azure SQL Database logical server.

C.Use the managed identity's principal ID to create a contained database user in SQL Database.

D.Create a user-assigned managed identity, assign it to the function app, and grant it access to the SQL database.

E.Create a service principal and assign it to the function app.

AnswersA, C, D

This is a valid and recommended approach. A system-assigned managed identity is automatically created and managed by Azure for a specific resource (the Function App in this case). Once enabled, this identity can be granted permissions directly to the Azure SQL Database, allowing the Function App to authenticate without needing connection strings with credentials. This eliminates the need for developers to manage secrets.

Why this answer

Option A is correct because enabling a system-assigned managed identity on the function app creates an identity in Microsoft Entra ID tied to that app, which can then be granted access to Azure SQL Database (for example, by adding it as a contained database user with the appropriate role). Option C is correct because after the managed identity exists, you must create a contained database user in the target SQL Database mapped to that identity's principal ID or name (e.g., CREATE USER [name] FROM EXTERNAL PROVIDER) and grant it the needed permissions, which is the actual authentication/authorization step. Option D is correct because a user-assigned managed identity can be created and attached to the function app, and that identity can likewise be granted access to the SQL database, providing the same managed-identity authentication path.

Option B is not valid because managed identities are assigned to Azure resources such as the function app, not to the Azure SQL logical server itself. Option E is not valid because a service principal is a separate Microsoft Entra ID application credential, not a managed identity, and assigning a service principal to a function app is not how managed-identity authentication to Azure SQL works.

Exam trap

The trap here is that candidates often confuse assigning a managed identity to a resource (like a function app) with assigning it to the database server itself, or they think a service principal is a type of managed identity, when in fact managed identities are a specific Azure feature distinct from service principals.

Full explanation →

786

Multi-Selecthard

You are developing a solution that uses Azure Container Apps to host a microservices application. The application consists of multiple services that need to communicate with each other. You need to configure the services to meet the following requirements: (1) Services must be able to discover each other by name, (2) Communication between services must be secure and encrypted, (3) You want to minimize the need for managing certificates. Which two actions should you perform? (Choose two.)

Select 2 answers

A.Deploy an Azure Application Gateway in front of the Container Apps environment to handle internal traffic.

B.Enable mutual TLS (mTLS) for the Container Apps environment.

C.Store service endpoints in Azure Key Vault and retrieve them at runtime.

D.Configure a custom DNS name for each container app and use it for service discovery.

E.Use Azure Container Apps' built-in service discovery by referring to other services using their app name.

AnswersB, E

Mutual TLS in Azure Container Apps provides automatic encryption and authentication between services within the environment. When enabled, each container app receives a certificate issued by the platform, and communication between apps is encrypted and authenticated without manual certificate management. This satisfies the requirement for secure, encrypted communication and minimizes certificate management because the platform handles certificate issuance and rotation. Enabling mTLS is a key step to secure service-to-service communication in a microservices architecture hosted on Container Apps.

Why this answer

To enable secure service-to-service communication with discovery by name and minimal certificate management, you should enable mutual TLS for the Container Apps environment and use the built-in service discovery. mTLS automatically encrypts and authenticates traffic between container apps, and the platform manages certificates. Built-in service discovery allows services to find each other using the app name without additional configuration. Together, these features provide a secure and simplified microservices communication setup.

Exam trap

The trap here is thinking that external load balancers or custom DNS are needed for internal service communication, when Container Apps provides native mTLS and service discovery.

Full explanation →

787

MCQmedium

A retail company uses Azure Logic Apps to integrate with third-party APIs. One Logic App sends purchase orders to a supplier's HTTP endpoint. The supplier requires that the request include an OAuth 2.0 access token obtained from their authorization server. The company wants to manage the client credentials (client ID and client secret) securely and rotate them automatically. The Logic App must also log all requests for auditing. What should you do?

A.Use the built-in HTTP action with a system-assigned managed identity and request a token from the supplier's authorization server using the managed identity.

B.Use the built-in HTTP action in the Logic App, store the client secret in Azure Key Vault, and retrieve it using the Key Vault connector. Then request a token from the supplier's authorization server.

C.Use the 'Managed API' connector for the supplier, configure it with client ID and secret in the connection parameters, and enable 'Azure AD Integration' on the Logic App.

D.Use the 'HTTP + Swagger' connector, define the OAuth2 security scheme, store the client secret in Key Vault, and configure the Logic App to use a system-assigned managed identity to access Key Vault.

AnswerD

The 'HTTP + Swagger' connector, also known as a Custom Connector, is the correct choice as it allows defining the API's structure and security, including OAuth 2.0, through an OpenAPI (Swagger) definition. By specifying the OAuth2 security scheme, the connector automatically handles the token acquisition and refresh process, abstracting this complexity from the Logic App workflow. Storing the client secret in Azure Key Vault, accessed securely via a system-assigned managed identity, ensures robust credential management, compliance, and facilitates secret rotation without code changes.

Why this answer

It combines the HTTP + Swagger connector to define the OAuth2 security scheme inline, stores the client secret in Azure Key Vault for secure management and automatic rotation, and uses a system-assigned managed identity to access Key Vault without hardcoding credentials. This approach ensures the Logic App can securely retrieve the client secret, request an OAuth 2.0 token from the supplier's authorization server, and log all HTTP requests via the connector's built-in logging capabilities.

Exam trap

The trap here is that candidates often assume a managed identity can be used to authenticate to any OAuth 2.0 endpoint, but managed identities are limited to Azure AD tokens; for external OAuth 2.0 servers, you must use the client credentials flow with securely stored secrets.

How to eliminate wrong answers

Option A is wrong because a system-assigned managed identity cannot be used to request a token from an external third-party OAuth 2.0 authorization server; managed identities only work with Azure AD to obtain tokens for Azure resources. Option B is wrong because while it stores the client secret in Key Vault, the built-in HTTP action does not natively support OAuth 2.0 token acquisition or automatic token refresh; you would need custom logic to handle the token request and refresh, and the Key Vault connector introduces additional latency and complexity. Option C is wrong because there is no generic 'Managed API' connector for arbitrary third-party suppliers; managed API connectors are pre-built by Microsoft for specific services, and enabling 'Azure AD Integration' on the Logic App does not help with external OAuth 2.0 flows.

Full explanation →

788

MCQhard

Your Azure Function app processes messages from an Azure Service Bus queue. The function is triggered by Service Bus messages. Occasionally, the function throws an unhandled exception after the message is processed but before the function completes. What happens to the message?

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

B.The message is abandoned and becomes available for other consumers after the lock duration expires.

C.The message is completed automatically despite the exception.

D.The message is automatically removed from the queue.

AnswerB

When an Azure Function processing a Service Bus message in PeekLock mode throws an unhandled exception, the underlying Service Bus message client implicitly calls `Abandon()` on the message. This action releases the lock on the message, making it available for other consumers to process once the message's `LockDuration` expires. The message's `DeliveryCount` is incremented, indicating it has been attempted and failed, thus preparing it for a retry.

Why this answer

In Azure Functions with a Service Bus trigger, the function runtime manages the lock on the message. If an unhandled exception occurs after the message has been processed but before the function returns, the runtime interprets this as a failure to complete the message. As a result, the message is abandoned, meaning the lock is released, and the message becomes available for redelivery to other consumers after the lock duration expires.

This behavior ensures that messages are not lost but can be retried.

Exam trap

The trap here is that candidates assume an exception after processing still results in the message being completed or dead-lettered immediately, but Azure Functions' Service Bus trigger abandons the message for retry, not dead-lettering it on the first failure.

How to eliminate wrong answers

Option A is wrong because messages are moved to the dead-letter queue only after exceeding the maximum delivery count or due to specific system errors (e.g., deserialization failure), not from a single unhandled exception after processing. Option C is wrong because the function runtime does not automatically complete a message if an exception occurs; completion only happens on successful execution. Option D is wrong because messages are never automatically removed from the queue on failure; they are either abandoned for retry or dead-lettered after retries are exhausted.

Full explanation →

789

MCQeasy

You need to expose an on-premises API securely to external partners without opening firewall ports. Which Azure service should you use?

A.Azure Traffic Manager

B.Azure API Management

C.Azure Application Gateway

D.Azure Front Door

AnswerB

Azure API Management is specifically designed to securely expose, publish, and manage APIs, including those hosted on-premises, to external consumers. It acts as a facade, providing a centralized gateway for all API traffic, enabling features like authentication, authorization, rate limiting, caching, request/response transformation, and a developer portal. Its ability to integrate with on-premises networks via VPN or ExpressRoute makes it the ideal solution for securely routing external requests to internal APIs.

Why this answer

Azure API Management is the correct choice because it acts as a secure gateway for exposing on-premises APIs to external partners without opening firewall ports. It can connect to on-premises backends via a VPN or Azure ExpressRoute, and it handles authentication, throttling, and transformation at the gateway layer, keeping the internal network isolated.

Exam trap

The trap here is that candidates often confuse Azure API Management with Azure Application Gateway or Azure Front Door, thinking that any reverse proxy or load balancer can expose APIs securely, but they miss that API Management is the only service that provides full API lifecycle management, including developer portals, policies, and subscription keys, without requiring direct network access to the backend.

How to eliminate wrong answers

Option A is wrong because Azure Traffic Manager is a DNS-based traffic load balancer that routes incoming traffic across endpoints based on routing methods (e.g., performance, priority), but it does not provide API-level security, authentication, or the ability to expose on-premises APIs without opening firewall ports. Option C is wrong because Azure Application Gateway is a layer-7 load balancer with web application firewall (WAF) capabilities, but it requires the backend to be directly reachable from the gateway, meaning firewall ports must be opened or a VPN must be configured; it does not natively abstract API management features like subscription keys or policies. Option D is wrong because Azure Front Door is a global HTTP/HTTPS load balancer and content delivery network (CDN) that accelerates and secures web applications at the edge, but it does not provide API management capabilities such as rate limiting, transformation, or developer portal integration, and it still requires network connectivity to the backend.

Full explanation →

790

MCQeasy

Your company uses Azure API Management (APIM) to expose several APIs. One of the backend APIs requires an API key that is stored in Azure Key Vault. You need to configure APIM to retrieve the API key from Key Vault and pass it to the backend in a header without exposing the key in policy definitions. Which APIM feature should you use?

A.Use a policy expression with the context.Variables to store the key.

B.Store the API key directly in the backend settings of the API.

C.Use a named value that references the Key Vault secret, and reference that named value in a set-header policy.

D.Use the authentication-managed-identity policy to authenticate to Key Vault and retrieve the secret.

AnswerC

This is the correct and recommended approach for securely managing secrets in Azure API Management. Named values can be configured to reference a secret stored in Azure Key Vault. APIM, using its managed identity, securely retrieves the secret at runtime and injects its value into the `set-header` policy without ever exposing the secret in the APIM configuration or policy definitions.

Why this answer

Named values in Azure API Management can be configured to reference secrets stored in Azure Key Vault. When a named value is linked to a Key Vault secret, APIM automatically retrieves the secret value at runtime and can inject it into policies (e.g., a set-header policy) without the secret ever appearing in plaintext in the policy definition. This approach ensures the API key is securely managed and not exposed in source control or policy code.

Exam trap

The trap here is that candidates often confuse the authentication-managed-identity policy (used for backend authentication) with the named value Key Vault integration (used for secret retrieval), leading them to select option D even though it does not directly retrieve secrets from Key Vault.

How to eliminate wrong answers

Option A is wrong because context.Variables in a policy expression are used to store temporary values within a policy scope, but they cannot directly retrieve secrets from Key Vault; the secret would still need to be fetched via a named value or managed identity, making this approach incomplete and insecure if the key is hardcoded. Option B is wrong because storing the API key directly in the backend settings of the API would expose the key in plaintext within the APIM configuration, violating the requirement to avoid exposing the key in policy definitions and not leveraging Key Vault for secure storage. Option D is wrong because the authentication-managed-identity policy is used to authenticate APIM to a backend service (e.g., to call another Azure resource), not to retrieve secrets from Key Vault; retrieving a secret from Key Vault requires a named value with a Key Vault reference or a custom policy using the send-request policy with managed identity, but the authentication-managed-identity policy alone does not fetch secrets.

Full explanation →

791

MCQeasy

You have enabled Application Insights on your Azure Web App. You notice that some server-side exceptions are not appearing in the Application Insights portal. What is the most likely reason?

A.The Application Insights SDK is not installed in the application

B.The developer forgot to set the Instrumentation Key in the application configuration

C.The web app is running on a Free tier App Service plan

D.The exceptions are being caught and handled in code without being re-thrown or explicitly logged

AnswerD

Application Insights' automatic exception tracking primarily captures unhandled exceptions that propagate up the call stack and cause the application to crash or terminate a request. When exceptions are caught within `try-catch` blocks and handled gracefully without being re-thrown or explicitly logged using `telemetryClient.TrackException()`, Application Insights does not automatically detect them. Developers must explicitly log these handled exceptions to ensure they appear in the telemetry.

Why this answer

Application Insights only captures exceptions that are unhandled or explicitly logged via the SDK. If an exception is caught in a try-catch block and not re-thrown or logged using `TelemetryClient.TrackException()`, it will not appear in the portal. This is a common oversight when developers handle exceptions silently without instrumentation.

Exam trap

The trap here is that candidates assume enabling Application Insights on the Azure portal automatically captures all exceptions, but in reality, caught exceptions require explicit logging via the SDK.

How to eliminate wrong answers

Option A is wrong because the question states that Application Insights is enabled on the Azure Web App, which implies the SDK is installed (e.g., via the App Insights extension or auto-instrumentation). Option B is wrong because if the Instrumentation Key were missing, no telemetry at all would appear, not just missing server-side exceptions. Option C is wrong because the Free tier App Service plan does not prevent exception telemetry from being sent; it only limits compute resources and does not affect Application Insights data collection.

Full explanation →

792

Multi-Selectmedium

Which TWO approaches can help you optimize the cost of Azure Storage accounts that store infrequently accessed data? (Choose two.)

Select 2 answers

A.Use Cool or Archive storage tier

B.Use Premium storage tier

C.Enable geo-redundant storage (RA-GRS)

D.Configure lifecycle management to move blobs to cooler tiers

E.Enable Azure Storage encryption

AnswersA, D

Utilizing the Cool or Archive storage tiers significantly optimizes Azure storage costs by aligning data storage with its access frequency. The Cool tier offers lower storage costs but higher access costs and slightly higher latency compared to Hot, suitable for data accessed infrequently. The Archive tier provides the lowest storage cost, ideal for long-term retention with flexible retrieval times, as data must be rehydrated before access, incurring rehydration costs and latency.

Why this answer

Option A is correct because Cool and Archive access tiers are specifically designed for infrequently accessed data: Cool offers lower storage costs than Hot (with higher access costs), and Archive provides the lowest storage cost of all tiers for data that can tolerate hours of rehydration latency, directly reducing the cost of storing rarely used blobs. Option D is correct because lifecycle management policies can automatically transition blobs from Hot to Cool or Archive (or delete them) based on rules such as last-modified or last-accessed time, ensuring data that becomes infrequently accessed is moved to cheaper tiers without manual intervention. Option B is not appropriate because Premium storage tiers (premium block blobs, files, etc.) are optimized for high performance and low latency and carry a higher cost per GB, which is the opposite of cost optimization for cold data.

Option C does not reduce cost because RA-GRS replicates data to a secondary region and is priced higher than LRS or GRS, adding redundancy rather than lowering storage expense. Option E does not affect cost because Azure Storage encryption (SSE) is enabled by default at no additional charge and does not change billing for capacity or transactions.

Exam trap

The trap here is that candidates may confuse cost optimization with data durability or security features, leading them to select geo-redundant storage (RA-GRS) or encryption, which do not reduce storage costs for infrequently accessed data.

Full explanation →

793

MCQeasy

You need to monitor the performance of an Azure web app. You want to track the average response time and the number of failed requests over the last hour. Which Azure service should you use?

A.Application Insights

B.Azure Monitor

C.Log Analytics

D.Azure Advisor

AnswerA

Application Insights is the correct choice as it provides comprehensive Application Performance Management (APM) capabilities specifically designed for monitoring live web applications. It automatically instruments your application to collect detailed telemetry, including request response times, failure rates, dependency performance, and exceptions. This service offers deep insights into application health and user experience, enabling proactive identification and diagnosis of performance bottlenecks.

Why this answer

Application Insights is the correct choice because it is an extensible Application Performance Management (APM) service designed specifically for monitoring live web applications. It can track metrics like average response time and failed request counts out of the box, and it integrates directly with Azure Web Apps via the Application Insights SDK or auto-instrumentation, providing real-time telemetry without requiring custom logging code.

Exam trap

The trap here is that candidates often confuse Azure Monitor (the umbrella service) with Application Insights, assuming Azure Monitor alone can track application-level metrics like response time, when in fact it requires Application Insights for that granular, code-level telemetry.

How to eliminate wrong answers

Option B (Azure Monitor) is wrong because while it collects and stores platform-level metrics and logs (e.g., CPU, memory), it does not natively capture application-level metrics like average response time or failed request counts without additional configuration or integration with Application Insights. Option C (Log Analytics) is wrong because it is a query and analysis tool for log data stored in Log Analytics workspaces, not a real-time application performance monitoring service; it lacks built-in application telemetry collection. Option D (Azure Advisor) is wrong because it is a personalized cloud consultant that provides best practice recommendations for cost, security, reliability, and performance, but it does not collect or display live application performance metrics such as response time or failure counts.

Full explanation →

794

MCQeasy

You are developing an ASP.NET Core web app that will be deployed to Azure App Service. The app needs to authenticate users from a Microsoft Entra ID tenant. You want to minimize development effort and rely on platform features. What should you do?

A.Implement custom OAuth 2.0 middleware in the app.

B.Add Microsoft.Identity.Web NuGet package and configure it in Startup.cs to use Microsoft Entra ID.

C.Use Microsoft Entra ID App Roles and add role checks in the code.

D.Enable App Service Authentication in the Azure portal and configure Microsoft Entra ID as the identity provider.

AnswerD

Enabling App Service Authentication, often referred to as EasyAuth, in the Azure portal provides a fully managed authentication solution that operates at the gateway level, external to the application code. By configuring Microsoft Entra ID as the identity provider, Azure App Service handles the entire authentication flow, including redirecting unauthenticated requests, validating tokens, and injecting user claims into HTTP headers. This approach requires no modifications to the application's codebase, significantly simplifying development and deployment.

Why this answer

Enabling App Service Authentication (also known as EasyAuth) in the Azure portal allows you to configure Microsoft Entra ID as the identity provider with minimal code changes. This approach leverages the platform's built-in authentication layer, which automatically handles token validation, session management, and redirects, thereby reducing development effort and relying on Azure's managed features.

Exam trap

The trap here is that candidates often overestimate the need for code-based solutions (like Microsoft.Identity.Web) and underestimate the power of Azure's built-in App Service Authentication, which can handle the entire authentication flow with zero code changes in the app.

How to eliminate wrong answers

Option A is wrong because implementing custom OAuth 2.0 middleware requires significant manual code for token validation, redirect handling, and session management, which contradicts the goal of minimizing development effort and relying on platform features. Option B is wrong because while Microsoft.Identity.Web simplifies integration with Microsoft Entra ID, it still requires adding NuGet packages, configuring middleware in Startup.cs, and managing authentication logic in code, which is more effort than using the built-in App Service Authentication feature. Option C is wrong because using App Roles and adding role checks in code addresses authorization (what a user can do) but does not handle authentication (verifying who the user is); it assumes authentication is already in place and adds unnecessary code complexity for the stated goal.

Full explanation →

795

MCQmedium

You are deploying a web app to Azure App Service. The app uses environment-specific configuration (e.g., connection strings). You need to manage these settings without redeploying the app. Which feature should you use?

A.Azure App Configuration service

B.App Service application settings

C.ARM template parameters

D.Azure Key Vault references in App Service

AnswerB

App Service application settings are key-value pairs that are injected as environment variables into the application's runtime. They can be easily managed through the Azure portal, CLI, or PowerShell, allowing immediate updates without requiring a code redeployment. Changes to these settings automatically trigger an application restart, ensuring the new values are picked up promptly, making them the ideal and most straightforward solution for managing environment-specific configuration.

Why this answer

App Service application settings (option B) are the correct feature because they allow you to store environment-specific configuration (e.g., connection strings, app settings) as key-value pairs that are injected into the app at runtime. These settings can be changed in the Azure portal, CLI, or PowerShell without redeploying the application code, making them ideal for managing configuration across different environments (development, staging, production). The settings are automatically encrypted at rest and overridden for the specific App Service slot when using deployment slots.

Exam trap

The trap here is that candidates often confuse Azure App Configuration service (a premium, centralized config service) with the simpler, built-in App Service application settings, or they mistakenly think Key Vault references alone can replace application settings, not realizing that references are just a value source within an application setting.

How to eliminate wrong answers

Option A is wrong because Azure App Configuration service is a centralized configuration store for distributed applications, but it requires the app to explicitly pull configuration via its SDK or a provider, and it is not the simplest or most direct way to manage environment-specific settings without redeploying—App Service application settings are built-in and require no code changes. Option C is wrong because ARM template parameters are used to parameterize infrastructure deployments (e.g., resource names, SKUs) and are evaluated at deployment time; they cannot be changed after the app is deployed without redeploying the ARM template. Option D is wrong because Azure Key Vault references in App Service allow you to reference secrets stored in Key Vault from application settings, but they are a feature built on top of application settings—you still need to define the application setting (which is an App Service application setting) to point to the Key Vault secret, and the question asks for managing environment-specific configuration, not specifically secrets.

Full explanation →

796

Multi-Selecteasy

Which TWO Azure services can be used to trigger an Azure Function when a new blob is created in a storage account? (Choose two.)

Select 2 answers

A.Azure Cosmos DB trigger

B.Azure Queue Storage trigger

C.Azure Event Grid trigger

D.Azure Blob Storage trigger

E.Azure Service Bus trigger

AnswersC, D

Azure Event Grid is a highly scalable event routing service capable of subscribing to various event sources, including Azure Blob Storage. It can detect specific events like "Microsoft.Storage.BlobCreated" and reliably deliver them to an Azure Function endpoint. This makes Event Grid an excellent choice for triggering functions in response to new blob creations, offering robust event delivery and filtering capabilities.

Why this answer

Option C (Azure Event Grid trigger) is correct because Azure Storage integrates with Event Grid to publish blob-created events (Microsoft.Storage.BlobCreated), and an Azure Function can subscribe to that event via an Event Grid trigger to react to new blobs. Option D (Azure Blob Storage trigger) is correct because it is the native Azure Functions binding that polls/uses the Blob storage extension to invoke a function when a new or updated blob is detected in a container. Option A (Azure Cosmos DB trigger) is incorrect because it responds to changes in a Cosmos DB container's change feed, not to blob creation.

Option B (Azure Queue Storage trigger) is incorrect because it fires on messages placed in a queue, not on blob creation events. Option E (Azure Service Bus trigger) is incorrect because it responds to messages on Service Bus queues or topics, which are unrelated to blob creation.

Exam trap

The trap here is that candidates often assume the Blob Storage trigger is the only native option, forgetting that Event Grid is also a first-class trigger for blob creation events and is actually the recommended approach for low-latency scenarios.

Full explanation →

797

MCQmedium

Users of a web application hosted on App Service are randomly signed out when the app is scaled out to three instances. Investigation shows that session data stored in in-process memory is not available when subsequent requests hit a different instance. What is the recommended solution?

A.Store session data in Azure Cache for Redis and configure all App Service instances to connect to the same Redis endpoint

B.Enable ARR affinity (sticky sessions) on the App Service to route each user's requests to the same instance

C.Write session data to Azure Blob Storage as a JSON file keyed by session ID on every request

D.Store session state in a Cosmos DB container with a TTL equal to the session timeout

AnswerA

Redis acts as a shared external session store. Each instance serializes the session to Redis on write and deserializes it on read. Because all instances point to the same Redis instance, any instance can serve any user's requests correctly, making the session store horizontally scalable and instance-independent.

Why this answer

When an App Service scales out to multiple instances, in-process session state is stored locally on each instance and is not shared. Azure Cache for Redis provides a centralized, in-memory data store that all instances can access, ensuring session data is available regardless of which instance handles a request. This is the recommended pattern for distributed session state in Azure.

Exam trap

The trap here is that candidates often confuse ARR affinity (sticky sessions) as a complete solution, not realizing it only masks the problem by pinning users to instances, but fails to provide resilience against instance failures or scaling operations.

How to eliminate wrong answers

Option B is wrong because enabling ARR affinity (sticky sessions) only routes requests from the same user to the same instance, but it does not solve the underlying problem of session data loss if that instance fails or is recycled, and it can lead to uneven load distribution. Option C is wrong because writing session data to Azure Blob Storage on every request introduces high latency and is not designed for low-latency, high-frequency session reads/writes; it is a file storage service, not a session store. Option D is wrong because Cosmos DB is a NoSQL database with higher latency and cost compared to Redis for session state, and its TTL feature is for document expiration, not for efficient session management; it is overkill and not the recommended solution for this scenario.

Full explanation →

798

MCQmedium

You are developing a web app that authenticates users via Microsoft Entra ID. The app needs to access the Microsoft Graph API to read user profiles. Which type of permission should you request in the app registration to ensure the app can read profiles without user interaction?

A.Delegated permissions

B.Resource-based permissions

C.Consent permissions

D.Application permissions

AnswerD

Application permissions allow an application to access data and perform actions as its own identity, without a signed-in user. This model is essential for background services, daemon applications, or web apps that need to operate autonomously, such as processing data nightly or integrating with other services. These permissions typically require administrator consent because the application acts with its own high-privilege identity, affecting all users within the tenant.

Why this answer

Application permissions are required for daemon or service-type applications that need to access Microsoft Graph API without a signed-in user. Unlike delegated permissions, which operate on behalf of a user, application permissions allow the app to authenticate as itself using the client credentials OAuth 2.0 flow, enabling read of user profiles without any user interaction.

Exam trap

The trap here is that candidates confuse delegated permissions (which require a user) with application permissions (which do not), especially when the scenario mentions 'read user profiles' without explicitly stating the app runs as a background service or daemon.

How to eliminate wrong answers

Option A is wrong because delegated permissions require a signed-in user and cannot operate in a non-interactive context; they are intended for apps that act on behalf of a user. Option B is wrong because resource-based permissions are not a standard permission type in Microsoft Entra ID app registrations; they refer to permissions assigned directly to a resource (e.g., Azure RBAC) and are not used for Graph API access. Option C is wrong because 'consent permissions' is not a valid permission type; consent is an action (granting approval) that applies to either delegated or application permissions, not a distinct category.

Full explanation →

799

MCQeasy

Your company wants to send email notifications to users via a third-party email service (SendGrid) from an Azure Logic App. What is the recommended way to securely store the SendGrid API key?

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

B.Store the API key in an App Setting of the Logic App

C.Hardcode the API key in the Logic App workflow definition

D.Store the API key in an environment variable on the integration service environment

AnswerA

Azure Key Vault stores the SendGrid API key as a protected secret, and the Logic App's managed identity authenticates to Key Vault without embedding credentials in the workflow definition. This satisfies the requirement to avoid hard-coded secrets while enabling secure retrieval.

Why this answer

Azure Key Vault securely stores secrets and can be accessed by Logic Apps via managed identity, providing the most secure and recommended approach. Option B is wrong because app settings are less secure and can be exposed in configuration files or logs. Option C is wrong because hardcoding secrets in workflow definitions is insecure and violates best practices.

Option D is wrong because environment variables are not specifically designed for secret management and lack the security controls of Key Vault.

Full explanation →

800

MCQhard

You are designing a serverless application using Azure Functions. The function must process messages from an Azure Service Bus queue. The processing time for each message can vary from a few seconds to several minutes. You need to minimize costs while ensuring that messages are processed in a timely manner. Which hosting plan should you recommend?

A.Container Instances plan

B.Premium plan

C.App Service plan

D.Consumption plan

AnswerB

The Azure Functions Premium plan is the optimal choice for scenarios demanding predictable performance, extended execution durations, and elimination of cold starts. It provides pre-warmed instances to ensure immediate response to triggers, crucial for time-sensitive Service Bus message processing. Critically, the Premium plan supports configurable execution timeouts up to 60 minutes, making it suitable for long-running operations that exceed the limits of the Consumption plan, while still offering dynamic scaling.

Why this answer

The Premium plan is correct because it supports long execution times (up to 60 minutes by default, configurable to unlimited), always-warm instances to avoid cold starts, and virtual network integration—all while providing predictable pricing and scaling. This meets the requirement of processing messages that can take several minutes without incurring the cold-start penalties or execution-time limits of the Consumption plan.

Exam trap

The trap here is that candidates often assume the Consumption plan is always the cheapest option, but they overlook its 10-minute execution timeout and cold-start latency, which can cause message processing failures or delays for long-running tasks.

How to eliminate wrong answers

Option A is wrong because Container Instances is not a hosting plan for Azure Functions; it is a separate service for running containers directly, not a Functions hosting option. Option C is wrong because the App Service plan requires a dedicated, always-running VM, which incurs higher costs than necessary for a serverless workload and does not provide the automatic scale-to-zero benefit of serverless plans. Option D is wrong because the Consumption plan has a maximum execution timeout of 10 minutes (by default 5 minutes) and can suffer from cold starts, making it unsuitable for messages that may take several minutes to process.

Full explanation →

801

MCQmedium

You are developing a solution that uses Azure Functions with a consumption plan. The function processes messages from an Azure Service Bus queue. During a load test, you notice that the function takes a long time to start processing messages after a period of inactivity. What is the most likely cause of this cold start delay?

A.The function is using a consumption plan, which may scale to zero instances.

B.The function timeout is set too low.

C.The function is using a premium plan with pre-warmed instances.

D.The Service Bus namespace is using the Premium tier.

AnswerA

This is the correct answer. Azure Functions running on a Consumption plan are dynamically allocated and deallocated based on demand. When no requests are received for a period, the function app may scale down to zero instances. The subsequent first request after this inactivity requires the Azure Functions host to provision new compute resources, load the function code, and initialize the runtime environment, leading to a noticeable delay known as a cold start.

Why this answer

The cold start delay occurs because the consumption plan scales the function app to zero instances after a period of inactivity. When a new message arrives, Azure Functions must allocate a new instance, load the function code, and initialize the runtime, which introduces latency. This is a well-known characteristic of the consumption plan's scale-to-zero behavior.

Exam trap

The trap here is that candidates may confuse function timeout settings with cold start latency, or incorrectly assume that Service Bus tier affects function startup behavior.

How to eliminate wrong answers

Option B is wrong because the function timeout setting controls the maximum execution duration for a single invocation, not the startup latency after inactivity. Option C is wrong because a premium plan with pre-warmed instances eliminates cold starts by keeping instances running, which would reduce rather than cause the delay. Option D is wrong because the Service Bus namespace tier (Premium) affects throughput and features, not the cold start behavior of the function app.

Full explanation →

802

MCQmedium

Your company uses Azure Logic Apps to automate a business process. The process needs to call an external REST API that requires an API key passed in the Authorization header. You need to store the API key securely and reference it in the Logic App. Which approach should you use?

A.Store the API key in the Logic App's definition as a constant

B.Use an Azure Key Vault secret and a managed identity

C.Hardcode the API key in a parameter file

D.Use an Azure Storage account table to store the key

AnswerB

Utilizing an Azure Key Vault secret in conjunction with a managed identity is the most secure and recommended approach for handling API keys. Azure Key Vault provides a centralized, secure store for secrets, backed by FIPS 140-2 Level 2 validated hardware security modules (HSMs), offering encryption, versioning, and granular access policies. A managed identity allows the Logic App to authenticate to Key Vault using Azure Active Directory without needing any hardcoded credentials, adhering to the principle of least privilege and simplifying secret rotation.

Why this answer

Azure Key Vault securely stores secrets like API keys, and using a managed identity allows the Logic App to authenticate to Key Vault without embedding credentials in code or configuration. This follows the principle of least privilege and eliminates the need to manage secrets in connection strings or parameter files.

Exam trap

The trap here is that candidates often choose Option A or C because they think storing the key in the Logic App definition or a parameter file is 'secure enough' for development, but the exam emphasizes that any plaintext storage in code or configuration is a security violation, and the only correct approach is to use a dedicated secrets store like Key Vault with managed identity.

How to eliminate wrong answers

Option A is wrong because storing the API key as a constant in the Logic App's definition exposes the key in plaintext within the workflow JSON, which can be viewed by anyone with read access to the Logic App and violates security best practices. Option C is wrong because hardcoding the API key in a parameter file still stores the key in plaintext within the deployment or configuration files, which can be leaked through source control or logs. Option D is wrong because using an Azure Storage account table to store the key does not provide encryption at rest by default (unless client-side encryption is implemented) and requires managing access keys for the storage account, introducing additional security risks.

Full explanation →

803

MCQmedium

You are building an event-driven application that needs to publish messages to multiple independent subscribers. Each subscriber must be able to filter messages based on custom properties, and each subscriber must receive all messages that match its filter, even if other subscribers have different filters. The solution must guarantee message delivery. Which Azure messaging service should you use?

A.Azure Queue Storage

B.Azure Service Bus Topics and Subscriptions

C.Azure Service Bus Queues

D.Azure Event Hubs

AnswerB

Azure Service Bus Topics and Subscriptions are purpose-built for implementing the publish/subscribe messaging pattern, making them ideal for event-driven architectures requiring message filtering. A publisher sends messages to a topic, and multiple independent subscriptions can be configured on that topic. Each subscription can apply SQL-like or correlation filters to receive only a subset of messages, ensuring that consumers only process events relevant to them. This enables robust fan-out capabilities with tailored message delivery.

Why this answer

Azure Service Bus Topics and Subscriptions are designed for publish-subscribe messaging where multiple independent subscribers each receive a copy of every message that matches their filter criteria. The topic allows publishing messages with custom properties, and each subscription can define a SQL-like filter (using the `SqlFilter` class) to select only relevant messages. This ensures that all subscribers receive all messages matching their filter, with guaranteed delivery via the broker's persistent storage and at-least-once delivery semantics.

Exam trap

The trap here is that candidates confuse Azure Service Bus Queues (point-to-point) with Topics (publish-subscribe), or assume Event Hubs can handle per-subscriber filtering, but Event Hubs lacks broker-side filtering and guarantees each event is consumed by only one consumer per consumer group, not by multiple independent subscribers with custom filters.

How to eliminate wrong answers

Option A is wrong because Azure Queue Storage provides a simple FIFO queue for point-to-point messaging; it does not support multiple independent subscribers or message filtering based on custom properties — each message is consumed by a single consumer. Option C is wrong because Azure Service Bus Queues also implement a point-to-point pattern where each message is delivered to only one consumer; they lack the publish-subscribe capability and per-subscriber filtering that topics and subscriptions provide. Option D is wrong because Azure Event Hubs is optimized for high-throughput event ingestion from multiple producers, not for guaranteed delivery to multiple independent subscribers with custom property filtering — it uses consumer groups for load balancing, not per-subscriber filters, and does not offer the same broker-level filtering or at-least-once delivery guarantees for each subscriber.

Full explanation →

804

MCQhard

An e-commerce platform writes orders to a Cosmos DB container. A downstream inventory service must process every new or updated order exactly once, even if the inventory service restarts mid-batch. The solution must scale horizontally when order volume increases. What is the recommended design?

A.Use the change feed processor library with a dedicated lease container; each worker instance claims partition leases and commits checkpoints after processing each batch

B.Poll the Cosmos DB container every 30 seconds using a _ts timestamp filter to find recently modified documents

C.Subscribe to Azure Event Grid Cosmos DB events and process them in an Azure Function

D.Enable Cosmos DB analytical store and run batch queries from an Azure Synapse Spark pool every hour

AnswerA

The lease container stores the last-processed continuation token per partition. On restart, a worker reads its leases and resumes from the checkpointed position. Adding more worker instances automatically redistributes leases across instances, providing linear horizontal scaling.

Why this answer

The change feed processor library with a dedicated lease container is the recommended design because it provides exactly-once processing semantics through checkpointing, automatic partition lease management for horizontal scaling, and resilience to worker restarts by resuming from the last committed checkpoint. This pattern is purpose-built for Cosmos DB change feed consumption in distributed systems.

Exam trap

The trap here is that candidates may choose Event Grid (Option C) because it is event-driven and seems simpler, but they overlook that Event Grid does not provide exactly-once processing or checkpoint-based restart resilience for Cosmos DB change feed scenarios.

How to eliminate wrong answers

Option B is wrong because polling with _ts timestamps cannot guarantee exactly-once processing due to clock skew, missed updates within the polling interval, and lack of checkpointing for restart resilience. Option C is wrong because Azure Event Grid provides at-least-once delivery for Cosmos DB events, not exactly-once, and does not manage partition leases or checkpoints for horizontal scaling. Option D is wrong because the analytical store and Synapse Spark pool are designed for batch analytics, not real-time event processing, and cannot guarantee exactly-once per-record processing with restart resilience.

Full explanation →

805

MCQhard

You are deploying a containerized application to Azure Kubernetes Service (AKS). The application needs to access Azure SQL Database securely. Which approach should you use to avoid storing credentials in the container image?

A.Store the connection string in a Kubernetes Secret and mount it as an environment variable

B.Use Azure AD Pod Identity (Workload Identity) to assign a managed identity to the pod and authenticate to SQL

C.Use a service principal and store its credentials in Azure Key Vault, then use the Key Vault Secrets Store CSI driver

D.Hardcode the credentials in the Dockerfile

AnswerB

Azure AD Workload Identity (formerly Pod Identity) is the most secure and recommended approach for AKS pods to authenticate to Azure services like SQL Database. It assigns an Azure Active Directory managed identity directly to a Kubernetes service account, which is then associated with the pod. The pod can then obtain an Azure AD access token by exchanging its Kubernetes service account token with Azure AD, allowing it to authenticate to Azure SQL Database without needing any stored credentials, connection strings, or client secrets within the pod or Kubernetes Secrets. This significantly reduces the attack surface and simplifies credential management.

Why this answer

Azure AD Pod Identity (now evolved into Workload Identity) allows you to assign a managed identity to a pod, which can then authenticate to Azure SQL Database without any credentials stored in the image or environment variables. This approach uses Azure AD tokens obtained via the pod's identity, eliminating the need for connection strings or secrets in the container.

Exam trap

The trap here is that candidates often choose Option A (Kubernetes Secret) because it seems like a standard Kubernetes pattern, but they overlook that the question specifically requires avoiding any credential storage in the image or environment, which a Secret still represents.

How to eliminate wrong answers

Option A is wrong because storing the connection string in a Kubernetes Secret and mounting it as an environment variable still exposes the credential in the cluster's etcd and to any pod with access to the secret, violating the 'no credentials in the image' goal. Option C is wrong because while it avoids storing credentials in the image, it introduces unnecessary complexity and still relies on a service principal secret stored in Key Vault, which must be retrieved at runtime; the question specifically asks to avoid storing credentials, and a managed identity (Option B) is the simpler, more secure approach. Option D is wrong because hardcoding credentials in the Dockerfile is a fundamental security anti-pattern that embeds secrets directly in the image, making them accessible to anyone who can pull the image.

Full explanation →

806

MCQeasy

You are developing a solution that stores large media files in Azure Blob Storage. Users access these files frequently for the first 30 days, then rarely afterwards. To optimize costs, you need to automatically move blobs to a cooler tier after 30 days of creation. Which Azure feature should you use?

A.Lifecycle management policies

B.Blob inventory

C.Change feed

D.Immutable storage

AnswerA

Lifecycle management policies are the correct solution because they automate the transition of blobs between different storage tiers (Hot, Cool, Archive) based on rules defined by age, last access time, or other criteria. This automation is crucial for optimizing storage costs for large media files, as it ensures less frequently accessed data is moved to cheaper tiers without manual intervention. By automatically moving older or less-accessed media to Cool or Archive storage, significant cost savings can be achieved.

Why this answer

Azure Blob Storage lifecycle management policies allow you to automatically transition blobs to cooler tiers (e.g., from Hot to Cool) based on age or last modification time. By defining a rule that moves blobs to the Cool tier 30 days after creation, you optimize storage costs for frequently accessed files that become rarely used. This feature is purpose-built for automating tier transitions without manual intervention or custom code.

Exam trap

The trap here is that candidates may confuse lifecycle management with Blob inventory or Change feed, thinking that reporting or event logging alone can automate tier transitions, but only lifecycle policies provide the native, rule-based automation without additional code.

How to eliminate wrong answers

Option B (Blob inventory) is wrong because it provides a report of blobs and their metadata but does not automate tier transitions; it is used for auditing and compliance, not cost optimization. Option C (Change feed) is wrong because it records creation and modification events for blobs but requires custom processing to act on those events; it is not a built-in mechanism for automatic tiering. Option D (Immutable storage) is wrong because it enforces write-once-read-many (WORM) policies to prevent deletion or modification, not to manage storage tiers based on age.

Full explanation →

807

MCQmedium

Refer to the exhibit. You are configuring access to an Azure Storage container using Azure RBAC via a custom role definition. You want to allow a user to list blobs in a container only if the request originates from the IP range 203.0.113.0/24. However, the user reports that they can list blobs from any IP. What is the issue?

A.The Principal is set to an Azure AD tenant instead of a specific user or group

B.The Resource should be the storage account resource ID, not the container resource ID

C.The Action should be 'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'

D.The Condition for IP address is incorrectly formatted

AnswerD

Azure RBAC conditions support specifying source IP address ranges to restrict access, and the provided syntax for `ipAddress` is indeed correctly formatted. Conditions leverage attribute-based access control (ABAC) to add additional checks beyond role assignments, such as network location or specific blob index tags. The use of `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/sourceIp` with a CIDR range is a valid and common way to enforce network-based access restrictions within an RBAC assignment.

Why this answer

The current explanation is technically incorrect. Azure RBAC conditions are designed to add restrictions to role assignments and are evaluated for every request by any principal covered by that assignment, regardless of whether the assignment target is a specific user, group, or a broader scope like the tenant. Assigning a role to the tenant does not bypass conditions; the condition should still be enforced for all principals covered by that assignment.

A more plausible reason for the observed behavior (user can list blobs from any IP) would be that the condition for the IP address is incorrectly formatted (Option D), causing it to always evaluate to true or be ignored, or that another role assignment without the condition exists for the user.

Exam trap

The current exam trap note reinforces the incorrect premise that assigning a role to the tenant bypasses conditions. This is not how Azure RBAC conditions function. A more accurate trap might focus on common pitfalls like incorrect condition syntax, or the existence of other, unconditional role assignments that grant the same permissions.

How to eliminate wrong answers

Option B is wrong because the 'Resource' in a custom role definition for a container-level permission should be the container resource ID (e.g., /subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.Storage/storageAccounts/{account}/blobServices/default/containers/{container}) to scope the role to that container; using the storage account resource ID would grant permissions across all containers, which is not the intent. Option C is wrong because the action 'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read' is correct for listing blobs; the issue is not with the action but with the role assignment scope or principal. Option D is wrong because the condition for IP address is correctly formatted using the '@Resource' attribute with 'Microsoft.Storage/storageAccounts/blobServices/containers/blobs:ipAddress' in the condition expression; the problem is that the condition is not being evaluated because the role assignment is applied to the tenant, not a specific user.

Full explanation →

808

Multi-Selecthard

An API receives JWT access tokens from Microsoft Entra ID. Which two token properties should the API validate before accepting a request? The architecture review board prefers a managed Azure-native control.

Select 2 answers

A.Issuer and signature are valid for the trusted tenant

B.The user's display name is present

C.Token audience matches the API application ID URI or client ID

D.The token was sent in a query string

AnswersA, C

Validating the issuer confirms the token came from the trusted Microsoft Entra ID tenant, and verifying the signature proves it was not tampered with. Together these establish authenticity before the API accepts the request, using Azure-native token validation.

Why this answer

Option A is correct because the API must verify that the JWT was issued by the trusted Microsoft Entra ID tenant (the iss claim matches the tenant's issuer, e.g., https://login.microsoftonline.com/{tenantid}/v2.0) and that its signature validates against Entra ID's published signing keys, ensuring the token is authentic and untampered. Option C is correct because the API must confirm the aud claim matches its own application ID URI or client ID, which prevents tokens issued for a different resource from being replayed against this API. Option B is not required for security validation — a display name is optional and not a reliable authorization check.

Option D is incorrect and insecure: tokens should be sent in the Authorization header as a Bearer token, never in a query string, which would expose them in logs and URLs.

Exam trap

The trap here is that candidates confuse 'claims that are present in the token' (like display name) with 'claims that must be validated for security' (issuer, audience, signature), leading them to select non-essential claims as validation requirements.

Full explanation →

809

Drag & Dropmedium

Arrange the steps to implement Azure Key Vault for storing and retrieving secrets in an application in the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

The correct sequence for implementing Azure Key Vault is: first create the Key Vault, then add the secret, grant access to the secret (e.g., via access policies or RBAC), retrieve the secret in the application, and finally use it. This ensures proper resource creation and security before accessing sensitive data.

Full explanation →

810

Drag & Dropmedium

Arrange the steps to deploy a containerized application to Azure Container Instances (ACI) from Azure Container Registry (ACR) in the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

First create ACR, push image, create container group, configure settings, then start.

Full explanation →

811

MCQhard

Application Insights ingestion cost is rising because a high-traffic app emits large telemetry volume. The team needs statistically useful telemetry while reducing ingestion. What should be configured? The design must avoid adding custom operational scripts.

A.Move the app to a larger App Service plan

B.Adaptive sampling

C.Disable all exception telemetry

D.Increase log verbosity to debug

AnswerB

Adaptive sampling is an intelligent, automatic feature within the Application Insights SDK that dynamically adjusts the rate at which telemetry items are collected and sent to the service. It works by discarding a percentage of telemetry items (like requests, dependencies, and traces) at the client-side before they are transmitted, ensuring that a representative sample is retained while significantly reducing the overall data volume. This direct reduction in ingested data volume is highly effective in lowering Application Insights costs, as billing is primarily based on the amount of data ingested.

Why this answer

Adaptive sampling is the correct solution because it automatically adjusts the volume of telemetry data collected from your application, ensuring that only a representative fraction of events is sent to Application Insights while preserving statistical accuracy for analysis. This reduces ingestion costs without requiring custom scripts or manual intervention, as it is a built-in feature of the Application Insights SDK that dynamically adapts based on traffic patterns.

Exam trap

The trap here is that candidates often confuse scaling (Option A) with cost optimization, or they mistakenly believe that disabling all telemetry (Option C) is a valid cost-saving measure, when in fact adaptive sampling provides a balanced approach that maintains data utility without manual overhead.

How to eliminate wrong answers

Option A is wrong because moving to a larger App Service plan increases compute resources but does not reduce telemetry volume or ingestion costs; it only addresses performance scaling, not data management. Option C is wrong because disabling all exception telemetry would eliminate critical diagnostic data needed for monitoring application health, potentially masking issues and violating the requirement for statistically useful telemetry. Option D is wrong because increasing log verbosity to debug would generate even more telemetry data, exacerbating the ingestion cost problem rather than solving it.

Full explanation →

812

Multi-Selecteasy

Which TWO actions should you take to enable a user-assigned managed identity for an Azure App Service web app?

Select 2 answers

A.Create the managed identity resource in Microsoft Entra ID.

B.Configure the identity in each deployment slot separately.

C.Store the identity's client ID in an app setting.

D.Create the managed identity in the same resource group as the web app.

E.Assign the identity to the web app in the Azure portal or CLI.

AnswersA, E

Creating a user-assigned managed identity involves provisioning it as a standalone Azure resource, distinct from the consuming service. This resource is then registered with Microsoft Entra ID, establishing its unique identity principal. This initial creation step is fundamental, as it defines the identity that will subsequently be assigned to Azure services like web apps, making it a prerequisite for their use.

Why this answer

A user-assigned managed identity is a standalone Azure resource created in Microsoft Entra ID (formerly Azure AD). It must exist as an identity resource before it can be assigned to any Azure service, including an App Service web app. This identity is then tied to a specific tenant and can be used by multiple Azure resources.

Exam trap

The trap here is that candidates often confuse user-assigned managed identities with system-assigned managed identities, assuming the identity must be created in the same resource group as the web app or that its client ID must be manually stored in an app setting, when in fact user-assigned identities are independent resources that can be created anywhere and are automatically discoverable by the consuming service.

Full explanation →

813

MCQeasy

Your company stores customer payment data in an Azure SQL Database. You need to ensure that only the application's managed identity can access the database, and no SQL logins or passwords are used. Which authentication method should you configure?

A.SQL Server authentication with a strong password stored in Key Vault

B.Use Microsoft Entra ID authentication with the managed identity configured as a contained database user

C.Enable Transparent Data Encryption (TDE) and use the database's certificate

D.Configure the Azure SQL firewall to allow only the application's outbound IP

AnswerB

This is the correct approach because it leverages Microsoft Entra ID authentication, allowing an Azure service, like an application running on an App Service or VM, to authenticate to Azure SQL Database using its assigned managed identity. The managed identity is then configured as a contained database user within the Azure SQL database, granting it specific permissions without requiring any passwords or connection strings containing secrets. This eliminates credential management overhead and significantly enhances security by removing secret exposure risks.

Why this answer

Configuring the managed identity as a contained database user in Azure SQL Database using Microsoft Entra ID authentication allows the application to authenticate without any SQL logins or passwords. The managed identity provides an automatically managed service principal in Entra ID, which can be mapped to a contained database user (CREATE USER [<identity-name>] FROM EXTERNAL PROVIDER). This enables token-based authentication using OAuth 2.0, ensuring that only the application's identity can access the database.

Exam trap

The trap here is that candidates often confuse network-level security (firewall rules) or data encryption (TDE) with authentication, failing to recognize that only Entra ID authentication with a managed identity eliminates the need for SQL logins and passwords entirely.

How to eliminate wrong answers

Option A is wrong because SQL Server authentication with a password stored in Key Vault still requires a SQL login and password, violating the requirement of 'no SQL logins or passwords.' Option C is wrong because Transparent Data Encryption (TDE) only encrypts data at rest and does not provide authentication or access control; it cannot replace the need for an identity-based authentication method. Option D is wrong because configuring the Azure SQL firewall to allow only the application's outbound IP does not authenticate the application; it only restricts network access by IP address, and the application would still need a SQL login or password to connect.

Full explanation →

814

MCQmedium

You are developing an Azure Functions app that processes orders. The function must scale out automatically during peak hours but should not incur costs when idle. Which hosting plan should you use?

A.Premium plan

B.Container Instances

C.App Service plan

D.Consumption plan

AnswerD

The Consumption plan is the quintessential serverless hosting option for Azure Functions, offering automatic scaling from zero instances and charging only for the compute resources consumed during function execution. It dynamically allocates and deallocates resources based on incoming events, meaning you pay nothing when your functions are idle. This pay-per-execution model makes it the most cost-effective choice for intermittent, event-driven, or highly variable workloads where minimizing idle costs is paramount.

Why this answer

The Consumption plan is correct because it automatically scales your function app based on demand, including scaling out to handle peak loads, and you only pay for execution time and resources consumed when your functions are running. When idle, there are no costs because the plan does not reserve any instances; it relies on a dynamic, event-driven scale model that can scale down to zero.

Exam trap

The trap here is that candidates often confuse the Premium plan's 'always ready' instances with the Consumption plan's true scale-to-zero capability, mistakenly thinking Premium is required for automatic scaling, when in fact Consumption provides automatic scaling and zero-cost idle behavior.

How to eliminate wrong answers

Option A is wrong because the Premium plan, while offering automatic scaling and no cold starts, incurs costs for pre-warmed instances and a minimum baseline of always-ready workers, so it does not scale to zero and will incur costs when idle. Option B is wrong because Container Instances are not a hosting plan for Azure Functions; they are a service for running containers directly, and while they can scale, they do not provide the built-in, event-driven scaling and pay-per-execution model of Azure Functions. Option C is wrong because the App Service plan runs on dedicated VMs that are always on, meaning you pay for the allocated resources (e.g., VM instances) even when the function app is idle, and it does not scale to zero.

Full explanation →

815

MCQeasy

You are reviewing an ARM template snippet for an Azure App Service. The exhibit shows the site configuration. You need to ensure that the app supports WebSocket connections for a real-time feature. Which setting must be added?

A.Set alwaysOn to false.

B.Set http20Enabled to false.

C.Change ftpsState to AllAllowed.

D.Add 'webSocketsEnabled': true to siteConfig.

AnswerD

For an Azure App Service to properly support and route WebSocket traffic, the "webSocketsEnabled" property must be explicitly set to "true" within the "siteConfig" section of the ARM template. This configuration instructs the underlying Azure platform to enable the necessary infrastructure for WebSocket connections, allowing the initial HTTP upgrade handshake to succeed and establish persistent, full-duplex communication channels between clients and the application. Without this setting, WebSocket connections will fail.

Why this answer

The 'webSocketsEnabled' property in the siteConfig of an Azure App Service ARM template explicitly enables WebSocket protocol support. WebSocket connections require a persistent, full-duplex communication channel over a single TCP connection, which is not enabled by default in Azure App Service. Setting this property to true allows the app to handle real-time features like chat or live notifications.

Exam trap

The trap here is that candidates often confuse 'webSocketsEnabled' with other networking or protocol settings like HTTP/2 or alwaysOn, assuming WebSockets are automatically supported or require a different configuration flag.

How to eliminate wrong answers

Option A is wrong because setting 'alwaysOn' to false would cause the app to unload after periods of inactivity, which would break WebSocket connections that need the app to remain active; alwaysOn should be true for WebSockets. Option B is wrong because 'http20Enabled' controls HTTP/2 support, which is unrelated to WebSocket functionality; disabling it does not affect WebSocket connections. Option C is wrong because 'ftpsState' controls FTP/FTPS access for file transfers, not WebSocket protocol support; changing it to AllAllowed has no impact on real-time features.

Full explanation →

816

MCQeasy

You deploy a containerized web application to Azure Container Instances (ACI). The application writes session data to a local directory. You need the data to persist across container restarts (e.g., after a crash or redeployment). Which storage configuration should you use?

A.Use an emptyDir volume within the container group.

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

C.Use the container's own filesystem and copy data to a blob storage on shutdown.

D.Enable Azure Disk Encryption on the container group.

AnswerB

Mounting an Azure Files share as a volume in an Azure Container Instances (ACI) container group is the correct approach for persistent storage. Azure Files offers fully managed, highly available file shares that can be accessed via the SMB protocol, ensuring data durability and availability even if the container group is stopped, restarted, or deleted. The data resides independently in Azure Storage, allowing new or restarted container instances to access the same persistent state.

Why this answer

Azure Files provides a fully managed SMB file share in the cloud that can be mounted as a volume in an Azure Container Instance. This allows session data written to the local directory to persist across container restarts, crashes, or redeployments, as the data lives on the share rather than in the ephemeral container filesystem.

Exam trap

The trap here is that candidates confuse 'emptyDir' (which is ephemeral and often used in Kubernetes for temporary storage) with a persistent volume, not realizing that ACI's emptyDir is also ephemeral and does not survive container group restarts.

How to eliminate wrong answers

Option A is wrong because an emptyDir volume is ephemeral and tied to the lifecycle of the pod or container group; its contents are deleted when the container group is restarted or redeployed, so it does not provide persistence across restarts. Option C is wrong because relying on the container's own filesystem means data is lost on restart or redeployment, and copying data to blob storage on shutdown is unreliable (shutdown may not be graceful) and adds unnecessary complexity. Option D is wrong because Azure Disk Encryption protects data at rest but does not provide a persistent storage volume; it is a security feature, not a storage solution for persisting session data across restarts.

Full explanation →

817

MCQmedium

You receive an error when deploying this ARM template: 'The serverFarmId property is required.' What is missing from the template?

A.The server farm resource (Microsoft.Web/serverfarms) is not defined in the template

B.The 'location' property is missing from the site resource

C.The apiVersion should be '2018-02-01'

D.The 'kind' property should be 'functionapp'

AnswerA

Azure Web Apps (Microsoft.Web/sites) require an underlying App Service Plan, also known as a server farm (Microsoft.Web/serverfarms), to define the compute resources, pricing tier, and scale settings. If the web app resource attempts to reference a server farm that is not explicitly defined within the same ARM template or does not already exist in the target resource group, the deployment will fail with a dependency error. The web app's `serverFarmId` property typically uses a `resourceId` function to link to this plan, making its prior definition crucial.

Why this answer

The error 'The serverFarmId property is required' indicates that the ARM template is missing a reference to an App Service Plan (Microsoft.Web/serverfarms) resource. In Azure, a web app or function app must be associated with an App Service Plan, which defines the compute resources and pricing tier. The template must define the server farm resource and link it via the 'serverFarmId' property on the site resource.

Exam trap

The trap here is that candidates often think the error is about a missing property on the site resource itself (like location or kind), rather than realizing the entire server farm resource definition is absent from the template.

How to eliminate wrong answers

Option B is wrong because the 'location' property is not related to the serverFarmId error; a missing location would cause a different error like 'The location property is required'. Option C is wrong because the apiVersion '2018-02-01' is a valid version for Microsoft.Web/sites and does not affect the serverFarmId requirement; the error is about a missing resource definition, not an API version mismatch. Option D is wrong because the 'kind' property set to 'functionapp' is used to specify the app type but does not resolve the missing server farm reference; the serverFarmId is still required regardless of the kind.

Full explanation →

818

Multi-Selecteasy

Which TWO conditions are required to use the 'Run from Package' feature in Azure App Service?

Select 2 answers

A.The package must be accessible via a URL if not deployed locally.

B.The package must be stored in Azure Blob Storage.

C.The package must be a ZIP file.

D.The package size cannot exceed 500 MB.

E.The App Service must have a managed identity to access the package.

AnswersA, C

When utilizing the "Run from Package" deployment method for an Azure App Service, if the application package is not directly uploaded to the App Service's local file system, it must be hosted at a URL that the App Service can access. For private storage locations, such as Azure Blob Storage, this URL typically requires a Shared Access Signature (SAS) token to provide secure, time-limited access without exposing the storage account's primary keys. This allows the App Service to mount the package remotely.

Why this answer

Option C is correct because 'Run from Package' requires the deployment artifact to be a ZIP archive (a .zip file), which App Service mounts as a read-only wwwroot; this is why the setting is exposed as WEBSITE_RUN_FROM_PACKAGE pointing to a .zip. Option A is correct because when the ZIP is not pushed locally via Zip Deploy/Kudu, it must be reachable through a URL that App Service can fetch, such as a SAS URL to Azure Blob Storage, OneDrive, or Dropbox, and the app runs directly from that external package. Option B is not required because the package URL can point to any accessible external location, not exclusively Azure Blob Storage.

Option D is not a stated requirement; there is no fixed 500 MB limit for Run from Package (limits relate to the hosting plan and deployment method, not this feature). Option E is not required because access to the package is granted via a SAS token or public URL, not a managed identity.

Exam trap

The trap here is that candidates often assume the package must be in Azure Blob Storage (Option B) or require a managed identity (Option E), but Azure App Service supports any accessible URL and uses SAS tokens for private storage, not managed identities.

Full explanation →

819

MCQeasy

You are building an Azure Logic App that must send an email notification when a new file is added to a SharePoint Online document library. Which connector and trigger should you use?

A.Use the SharePoint connector with the 'When a file is created' trigger

B.Use the Office 365 Outlook connector with the 'When a new email arrives' trigger

C.Use the Azure Blob Storage connector with the 'When a blob is added or modified' trigger

D.Use the HTTP connector with a manual trigger and poll SharePoint's REST API

AnswerA

The SharePoint connector is purpose-built for seamless integration with SharePoint Online, offering a robust set of actions and triggers. The 'When a file is created' trigger specifically listens for new file additions within a designated SharePoint site and document library. This event-driven trigger automatically initiates the Logic App workflow upon detection, eliminating the need for custom code or manual polling, making it the most direct and efficient solution for monitoring file creation in SharePoint.

Why this answer

The SharePoint connector's 'When a file is created' trigger is the correct choice because it directly monitors a SharePoint Online document library for new file additions and initiates the Logic App workflow automatically. This trigger uses SharePoint's webhook capabilities to receive real-time notifications, eliminating the need for polling or manual intervention.

Exam trap

The trap here is that candidates may confuse the SharePoint connector with other storage connectors (like Azure Blob Storage) or mistakenly think a polling-based HTTP approach is simpler, overlooking the native event-driven trigger that is purpose-built for this exact scenario.

How to eliminate wrong answers

Option B is wrong because the Office 365 Outlook connector's 'When a new email arrives' trigger monitors an email inbox, not a SharePoint document library, and would require an email to be sent for each file addition, which is not the requirement. Option C is wrong because the Azure Blob Storage connector's 'When a blob is added or modified' trigger is designed for Azure Blob Storage containers, not SharePoint Online document libraries, and cannot directly detect file changes in SharePoint. Option D is wrong because using the HTTP connector with a manual trigger and polling SharePoint's REST API introduces unnecessary complexity, latency, and resource consumption compared to the native event-driven trigger, and it lacks the built-in authentication and optimization of the SharePoint connector.

Full explanation →

820

MCQmedium

Contoso Ltd. is migrating a legacy on-premises application to Azure. The application processes customer orders and sends confirmation emails. The new solution must use Azure Functions with an HTTP trigger to receive orders, store order data in Azure Cosmos DB, and send emails via SendGrid. Security requirements: All connections must use managed identities where possible. No secrets should be stored in code or configuration files. Cosmos DB and SendGrid API keys must be retrieved at runtime from Azure Key Vault. The Azure Function app must be able to access Key Vault without storing any connection strings or secrets in application settings. The development team plans to use the Azure.Identity and Azure.Security.KeyVault.Secrets libraries. Which approach should the team use to authenticate to Key Vault?

A.Upload a client certificate to the Function app's certificate store. Use ClientCertificateCredential to authenticate to Key Vault.

B.Use Key Vault references in application settings. Store the Key Vault URI in app settings and let the Functions runtime resolve secrets.

C.Enable system-assigned managed identity on the Function app. Grant the identity 'Get' and 'List' permissions on Key Vault secrets. Use DefaultAzureCredential in code to authenticate to Key Vault.

D.Create a user-assigned managed identity, assign it to the Function app, and store its client ID in application settings. Grant the identity permissions to Key Vault. Use ClientSecretCredential with the client ID and a secret.

AnswerC

Enabling a system-assigned managed identity on the Function app provides an Azure Active Directory identity that the application can use to authenticate to other Azure services, such as Key Vault, without storing any credentials in code or configuration. Granting this identity 'Get' and 'List' permissions on Key Vault secrets ensures it has the necessary access. The `DefaultAzureCredential` in code then automatically detects and utilizes this managed identity, offering a robust, secret-free authentication mechanism.

Why this answer

It uses a system-assigned managed identity, which eliminates the need to store any secrets or connection strings. The DefaultAzureCredential class automatically attempts authentication via managed identity when running in Azure, and the code retrieves secrets from Key Vault using the Azure.Identity and Azure.Security.KeyVault.Secrets libraries. Granting 'Get' and 'List' permissions on Key Vault secrets allows the function to read the Cosmos DB and SendGrid API keys at runtime, meeting all security requirements.

Exam trap

The trap here is that candidates often confuse Key Vault references (Option B) as a valid secretless approach, but they still require storing the Key Vault URI in app settings, and the question explicitly prohibits storing any connection strings or secrets in application settings, making managed identity with DefaultAzureCredential the only fully compliant solution.

How to eliminate wrong answers

Option A is wrong because uploading a client certificate and using ClientCertificateCredential requires managing and storing a certificate, which introduces a secret that must be securely stored and rotated, violating the requirement that no secrets be stored in code or configuration files. Option B is wrong because Key Vault references in application settings still require the Key Vault URI to be stored in app settings, and the resolution happens at runtime via the Functions runtime, but the question explicitly requires that the Function app access Key Vault without storing any connection strings or secrets in application settings; additionally, Key Vault references do not use the Azure.Identity and Azure.Security.KeyVault.Secrets libraries as planned. Option D is wrong because storing the user-assigned managed identity's client ID in application settings is a form of secret storage, and using ClientSecretCredential requires a client secret, which must be stored somewhere, violating the no-secrets requirement.

Full explanation →

821

MCQhard

A company uses Azure Functions to process messages from Azure Service Bus. The function currently uses the Consumption plan. They notice that during high load, messages are processed slowly due to scaling latency. Which change would improve throughput most?

A.Switch to the Premium plan

B.Set the maximum instance count to 20

C.Increase the function's batch size to 100

D.Enable Service Bus sessions

AnswerA

Switching to the Premium plan directly addresses latency issues by providing pre-warmed instances, eliminating cold starts that often plague Consumption plan functions. This ensures that function apps are always ready to process messages immediately, leading to significantly faster response times and more predictable performance. Furthermore, Premium plans offer enhanced networking capabilities and dedicated resources, which contribute to more consistent and lower-latency message processing.

Why this answer

The Premium plan for Azure Functions provides pre-warmed instances and faster scaling, eliminating the cold start and scaling latency inherent in the Consumption plan. This directly addresses the bottleneck during high load by ensuring that new instances are allocated instantly, thereby improving message processing throughput from Service Bus.

Exam trap

The trap here is that candidates often assume increasing batch size or instance count will solve scaling latency, but they overlook that the fundamental issue is the cold start and provisioning delay inherent in the Consumption plan, which only the Premium plan resolves by providing pre-warmed instances and faster scaling.

How to eliminate wrong answers

Option B is wrong because setting the maximum instance count to 20 does not reduce scaling latency; it only caps the upper limit of instances, and the Consumption plan still suffers from cold start delays when scaling out. Option C is wrong because increasing the batch size to 100 may cause messages to be locked for longer periods, leading to increased message lock duration and potential duplicate processing, and it does not address the root cause of scaling latency. Option D is wrong because enabling Service Bus sessions does not improve throughput; sessions are used for message ordering and stateful processing, and they can actually reduce parallelism since all messages in a session must be processed by a single instance.

Full explanation →

822

Matchingmedium

Match each Azure compute service to its execution model.

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

Concepts

Matches

IaaS with full OS control

PaaS for web and API apps

Serverless event-driven compute

Managed job scheduling for parallel workloads

Why these pairings

Azure compute services offer different execution models: Azure Functions (serverless, event-driven), Azure Logic Apps (serverless workflow), Azure Kubernetes Service (container orchestration). Common confusions involve associating serverless with containers or PaaS with orchestration.

Full explanation →

823

Multi-Selecteasy

You are designing a solution to store application secrets. You need to ensure that secrets are encrypted at rest and access is audited. Which TWO Azure services should you use?

Select 2 answers

A.Azure SQL Database

B.Azure Monitor

C.Azure Key Vault

D.Azure Storage Account with encryption

E.Azure App Configuration

AnswersB, C

Azure Monitor is a comprehensive solution for collecting, analyzing, and acting on telemetry from Azure and on-premises environments. While it does not store application secrets itself, it is crucial for monitoring the security and access patterns of a dedicated secret store like Azure Key Vault. By integrating with Key Vault diagnostic logs, Azure Monitor enables auditing of secret access, detection of anomalous behavior, and alerting on security incidents, thereby enhancing the overall security posture of the secret management solution.

Why this answer

Azure Monitor is correct because it provides the auditing and logging capabilities required to track access to secrets. By enabling diagnostic settings on Key Vault, you can send audit events (e.g., secret get, set, delete) to a Log Analytics workspace, storage account, or Event Hub, which are then queryable via Azure Monitor Logs. This satisfies the requirement for access auditing.

Exam trap

The trap here is that candidates often confuse Azure App Configuration with Key Vault, but App Configuration is for non-sensitive settings (e.g., feature flags) and lacks the encryption-at-rest and auditing guarantees required for secrets, while Key Vault is the dedicated service for secure secret storage and access logging.

Full explanation →

824

MCQmedium

Your Azure Function app uses an event-driven architecture with Azure Event Hubs. You need to ensure that if the function fails to process an event, the event is retried up to three times and then sent to a dead-letter queue. What should you configure?

A.Use Durable Functions to orchestrate retries and dead-lettering.

B.Implement a try-catch block in the function code and manually re-queue the event.

C.Configure the retry policy in the function's host.json file.

D.Set the 'enableRetry' property on the Event Hub namespace.

AnswerC

Configuring the retry policy within the function's host.json file is the correct and most efficient approach for handling transient failures in event-driven Azure Functions. This declarative configuration allows you to define parameters like `maxRetryCount` and `retryStrategy` (e.g., fixed delay or exponential backoff) directly. For supported bindings like Event Hubs, it automatically integrates with dead-lettering mechanisms, ensuring events are moved to a dead-letter queue after the specified number of retries are exhausted.

Why this answer

Azure Functions for Event Hubs supports a built-in retry policy configured in the host.json file. This policy allows you to specify the maximum number of retries (e.g., 3) and, after exhausting those retries, the event is automatically sent to a dead-letter queue (DLQ) configured on the Event Hub. This approach is declarative and requires no custom code for retry or dead-lettering logic.

Exam trap

The trap here is that candidates often confuse the retry policy configuration location (host.json for the function app) with properties on the Event Hubs namespace itself, or they overcomplicate the solution by choosing Durable Functions when a simple declarative setting suffices.

How to eliminate wrong answers

Option A is wrong because Durable Functions are designed for orchestrating complex, long-running workflows and stateful processes, not for simple retry-and-dead-letter patterns on Event Hubs triggers; using them here would introduce unnecessary complexity and overhead. Option B is wrong because manually re-queuing the event in a try-catch block is error-prone, violates the event-driven architecture's decoupling principles, and does not provide a built-in dead-letter mechanism; it also requires custom code to manage retry counts and queue management. Option D is wrong because the 'enableRetry' property does not exist on the Event Hubs namespace; retry policies for Azure Functions are configured at the function app level (host.json), not on the Event Hubs resource itself.

Full explanation →

825

MCQeasy

You need to deploy a web application to Azure App Service. The application requires a custom domain name and SSL/TLS certificate. You want to automate the deployment using Azure CLI. Which command should you use to upload the SSL certificate to the App Service?

A.az appservice web config ssl upload

B.az appservice certificate import

C.az webapp config ssl upload

D.az webapp certificate upload

AnswerC

The `az webapp config ssl upload` command is the correct and designated method within the Azure CLI for uploading a local `.pfx` file, which contains both the public certificate and its corresponding private key, directly to an Azure App Service. Upon successful upload, this command also enables the binding of the newly uploaded certificate to a specific custom domain configured for the web app, thereby securing traffic with HTTPS. This is crucial for enabling SSL/TLS for custom domains.

Why this answer

The `az webapp config ssl upload` command is the Azure CLI command used to upload an SSL/TLS certificate (in .pfx format) to an existing Azure App Service web app. This command binds the certificate to the app, enabling HTTPS for custom domains.

Exam trap

The trap here is that candidates confuse the deprecated `az appservice` command group with the current `az webapp` group, or they misremember the exact command syntax (e.g., thinking `az webapp certificate upload` exists) because Azure CLI commands have evolved significantly across versions.

How to eliminate wrong answers

Option A is wrong because `az appservice web config ssl upload` uses the deprecated `az appservice` command group, which has been replaced by the `az webapp` group in modern Azure CLI versions. Option B is wrong because `az appservice certificate import` is used to import a certificate from Azure Key Vault or a local file into an App Service Certificate resource, not to upload it directly to a web app. Option D is wrong because `az webapp certificate upload` is not a valid Azure CLI command; the correct verb is `config ssl upload` within the `az webapp` group.

Full explanation →

Microsoft Azure Developer Associate AZ-204 (AZ-204) — Questions 751–825