Develop Azure compute solutions practice questions

Azure Front Door

Why it fails: Azure Front Door operates at the edge and expects a publicly reachable origin (or Private Link with Premium); it isn't built to route directly to a container group on a private VNet. Azure Application Gateway deploys inside the VNet and can reach the container group's private IP directly, which is what allows it to expose the application without the container group being publicly reachable.

Azure Container Registry

Why it fails: Azure Container Registry stores container images; it does not provide custom domain or SSL termination for running containers.

Azure DNS zone

Why it fails: Azure DNS zone only manages DNS records; it does not terminate SSL or route traffic to containers.

Set the batch size to 1 in the function configuration.

Why it fails: Setting the batchSize to 1 in the host.json configuration for a Service Bus trigger only ensures that each individual function invocation processes a single message. While this reduces the number of messages processed per call, it does not prevent multiple instances of the Azure Function from concurrently picking up and processing messages from the same Service Bus partition. Therefore, setting batchSize to 1 does not guarantee sequential processing within a partition across a scaled-out function app.

Set the maxConcurrentCallsPerSession to 1, or use a session-enabled queue and set maxConcurrentSessions to 1 if using sessionId.

Why it fails: To ensure sequential processing within a Service Bus partition or session, the maxConcurrentCallsPerSession setting should be set to 1 in the host.json configuration. If using a session-enabled queue and leveraging sessionId for ordering, maxConcurrentSessions should be set to 1 instead. These settings specifically limit the number of concurrent function invocations that can process messages belonging to the same logical partition or session, thereby enforcing ordered processing within that specific group while still allowing parallel processing across different partitions or sessions.

Use a consumption plan, which automatically limits concurrency.

Why it fails: Using a Consumption plan for an Azure Function does not inherently limit concurrency in a way that guarantees sequential processing within a Service Bus partition. The Consumption plan automatically scales out instances based on load, which means multiple function instances can run concurrently. This scaling behavior actually increases the potential for concurrent processing of messages from the same partition across different instances, rather than enforcing sequential order within that partition.

Use a queue trigger instead of a Service Bus trigger.

Why it fails: Using an Azure Storage Queue trigger instead of a Service Bus trigger is inappropriate for scenarios requiring strict message ordering within partitions or sessions. Azure Storage Queues are designed for simple, at-least-once delivery and do not provide built-in mechanisms like sessions or partitioning keys to guarantee the order of messages when multiple consumers are processing them. Service Bus is specifically engineered with advanced features like sessions and partitioning to support complex ordering requirements.

Mount an Azure File Share volume for the output container and configure the application to write output files to a directory on that share. Store the connection string for the file share in a secure fashion using Key Vault and pass it as an environment variable.

Why it fails: While using Azure File Share is durable, the requirement is to write results back to Blob Storage (output container), not a file share. Also, the application is designed to use Blob Storage SDK, not file system I/O.

Embed the storage account connection string directly into the Docker image during build time and rely on the container's environment to provide the output blob container name.

Why it fails: Embedding a storage account connection string directly into a Docker image during build time is a significant security vulnerability. This hardcodes sensitive credentials, making them discoverable if the image is inspected or falls into unauthorized hands. Furthermore, rotating these secrets requires rebuilding and redeploying the entire image across all environments, which is operationally cumbersome and disrupts CI/CD pipelines. This practice violates the principle of least privilege by making the secret universally available within the image.

Set the storage account connection string as an environment variable in the ACI container group definition (YAML or ARM template) and have the application use it at runtime.

Why it fails: Setting a storage account connection string directly as an environment variable within an Azure Container Instances (ACI) container group definition, whether in YAML or an ARM template, is insecure. These values are often stored in plain text within deployment artifacts, source control, and can appear in deployment logs, making them easily accessible to anyone with sufficient permissions to view these resources. This method lacks robust security controls like auditing, access policies, and automatic rotation, which are critical for managing sensitive credentials.

