Develop Azure compute solutions practice questions

Set the batch size to 1 in the function configuration.

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Enable manual scaling and set the instance count to 3.

Why wrong: Enabling manual scaling directly contradicts the principle of autoscaling, which dynamically adjusts instance counts based on demand. Manual scaling fixes the number of instances to a static value, such as 3, requiring an administrator to manually intervene for any changes. This approach offers no automatic responsiveness to fluctuating workloads, making it unsuitable for an autoscaling configuration.

Set the default instance count to 1.

Why wrong: Setting a default instance count merely establishes the initial number of instances when the service starts or when no active scaling rules apply. While a necessary baseline, it does not define the dynamic behavior or conditions under which the system scales up or down. Autoscaling requires explicit rules and thresholds to react to metrics, not just a static default.

Create a scale rule based on a specific date and time.

Why wrong: Creating a scale rule based on a specific date and time configures scheduled scaling, which adjusts instance counts at predefined intervals or specific times. While a form of automated scaling, it is distinct from reactive, metric-based autoscaling that responds to real-time load fluctuations like CPU usage. This action does not configure dynamic scaling based on performance metrics.

Integrate with Azure Virtual Network by default.

Why wrong: Azure Container Instances (ACI) provides basic public IP connectivity by default, allowing containers to be directly accessible from the internet. While ACI does support integration with an Azure Virtual Network (VNet), this is an optional and advanced networking configuration that must be explicitly enabled during container group creation. It is not the default behavior, as default deployments typically run on a public IP address without VNet isolation.

Run containers as nested containers (Docker-in-Docker).

Why wrong: Azure Container Instances runs containers in a secure, hypervisor-isolated environment, which means the underlying host operating system is not exposed to the container. Consequently, ACI does not support privileged operations like running Docker-in-Docker (DinD) or other forms of nested containerization. This architectural design prioritizes security and rapid startup times over complex virtualization scenarios within the container itself.

Mounting Azure NetApp Files volumes.

Why wrong: Azure Container Apps currently supports persistent storage through Azure Files shares and Azure Blob Storage, which can be mounted as volumes to container apps. Azure NetApp Files, while a high-performance, enterprise-grade file storage service for Azure, is not directly supported as a volume mount option within the Azure Container Apps environment. This limitation means developers cannot leverage its specific performance characteristics for their containerized applications in this platform.

The package must be stored in Azure Blob Storage.

Why wrong: While Azure Blob Storage is a highly recommended and common choice for hosting deployment packages due to its scalability and robust access control features, it is not an exclusive requirement for the "Run from Package" feature. The package can also be stored in other accessible locations, such as a public web server, or even directly uploaded to the App Service's `data/SitePackages` directory via Kudu or FTP, where it is then referenced by the `WEBSITE_RUN_FROM_PACKAGE` app setting.

The package size cannot exceed 500 MB.

Why wrong: The maximum supported size for a deployment package when using the "Run from Package" feature in Azure App Service is 1 GB. If the package exceeds this 1 GB limit, the App Service will be unable to successfully mount and run the application, resulting in deployment failures. It is essential to ensure that the compiled application and all its necessary dependencies remain within this specified size constraint for successful operation.

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

Why wrong: An Azure App Service is not strictly required to have a managed identity to access a deployment package for the "Run from Package" feature. While a system-assigned or user-assigned managed identity can be effectively used to grant secure, role-based access to private storage accounts, an equally valid and common alternative is to append a Shared Access Signature (SAS) token to the package URL. This SAS token provides temporary, delegated access without necessitating a managed identity for authentication.

The repository is Mercurial, not Git.

Why wrong: 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 wrong: 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 wrong: 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.

Orchestration history is stored in memory to reduce latency.

Why wrong: This statement is incorrect because Durable Functions do not store orchestration history solely in memory. Instead, the entire execution history, including inputs, outputs, and events, is durably persisted in Azure Storage, specifically in Azure Table storage. This persistence ensures that orchestrations can reliably recover from host failures and continue execution from the last known state, even if the function app restarts, which would not be possible with in-memory storage.

The orchestrator function should be triggered by an HTTP trigger directly.

Why wrong: Orchestrator functions are not directly invoked by HTTP triggers. Instead, they are initiated by a separate "client" or "starter" function, which can be an HTTP-triggered function, a queue-triggered function, or another type of Azure Function. The starter function uses the Durable Functions client binding to start a new orchestration instance and returns a status HTTP response, allowing the orchestrator to run asynchronously in the background.

Configure Pod Disruption Budgets

Why wrong: Pod Disruption Budgets (PDBs) are a Kubernetes API object that ensures a minimum number or percentage of pods for a given workload remain running during voluntary disruptions, such as node maintenance, upgrades, or scaling down operations. By defining a PDB, the Kubernetes scheduler and controllers will prevent the eviction of too many pods simultaneously, thereby maintaining application availability and preventing service degradation during planned cluster changes. This is crucial for high availability within a single cluster.

Enable Cluster Autoscaler

