AZ-204 Develop Azure compute solutions Practice Question
You are deploying a containerized application to Azure Container Instances. The application must restart automatically if it crashes. You set the restart policy to 'Always'. However, the container keeps restarting continuously even when there is no crash. What is the most likely cause?
⚠ Common exam trap
Watch out — candidates often confuse 'Always' with 'OnFailure' — 'Always' restarts on any exit, including non-zero exit codes on startup, while 'OnFailure' only restarts on non-zero exit codes, making the continuous restart loop a symptom of an application that fails immediately with a non-zero exit code.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The application inside the container exits with a non-zero exit code on startup.
The 'Always' restart policy in Azure Container Instances restarts the container whenever it stops, regardless of the exit code. If the application exits with a non-zero exit code on startup (e.g., due to a configuration error or missing dependency), the container will stop immediately, triggering an infinite restart loop. This is the most likely cause because the container is not crashing due to external factors but rather failing during its initialization phase.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The container is configured with an Azure Files volume that is not accessible.
Why it's wrong here
If an Azure Files volume is inaccessible due to misconfiguration (e.g., incorrect storage key, firewall rules, or non-existent share), the container runtime will typically fail to mount it successfully. This often prevents the container from starting at all or causes the application within to crash immediately if it critically depends on that mount point. While this leads to container termination and subsequent restart attempts, the root cause is a platform-level mount failure, not an application exiting with a non-zero code after starting.
- ✓
The application inside the container exits with a non-zero exit code on startup.
Why this is correct
Container orchestrators, such as Azure Container Instances (ACI), are designed to monitor the primary process running within a container. When this process exits with a non-zero status code, it signals an abnormal termination or a critical failure within the application. ACI's default restart policies (like 'Always' or 'OnFailure') will then automatically attempt to restart the container. If the application consistently fails and exits immediately upon startup with a non-zero code, this creates a continuous restart loop, as the orchestrator repeatedly tries to bring up a failing container.
- ✗
The container is trying to bind to a port that is already in use on the host.
Why it's wrong here
In Azure Container Instances, containers run in isolated network namespaces, and port conflicts are generally managed at the container group level. If an application inside a container attempts to bind to a port that is already in use *within that same container's network namespace* by another process, it would prevent the application from starting successfully. However, ACI assigns unique IP addresses to container groups, abstracting away conflicts with the underlying host. Such a conflict would manifest as a startup failure, but not necessarily a continuous restart loop driven by the application's exit code.
- ✗
The container is exceeding the allocated CPU or memory limits.
Why it's wrong here
When a container exceeds its allocated CPU or memory limits in Azure Container Instances, the ACI service will actively terminate the container to enforce resource governance and maintain host stability. For CPU overruns, the container might be throttled or killed; for memory overruns, it will be terminated by an Out-Of-Memory (OOM) killer. While this termination triggers a restart attempt based on the container group's policy, it is a direct resource enforcement action by the platform, distinct from an application exiting with a non-zero code due to an internal logic error.
Go deeper
Related to this question
About these practice questions
One of 881 original AZ-204 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-204 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-204 exam.