A container image being available in Azure Container Registry does not mean an application is running, and a deployed container resource does not mean a customer can reach it. Those are separate stages with different failure modes.
Consider a small organization with two workloads: a nightly invoice converter that reads approved files and exits, and a customer-facing invoice-status API that must remain available while a new version is released. This comparison makes it easier to decide when Azure Container Instances or Azure Container Apps is appropriate, while using the same controlled registry.
Microsoft’s current AZ-104 skills outline includes Azure Container Registry, Container Instances, Container Apps, and container sizing and scaling. For Microsoft AZ-104 container operations, the key skill is matching a reproducible artifact to the right execution model and then diagnose a failed deployment without widening access by guesswork. The procedures below describe an illustrative lab; they are not measured results from a live subscription.
Give the image a stable identity before choosing where it runs
Store an approved container image in Azure Container Registry (ACR), recording its registry, repository, tag and manifest digest. A tag is a human-friendly pointer that can be reused; the digest identifies the precise artifact. If the team redeploys a mutable tag such as latest, it may not be able to reconstruct which image was running during yesterday’s incident. The registry concepts documentation explains repositories, image tags and digests.
Keep image publishing privileges separate from runtime pull access. A build process may need to push, while the hosted workload normally needs only enough authority to retrieve its specified image. A denied pull might indicate the wrong principal, a missing assignment, unsupported identity configuration or a registry network restriction. Do not solve those possibilities by assigning a broad registry administrator role without finding the failing condition first.
For both invoice workloads, create a release record that names the digest, intended destination, configuration revision and owner. That record provides a common starting point when the ACI job fails at startup or the API revision serves the wrong application version.
Use Container Instances for a bounded job with clear completion rules
Azure Container Instances (ACI) runs container groups without requiring the team to operate a cluster. It can suit an approved one-off utility or batch workload when the selected image, CPU, memory, restart policy, environment and storage model meet the job’s requirements. The invoice converter has a defined input set and completion condition. It does not need HTTP ingress merely because the image was built for a container platform.
Configure a disposable job with non-sensitive test invoices, an explicit command and a restart policy appropriate to the desired lifecycle. Record the input object identifiers, chosen CPU and memory, expected exit behavior and where durable output will be written. Treat the container’s local filesystem as an execution environment rather than the only durable copy of valuable business records.
Test two failures independently: an image reference that does not exist and a program that starts but exits unsuccessfully. In the first case, the runtime never reaches the business logic. In the second, image retrieval worked and the next evidence belongs in the container process logs and input configuration. A cloud resource in a provisioned state is not proof that the invoice conversion finished correctly or wrote all expected outputs.
Use Container Apps when revisions and inbound traffic are part of the job
The invoice-status API has a different contract: callers need an endpoint, a healthy process, permitted ingress and a controlled rollout. Azure Container Apps provides managed app revisions, ingress and scaling rules. Start with a small HTTP API that exposes a known health response, and configure the port and desired ingress reachability for the chosen environment. An event-driven worker may legitimately have ingress disabled; that same setting would make an externally reachable status API unusable.
Container Apps has single- and multiple-revision modes. In single-revision mode the platform deploys a replacement revision and handles the transition after the new revision becomes ready under the supported rules. Multiple-revision mode offers explicit control over active revisions and traffic distribution. Those modes are not just labels for the same release process. Choose one deliberately and record which revision and image digest actually received requests.
Deploy a second API revision that changes only a harmless response marker. Verify its startup probe, readiness, dependency access and returned marker before directing production-like test traffic to it. If the revision fails startup or cannot reach a backend, retain the known-working version under the supported revision model rather than treating a successful deployment request as evidence of a safe release. A traffic rollback does not necessarily reverse an external database change.
Size the runtime according to actual execution behavior
The nightly converter needs enough memory and CPU to finish within an acceptable processing window. Increasing replicas would not help if every instance independently rewrites the same invoice or competes for a single protected output. The HTTP API’s main concerns include request concurrency, startup time, downstream capacity, health probes and supported replica bounds. Measure those requirements in an approved test environment before asserting a minimum or maximum replica count.
Document any scale trigger and what should happen during idle periods or backend failure. A replica can be healthy from the platform’s point of view while its database connection is denied; scaling more instances merely reproduces the fault. Also distinguish a failure to pull the image from a service that can start but cannot serve its ingress target port. For Container Apps, consult the current ingress settings for the selected HTTP or TCP configuration.
Diagnose a bad deployment in the order it can fail
When the API is unavailable, investigate the first failed stage. Use the error and release record to avoid making several unrelated configuration changes at once:
| Stage | What to inspect | What not to assume |
|---|---|---|
| Image reference | Registry URL, repository, tag/digest, existence of manifest | A deployment manifest points to a valid image |
| Registry access | Pull identity, role, registry network path, exact denial | Granting Owner is the required fix |
| Container startup | Entrypoint, environment, memory, process exit and logs | A provisioned container executed its business task |
| Application readiness | Listening port, probes, dependency response and health result | A running process is a ready HTTP service |
| Ingress and release routing | Exposure rules, revision mode, traffic weights and response marker | The newest revision is the one receiving traffic |
If the application reaches its backend using a managed identity, inspect the runtime’s selected principal and target permissions separately from the registry pull identity. Managed identity principal IDs and access tokens must be traced to their runtime and target permissions. A correct registry role does not authorize Blob access or Key Vault secrets. Log error categories and safe correlation identifiers without exposing credentials, raw secrets or confidential invoice contents.
Complete the release with a result a reviewer can reproduce
For the ACI task, preserve the exact image digest, input identifiers, execution state, exit status, output count and errors. For the Container Apps API, preserve the digest, environment and revision, observed readiness, test endpoint response, traffic selection and fallback revision. Label a planned test as planned until somebody actually runs it; it is not acceptable to invent a passing result because the steps look reasonable.
The service choice should follow those operational contracts. Use ACR to distribute controlled artifacts; ACI when bounded container-group execution fits; and Container Apps when revisions, managed ingress and scaling are genuinely needed. A different managed hosting model, such as Azure App Service, may be better for an application whose deployment and runtime constraints are already aligned to it. The outcome is not the platform with the most features, but the simplest supported configuration that can be operated, secured and recovered reliably.