Why wrong: The Kubernetes Cluster Autoscaler automatically adjusts the number of nodes in your AKS cluster based on the resource requests of pending pods. Its purpose is to ensure that there are enough compute resources (nodes) to run all scheduled pods, or to scale down nodes when they are underutilized. While essential for cost optimization and performance within a single cluster, it does not provide disaster recovery capabilities against regional outages or application-level failures across multiple clusters.

Durable Functions

Why wrong: 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 wrong: 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 wrong: Retry policy handles transient failures but does not guarantee ordering or exactly-once.

Create a new App Service plan

Why wrong: Creating a new App Service plan is incorrect because an App Service plan defines the underlying compute resources, such as VMs, CPU, and memory, that host your web app. Continuous deployment (CI/CD) is concerned with the process of automatically building and deploying code to an *existing* web app, not with provisioning new infrastructure. The App Service plan for the target web app is already in place and does not need to be re-created or modified specifically for setting up CI/CD.

Enable Application Insights

Why wrong: Enabling Application Insights is incorrect because Application Insights is an Application Performance Management (APM) service used for monitoring the performance, availability, and usage of live web applications. While crucial for understanding an application's health and user experience *after* deployment, it plays no direct role in the actual process of building, packaging, or deploying the application code. Its functionality is entirely separate from the continuous integration and continuous deployment pipeline.

Add a custom domain to the App Service

Why wrong: Adding a custom domain to the App Service is incorrect because a custom domain allows users to access the web app using a personalized URL (e.g., `www.yourcompany.com`) instead of the default Azure-provided domain (e.g., `yourwebapp.azurewebsites.net`). This configuration is a post-deployment step focused on branding and accessibility for end-users, completely unrelated to the mechanisms or steps involved in setting up continuous integration or continuous deployment of the application code itself.

Enable the 'Always On' setting

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 Azure AD application

Why wrong: Incorrect. Registering the container with an Azure AD application is not necessary; a managed identity provides the required authentication without manual registration.

Configure a custom DNS server

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

Slot settings are not supported in ARM templates

Why wrong: 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 wrong: 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 wrong: 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.

Generate a shared access signature (SAS) token and include it in the connection string

Why wrong: Generating a Shared Access Signature (SAS) token provides delegated access to Azure Storage resources for a specified period and with defined permissions. While effective for granting limited access, a SAS token is a shared secret that must be managed and rotated, and its inclusion in a connection string does not leverage Azure Active Directory-based managed identities. This approach requires manual credential handling, which is less secure than using managed identities.

Use the storage account access key in the connection string

Why wrong: Using a storage account access key in a connection string grants full administrative control over the entire storage account, making it a highly privileged shared secret. This method bypasses Azure Active Directory authentication and does not utilize managed identities, posing a significant security risk if the key is compromised. Best practices strongly advise against embedding access keys directly in application configurations due to their broad permissions and static nature.

Use the default AzureWebJobsStorage connection string from the function app settings

Why wrong: The 'AzureWebJobsStorage' connection string is primarily used by the Azure Functions runtime for its internal operations, such as managing triggers, logging, and state. This connection string typically contains a storage account access key or a SAS token, which are shared secrets, not managed identities. Therefore, relying on this default connection string for application-specific data access does not utilize the more secure, credential-free authentication provided by managed identities.

Azure Queue Storage trigger

Why wrong: An Azure Queue Storage trigger is designed to activate an Azure Function when a new message is added to a specified Azure Storage Queue. This trigger is specifically for processing discrete messages placed into a queue for asynchronous processing, not for monitoring or reacting to events occurring within Azure Blob Storage containers. It operates on the principle of message consumption, not external resource change detection.

Azure Cosmos DB trigger

Why wrong: An Azure Cosmos DB trigger specifically responds to changes occurring within an Azure Cosmos DB container, leveraging the service's change feed functionality. This trigger is designed for scenarios where a function needs to process new inserts, updates, or deletes of documents in a NoSQL database. It has no direct mechanism to monitor or react to events originating from Azure Blob Storage.

HTTP trigger

Why wrong: An HTTP trigger provides a function with a callable HTTP endpoint, allowing it to be invoked by an explicit HTTP request from any client or service. This trigger operates on a request-response model, requiring an external entity to actively send a web request to the function's URL. It does not automatically react to passive events like a blob being created in storage; it waits for an inbound network call.

Ability to use custom base images.

Why wrong: The ability to use custom base images is not a differentiating factor, as both services offer this capability. Azure Functions, especially when deployed on Linux with custom handlers or container support, allows you to package your function app into a custom Docker image, providing full control over the runtime environment and dependencies. Similarly, Azure Container Instances (ACI) is inherently designed to run any Docker container, making the use of custom base images a standard and robust feature for deploying applications on the platform. Therefore, this capability is not a unique advantage for either service.

Cold start latency.

Why wrong: Cold start latency is a significant factor for performance-sensitive applications. Azure Functions on the Consumption plan can experience cold starts, where the platform needs to provision and initialize the function app instance before processing the first request after a period of inactivity, leading to initial delays. Azure Container Instances, conversely, runs continuously once started, eliminating cold start issues because the container is always allocated and ready to process requests. For latency-sensitive workloads with unpredictable traffic patterns, ACI offers more consistent response times by avoiding these initial delays.