emptyDir volume

Why it fails: An emptyDir volume is a temporary, empty directory created when a container group is started in Azure Container Instances. Its contents are entirely ephemeral, existing only for the duration of that specific container group's lifecycle. Consequently, any data written to an emptyDir volume is irrevocably lost if the container group restarts, crashes, or is deleted, making it unsuitable for persistent data storage requirements.

hostPath volume

Why it fails: The hostPath volume type is a Kubernetes-specific concept designed to mount a file or directory from the underlying node's filesystem into a pod. Azure Container Instances, however, abstracts away the underlying host infrastructure, meaning there is no direct access or concept of a 'host path' for containers. Therefore, hostPath volumes are fundamentally incompatible with the ACI environment and cannot be used for storage.

Azure Disk volume

Why it fails: Azure Disk provides highly durable, high-performance block storage primarily designed for Azure Virtual Machines. While it offers persistent storage, Azure Container Instances does not natively support directly attaching an Azure Disk volume to a container group. ACI's architecture is streamlined for quick container deployment and relies on Azure Files for its managed, network-attached persistent file share capabilities, rather than block storage.

Azure CDN custom domain

Why it fails: CDN accelerates content delivery and does not provide VNet connectivity.

Application Gateway path routing

Why it fails: Application Gateway routes inbound traffic and does not give the app outbound VNet access.

Private Endpoint for the web app only

Why it fails: A Private Endpoint provides private inbound access to the web app, not outbound connectivity from it.

Azure Batch pool

Why it fails: Azure Batch is for batch compute jobs, not the standard hosting plan for Azure Functions.

Consumption plan

Why it fails: The Consumption plan has stricter timeout limits and fewer networking capabilities.

App Service Free tier

Why it fails: The Free tier is not suitable for production Functions workloads requiring VNet integration.

Deploy the web front-end in App Service and the worker in Azure Kubernetes Service.

Why it fails: It deploys the worker in Azure Kubernetes Service (AKS), which is not in the same App Service plan. This would incur additional costs for AKS and does not minimize costs by sharing the same plan.

Use Docker Compose to run both containers in the same App Service plan.

Why it fails: Docker Compose runs all containers as a single unit in App Service; they cannot scale independently. All containers scale together, which violates the requirement.

Deploy the worker as a separate Azure Container Instance.

Why it fails: Deploying the worker as a separate Azure Container Instance (ACI) places it outside the App Service plan, increasing costs and not meeting the requirement to run both in the same plan.

Process messages in batches to improve throughput.

Why it fails: While processing messages in batches can significantly improve the throughput of an Azure Function by reducing overhead per message, it does not inherently address the core reliability concerns of message loss or duplicate processing. Batching is a performance optimization that aggregates multiple messages for a single function invocation, but it provides no guarantees regarding idempotency or atomic processing of individual messages within the batch if failures occur. Therefore, it doesn't prevent side effects from retries or ensure data consistency in a distributed system.

Use the AutoComplete option to automatically mark messages as complete.

Why it fails: The AutoComplete option automatically marks a Service Bus message as complete upon successful execution of the Azure Function, which simplifies development but introduces a significant risk of message loss. If the function successfully receives the message and AutoComplete triggers, but then crashes or encounters an unhandled exception *before* its internal business logic fully processes and persists the message's effects, the message is lost from the queue without its intended processing being completed. This "fire-and-forget" approach sacrifices reliability for convenience.

Use the 'When a file is added' trigger and store processed file names in a SQL database.

Why it fails: This works but introduces unnecessary complexity and overhead.

Use the FTP trigger 'When a file is added or modified' with a recurrence of 10 minutes.

Why it fails: The FTP trigger polls on its own recurrence and re-evaluates files each cycle, so modified timestamps can cause reprocessing; it offers no deduplication state. It suits simple polling of a folder, whereas tracking processed files requires storing state, for example in Azure Blob storage or a SQL table, keyed by file name.

