Skip to main content

Technical Lab: Provision a container by using Azure Container Instances

Questions​

Question 1 — Multiple Choice​

You need to deploy a container in Azure Container Instances that must communicate with other containers from the same group, sharing IP address and lifecycle. What is the correct mechanism for this?

A) Create separate ACI instances and connect them via Azure Virtual Network with configured peering.

B) Define multiple containers within the same container group, which share the same IP address and network namespace.

C) Use an Azure Container App to orchestrate the containers, since ACI does not support multiple containers per instance.

D) Configure a sidecar as a separate service in ACI and expose communication via internal Azure Load Balancer.

Question 2 — Technical Scenario​

A developer executed the following command to deploy a container:

az container create \
  --resource-group rg-producao \
  --name meu-app \
  --image meuregistry.azurecr.io/app:v1 \
  --cpu 1 \
  --memory 1.5 \
  --restart-policy OnFailure

After execution, the container doesn't start and the event log indicates authentication failure when trying to download the image. What is the most likely cause and appropriate correction?

A) The OnFailure policy prevents initial execution; should use Always.

B) The parameter --memory 1.5 is invalid for the selected region; should use an integer value.

C) The command didn't include credentials for Azure Container Registry; it's necessary to add --registry-login-server, --registry-username and --registry-password (or configure managed identity).

D) ACI doesn't support images hosted in Azure Container Registry; the image must be in Docker Hub.

Question 3 — True or False​

An Azure Container Instances container group deployed with Windows OS type can include containers that run Linux images in the same group, as long as each container declares its own operating system in the YAML definition.

Question 4 — Technical Scenario​

You need to deploy a container that processes files uploaded by users. The container must have persistent access to a /dados directory, where files survive container restarts. You configured the following snippet in a YAML file:

volumes:
  - name: dados-vol
    azureFile:
      shareName: arquivos
      storageAccountName: mystorageaccount
      storageAccountKey: <chave>
containers:
  - name: processador
    image: meuregistry.azurecr.io/processador:latest
    volumeMounts:
      - name: dados-vol
        mountPath: /dados

When applying the YAML, the volume is not mounted correctly. What is the most likely error in this configuration?

A) ACI doesn't support Azure Files type volume mounting; it's necessary to use an Azure Blob Storage mounted via blobfuse.

B) The storage account key cannot be provided directly in YAML; it must be referenced via Azure Key Vault.

C) The volume definition is at the correct level, but volumeMounts should be inside the container's properties section according to ACI schema, and a YAML structure error can cause silent mounting failure.

D) The shareName must correspond to the ACI container name; different names cause volume resolution failure.

Question 5 — Multiple Choice​

When comparing the available restart policy options in Azure Container Instances, which behavior combination is technically correct?

PolicyBehavior
AlwaysRestarts the container regardless of exit code
OnFailureRestarts only if the container exits with non-zero code
NeverThe container runs once and is not restarted in any case

A) The table is correct for all three policies.

B) The table is wrong only for OnFailure; this policy restarts the container regardless of exit code, just like Always.

C) The table is wrong only for Never; this policy still allows restart if the container fails due to Azure infrastructure error.

D) The table is wrong for Always; this policy only applies to containers that didn't receive an explicit shutdown command.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

In Azure Container Instances, the container group is the deployment unit that groups multiple containers in a single logical host. Containers within the same group share the IP address, exposed ports, and lifecycle, communicating with each other via localhost. This architecture is analogous to the Pod concept in Kubernetes.

Alternatives A and D represent the misconception of treating each ACI container as a completely isolated instance that would need external network infrastructure to communicate. Alternative C is incorrect because ACI does support multiple containers per group; Azure Container Apps is a different abstraction layer, not a requirement for this.

Answer Key — Question 2​

Answer: C

Azure Container Registry is a private registry. When using ACI to pull an image from a private registry, it's mandatory to provide authentication credentials. The command completely omitted the --registry-login-server, --registry-username, and --registry-password parameters. A more secure alternative is to assign a managed identity to the container group and grant it the AcrPull role on the registry.

Alternative A is incorrect because the restart-policy doesn't interfere with the image pull process. Alternative B is incorrect because ACI accepts decimal values for memory, like 1.5 GB. Alternative D is factually wrong; ACI has native support for Azure Container Registry.

Answer Key — Question 3​

Answer: False

A container group in ACI has a single OS type defined for the entire group. It's not possible to mix Linux and Windows containers within the same group. If the group is declared as Windows, all containers must run Windows images. The attempt to declare the OS per container individually in YAML is not supported by the platform. This limitation is relevant in migration scenarios or sidecar deployments that use different OS images.

Answer Key — Question 4​

Answer: C

ACI fully supports Azure Files type volumes, so alternative A is wrong. Alternative D is incorrect; there's no relationship between shareName and the ACI container name.

Alternative B describes a good security practice, but it's not the cause of a mounting failure in the presented configuration. The most common problem in this scenario is a structural error in the YAML file. In the ACI schema, the volumeMounts section must be correctly nested within the container's properties. A misalignment in indentation or incorrect positioning in YAML results in silent mounting failure, where the container starts, but the /dados directory is not mapped to Azure Files. Reviewing the schema with az container create --help or validating the YAML against the ARM schema is the correct diagnostic approach.

Answer Key — Question 5​

Answer: A

The table is correct for all three policies. Always is suitable for long-running services that should remain in execution. OnFailure is ideal for batch tasks where an exit with code zero indicates success and doesn't require restart. Never is used for single-execution workloads where any restart would be undesirable, like one-time processing pipelines.

The distractors explore the suspicion that actual behavior differs from documented. Alternative C represents a common misconception: Azure infrastructure failures (like host reallocation) are handled by the platform transparently and are not exposed as restart events at the container policy level. The Never policy applies to the container's behavior itself, not to the availability of the underlying infrastructure.