Develop Azure compute solutions practice questions

Function chaining

Why wrong: Function chaining executes activities sequentially, not in parallel.

Monitor

Why wrong: Monitor pattern repeatedly checks an external state, not used for parallel execution.

Human interaction

Why wrong: Human interaction pattern waits for an external manual signal, not parallel API calls.

The function timeout is set too low.

Why wrong: Incorrect. The function timeout (default 5 minutes for consumption) would stop execution, not cause duplicates.

The function uses blob output binding incorrectly.

Why wrong: Incorrect. Output binding issues would not cause duplicate processing.

The function app is using a premium plan instead of consumption.

Why wrong: Incorrect. The premium plan also has visibility timeout behavior; the scenario is specific to consumption, but the root cause remains visibility timeout.

Store connection string in environment variables.

Why wrong: Incorrect. Storing connection strings in environment variables exposes secrets.

Use Key Vault references in App Settings.

Why wrong: Incorrect. Key Vault references can be used for secrets, but App Configuration itself can be accessed via managed identity.

Hardcode the connection string.

Why wrong: Incorrect. Hardcoding is insecure and not recommended.

Entity trigger

Why wrong: Incorrect. Entity triggers are used for stateful entities, not for parallel processing and aggregation.

Activity trigger with retry policy

Why wrong: Incorrect. Activity triggers execute a single task; retry policies handle failures but do not enable parallel execution.

Timer trigger

Why wrong: Incorrect. Timer triggers are based on schedules and not designed for orchestrating parallel tasks.

Environment variables in the container group

Why wrong: Incorrect. Environment variables can be visible in logs and are not encrypted at rest.

Azure Files volume mounted into the container

Why wrong: Incorrect. Azure Files does not provide encryption at rest by default, and the contents could be visible if accessed.

ConfigMap in a Kubernetes cluster

Why wrong: Incorrect. ConfigMap is a Kubernetes resource; Azure Container Instances does not natively support ConfigMap.

Auto-scaling

Why wrong: Auto-scaling adjusts the number of instances based on load but does not handle deployment or rollback.

Traffic Manager

Why wrong: Traffic Manager distributes traffic across regions but does not manage deployment or rollback within a single app.

Application Insights

Why wrong: Application Insights monitors application performance but does not facilitate deployment or rollback.

emptyDir

Why wrong: emptyDir volumes are temporary and are deleted when the container terminates, not suitable for persistent data.

Host path

Why wrong: Host path volumes are tied to the specific node and are not portable or suitable for sharing across instances.

Secret volume

Why wrong: Secret volumes are used to mount sensitive data, not for general persistent storage.

App Service Plan

Why wrong: App Service Plan requires a fixed pricing tier and manual scaling; it does not offer pay-per-execution.

Premium Plan

Why wrong: Premium Plan provides always-ready instances and VNET integration, but it charges per instance regardless of usage.

Dedicated Plan

Why wrong: Dedicated Plan is used for running functions on dedicated VMs or App Service plans with fixed costs.

emptyDir volume

Why wrong: emptyDir is a temporary volume that is cleared when the container restarts.

Azure Disk

Why wrong: Azure Disk is not natively supported in ACI; it requires a sidecar container or use of virtual machines.

ConfigMap

Why wrong: ConfigMaps are used for injecting configuration data, not for persistent storage.

Auto-scaling

Why wrong: Incorrect. Auto-scaling handles load changes by adjusting instance count, not application version deployment.

Backup

Why wrong: Incorrect. Backup saves your app's configuration and content, but does not help with deploying new versions without downtime.

Custom domains

Why wrong: Incorrect. Custom domains map a domain name to your app, but do not aid in deployment or testing new versions.

Blob Storage trigger on Consumption plan

Why wrong: Incorrect. Blob Storage trigger uses a polling mechanism that can delay processing and may miss events under rapid uploads. Consumption plan may also suffer from cold starts.

Event Grid trigger on Consumption plan

Why wrong: Incorrect. While Event Grid is better, the Consumption plan may not guarantee adequate performance at high scale due to resource limits and cold starts.

Blob Storage trigger on Premium plan