Use the Sliding Window trigger and set the window size to 10 minutes.

Why it fails: Sliding Window is for time windows, not file-level tracking.

Configure the Azure Functions host to use Microsoft Entra ID authentication.

Why it fails: This is an alternative, not in-code validation as specified.

Use the Microsoft Authentication Library (MSAL) to validate the token.

Why it fails: MSAL is for acquiring tokens, not validating them.

Use Azure AD B2C to validate the token.

Why it fails: Azure AD B2C is for customer identities, not general Entra ID validation.

Use GPU-enabled containers for faster processing.

Why it fails: GPUs are more expensive and not needed for typical batch jobs.

Deploy the container group in a virtual network.

Why it fails: Virtual network is not required for the job and adds cost.

Use a container group with a restart policy of 'Always'.

Why it fails: Always restart keeps the container running, increasing cost.

The repository is Mercurial, not Git.

Why it fails: The exhibit explicitly states 'isMercurial: false' within the deployment source configuration. This property directly indicates that the connected repository is indeed a Git repository, not Mercurial. Therefore, the premise that the repository type is mismatched is incorrect, as the configuration clearly identifies it as Git, making this option an invalid reason for deployment failure.

The deployment rollback is enabled and blocking new deployments.

Why it fails: Deployment rollback functionality allows reverting a web app to a previously deployed version, but its enablement status does not prevent new deployments from occurring. The purpose of rollback is to provide a recovery mechanism, not to act as a gatekeeper for incoming code pushes. Therefore, even if rollback were enabled, it would not block the initiation of a new deployment process, making this option an incorrect cause for deployment blockage.

The 'branch' property is set to 'main', but the actual branch is 'master'.

Why it fails: The deployment configuration clearly specifies the 'branch' property as 'main' in the exhibit. If the actual push event targets the 'main' branch, then there is no mismatch between the configured branch and the branch being updated. This option would only be a problem if the configuration expected 'main' but the push was to a different branch like 'master', which is not indicated by the problem statement or exhibit.

The user ID does not have access to the database.

Why it fails: The error 'Login failed' indicates the login itself failed, not access to a specific database.

The connection string type should be 'SQLServer' instead of 'SQLAzure'.

Why it fails: For Azure SQL Database, 'SQLAzure' is the correct type.

The connection string is missing 'Trusted_Connection=True;'.

Why it fails: Trusted_Connection is not used with SQL authentication.

Durable Functions

Why it fails: Durable Functions are for orchestrating workflows, not for Event Hubs ordered processing.

Enable session support on Event Hubs and use the session-enabled trigger

Why it fails: Session support is a feature of Azure Service Bus, not Event Hubs. Event Hubs does not have session-enabled triggers; ordering is guaranteed within a partition, and checkpointing tracks progress.

Use a retry policy in the function

Why it fails: Retry policy handles transient failures but does not guarantee ordering or exactly-once.

Set maxDeliveryCount to a higher value

Why it fails: Increasing maxDeliveryCount only affects the number of retries for failed messages, not the throughput of successful processing. It does not improve throughput.

Set maxMessagesPerBatch to a lower value

Why it fails: Lowering maxMessagesPerBatch reduces the number of messages processed per batch, increasing the number of fetches and overhead, which decreases throughput.

Set maxEventBatchSize to a higher value

Why it fails: maxEventBatchSize is used for Event Hubs triggers, not Service Bus. This setting does not apply to Service Bus and will not affect throughput.

Enable the 'Always On' setting

Why it fails: Enabling the 'Always On' setting is inappropriate for a serverless application aiming for cost efficiency and scaling to zero, as it is primarily a feature of App Service Plans. 'Always On' keeps the application loaded in memory to prevent cold starts, meaning at least one instance is continuously running and incurring costs, which directly contradicts the serverless principle of paying only for execution time.

Use a Premium hosting plan

