Developing AI Cloud Solutions on Azure Free Sample Questions

The az acr pack build command leverages Cloud Native Buildpacks directly within Azure Container Registry to compile application source code into a container image without requiring a Dockerfile. In contrast, az acr build performs a quick task build that requires a Dockerfile. az acr run executes commands inside an existing container image in ACR Tasks, and az acr import is used to import already-built images from external container registries.

Multi-step tasks in ACR Tasks are declared using YAML files and support built-in run variables such as {{.Run.ID}}, {{.Run.Registry}}, and {{.Values}} to parameterize and tag image outputs.

ACR Tasks includes native support for base image update triggers (--base-image-trigger-enabled true), which automatically trigger application image builds when an upstream OS or framework base image is updated in the registry. Multi-step tasks in ACR Tasks are declared using YAML files and support built-in run variables such as {{.Run.ID}}, {{.Run.Registry}}, and {{.Values}} to parameterize and tag image outputs. Polling via cron or deploying custom container instances introduces unnecessary complexity when native ACR triggers exist.

In Azure Container Apps (when configured in multiple revision mode), assigning a revision label (az containerapp revision label add) provides a direct, predictable sub-domain URL (e.g., https:// --- . . .azurecontainerapps.io) specifically to that revision. This allows engineers to test the revision directly without allocating any percentage of the production traffic split. Allocating 1% traffic routes live end users, single revision mode does not support staging slots, and internal ingress prevents external QA access.

In Azure Container Apps single revision mode, zero-downtime deployment is achieved because traffic automatically switches to the new revision only after three conditions are satisfied: 1) provisioning succeeds, 2) the replica count of the new revision scales to match the replica count of the previously active revision (subject to minReplicas and maxReplicas constraints), and 3) startup and readiness probes pass successfully. Once ready, traffic shifts 100% to the new revision and the old revision is deactivated and deprovisioned.

In Azure Container Apps, revision labels must consist of lowercase alphanumeric characters or hyphens (-), must start and end with an alphanumeric character, cannot exceed 64 characters, and cannot include consecutive hyphens (--). Therefore, qa-test-v2 is valid. -staging-release is invalid because it begins with a hyphen, prod--preview is invalid because of consecutive hyphens, and Feature_Experiment_1 is invalid because it contains uppercase letters and underscores.

In Azure Container Apps KEDA-based scaling, the cooldownPeriod (which defaults to 300 seconds) applies strictly when scaling from the last active replica down to 0 replicas. Scale-down operations between non-zero replica counts (such as from 10 down to 4) do not wait for the cool down period; they scale down based on the scale-down stabilization window and current metric evaluations.