Why wrong: Incorrect. Even with a Premium plan, the Blob Storage trigger still relies on polling, which can miss events and isn't as reliable as Event Grid.

Store logs in Azure Container Registry

Why wrong: Incorrect. Azure Container Registry is for storing and managing container images, not for runtime log storage.

Use a Docker volume in the container

Why wrong: Incorrect. Docker volumes are not directly supported in Azure Container Instances without an orchestration platform like Kubernetes.

Pass log path via an environment variable

Why wrong: Incorrect. Environment variables cannot persist data; they are only used for configuration and are lost when the container restarts.

HTTP trigger + Consumption plan

Why wrong: Incorrect. HTTP trigger requires a client to send an HTTP request; it does not automatically respond to blob uploads.

Queue trigger + Consumption plan

Why wrong: Incorrect. This would require adding a separate process to write message to a queue after blob upload, increasing complexity and latency.

Timer trigger + Consumption plan

Why wrong: Incorrect. Timer trigger runs on a schedule and would process blobs based on time rather than actual upload events, leading to latency and inefficiency.

Deploy an Azure Function with a Queue trigger on the Consumption plan.

Why wrong: An Azure Function on the Consumption plan runs independently and incurs separate costs and management, not sharing the same compute resources as the web app.

Create a separate Azure Container Instance to run a continuous job.

Why wrong: ACI is a separate service with its own billing and management, adding overhead and not sharing the web app's compute resources.

Use Azure Logic Apps with a recurrence trigger to poll the queue.

Why wrong: Logic Apps are a separate service for workflow automation; they incur additional costs and do not run within the web app's compute context.

osType = "Linux"

Why wrong: osType specifies the base operating system but does not affect network access or IP address assignment.

restartPolicy = "Always"

Why wrong: Restart policy controls container restart behavior after exit, not network configuration.

volumes.mountPath = "/mnt"

Why wrong: Volumes are used for persistent storage and do not influence IP address or public accessibility.

Mount a GPU volume from the host.

Why wrong: ACI does not support GPU volumes; GPUs are allocated via the container group SKU, not by mounting host devices.

Use Azure Batch with GPU-enabled pools.

Why wrong: Azure Batch is an alternative service for GPU workloads but is not part of ACI; the question specifically asks about ACI.

Enable container GPU support in the Dockerfile.

Why wrong: The Dockerfile can request GPU access but the underlying infrastructure must provide it; ACI requires selecting a GPU SKU to supply GPUs.

Azure Front Door

Why wrong: Azure Front Door is a global load balancer and application delivery controller, but for a single container group with SSL termination, Azure Application Gateway is more appropriate and less complex.

Azure Container Registry

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

Azure DNS zone

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

Use a retry policy in the function code

Why wrong: A retry policy only retries the function invocation; it does not roll back or compensate database writes already performed.

Enable function-level exception handling

Why wrong: Exception handling can catch errors but cannot ensure the entire process is reliably retried or compensated.

Use an Azure Storage Queue for the function input

Why wrong: A queue input ensures the message is not lost, but if the function fails after writing to the database, the message may be requeued but the database side effect remains, leading to duplicate or inconsistent state.

Timer trigger with Consumption plan

Why wrong: A timer trigger runs on a fixed schedule, not in response to blob uploads. It does not activate on new blobs.

HTTP trigger with Premium plan

Why wrong: An HTTP trigger requires an incoming HTTP request; it does not fire automatically on blob uploads. The Premium plan is not needed for scaling.

Queue trigger with App Service plan

Why wrong: A queue trigger processes messages from an Azure Storage Queue, not blob events. The App Service plan would be unnecessary for the stated requirement and requires manual scaling or always-on.

Set restart policy to Always and use a private container registry

Why wrong: The Always policy restarts the container even on successful exits, which is unnecessary for a background job and increases costs. A private registry is irrelevant to the restart behavior.

Set restart policy to Never and use a public container registry

Why wrong: The Never policy does not restart the container if it crashes, which would require manual intervention.

Set restart policy to OnFailure and deploy in a virtual network

Why wrong: While OnFailure is correct, adding a virtual network is unnecessary for the restart behavior and increases complexity and cost.