Why it fails: Using a Premium hosting plan is not suitable if the goal is to scale completely to zero, as Premium plans maintain at least one pre-warmed instance at all times. While Premium plans offer benefits like minimal cold starts, VNet integration, and dedicated instances, this 'always warm' characteristic means there is a continuous baseline cost, preventing the function from fully deallocating when idle.

Pass secrets as environment variables

Why it fails: Passing secrets as environment variables is not secure because environment variables can be viewed in the container's metadata and logs, potentially exposing secrets.

Mount a volume that maps to a Key Vault secret store

Why it fails: Incorrect. Azure Container Instances does not support mounting a volume that maps to a Key Vault secret store. This is not a valid method for accessing Key Vault from ACI.

Register the container with an Microsoft Entra ID application

Why it fails: Incorrect. Registering the container with an Microsoft Entra ID application is not necessary; a managed identity provides the required authentication without manual registration.

Configure a custom DNS server

Why it fails: Incorrect. Configuring a custom DNS server does not provide secure access to Key Vault.

Slot settings are not supported in ARM templates

Why it fails: Slot settings are indeed fully supported in Azure Resource Manager (ARM) templates for App Service. You define these settings within the `Microsoft.Web/sites/slots` resource type, specifically by populating the `properties.appSettings` array or `properties.connectionStrings` array. This declarative approach allows for precise, automated configuration of slot-specific environment variables and connection details, ensuring consistent deployments across different environments.

Deployment slots have been deprecated for App Service

Why it fails: Deployment slots remain a fully supported and essential feature of Azure App Service, providing a robust mechanism for zero-downtime deployments and application testing. They enable developers to stage new versions of their applications, perform A/B testing, and implement blue/green deployment strategies without impacting the live production environment. Their continued availability and active development underscore their value in modern DevOps practices for cloud applications.

The app setting name must be prefixed with 'APPSETTING_'

Why it fails: Azure App Service application settings are exposed to the application as environment variables, and they do not inherently require any specific prefix like 'APPSETTING_'. While certain legacy frameworks or specific application designs might internally use such conventions for configuration, the App Service platform itself does not enforce this naming scheme for its configuration settings. Developers can name their app settings freely, adhering to standard environment variable naming conventions.

The 'allowedAudiences' is missing the App Service URL.

Why it fails: The 'allowedAudiences' configuration specifies the intended recipient(s) of an access token, typically the Application ID URI of the *resource API* that the token grants access to. The App Service URL itself is generally not included here, as the App Service's built-in authentication acts as a client or proxy, not usually the ultimate resource for which the token is issued. Therefore, the absence of the App Service URL in 'allowedAudiences' is not an error and would not cause authentication issues.

The 'issuer' URL is incorrect; it should be a tenant-specific endpoint.

Why it fails: The 'issuer' URL `https://sts.windows.net/common/v2.0` is a valid and commonly used endpoint for multi-tenant applications leveraging the Microsoft Entra ID v2.0 endpoint. This common issuer allows the application to accept tokens from any Microsoft Entra ID tenant without needing to specify a tenant-specific GUID in the configuration. Therefore, stating it *should* be a tenant-specific endpoint is incorrect, as the common endpoint is appropriate and functional for multi-tenant scenarios.

No 'tokenRefreshEndpoint' is configured for session management.

Why it fails: The 'tokenRefreshEndpoint' is a critical configuration setting within Azure App Service authentication that enables the platform to silently renew expired access tokens without requiring user interaction. If this endpoint is not configured or session management is otherwise incomplete, the App Service will not be able to obtain new tokens automatically. Consequently, once the current access token expires, the user will be repeatedly prompted to re-authenticate, leading to a poor user experience.

Continuous deployment from GitHub.

Why it fails: Continuous deployment alone does not reduce downtime.

Traffic Manager.

Why it fails: Traffic Manager is for global load balancing, not deployment.

Auto-heal.

Why it fails: Auto-heal recovers from crashes, not deployment downtime.