Azure Container Registry, Azure Container Instances and Azure Container Apps solve distinct operational problems. This AZ-104 guide compares artifact identity, image-pull authorization, runtime lifecycle, revisions and scaling, with a synthetic troubleshooting exercise that separates infrastructure success from application completion.
A built image is not a running service
A container image can build successfully and then fail in Azure because the runtime cannot pull it, its registry credentials are wrong, its entry point exits or the app cannot reach a dependency. Azure administrators need to understand which layer owns each failure. The Azure Container Registry (ACR) stores artifacts; Azure Container Instances (ACI) runs container groups with relatively direct lifecycle controls; and Azure Container Apps operates application environments with revisions, scaling and ingress capabilities.
The current AZ-104 blueprint specifically includes provisioning an ACR, creating a container with ACI and Container Apps, and controlling container size and scale. This is not an Azure Kubernetes Service exam. The goal is to configure and troubleshoot the managed platforms actually named in the syllabus, not describe every possible container orchestrator.
Choose the runtime from the request pattern
Consider two hypothetical workloads. One converts a batch of public sample documents each evening and exits when finished. Another exposes a web service that receives unpredictable requests throughout the business day. Both can use container images, but they do not necessarily require identical hosting. The nightly job may fit a bounded container group, while an event-driven application benefits from revision management, ingress and scaling.
Start with requirements: how long each unit of work runs, whether it must handle HTTP requests, required concurrency, cold-start tolerance, secret access, outbound network path, log retention and acceptable restart behavior. A service that needs stable public HTTP availability and zero-downtime revision changes should not be placed on a primitive execution platform merely to simplify an initial demo.
For each alternative list features available in its current Azure SKU and region. "Container" alone does not mean autoscale, encrypted secrets, private networking, built-in revisions or durable file storage are provided with the same semantics.
ACR is an artifact identity and access boundary
An ACR repository stores image manifests and layers. A tag such as release-candidate or latest can change to point at a different digest. Use the immutable image digest when evidence of exactly what ran is important. Record the source revision, build pipeline, base image provenance and release approval alongside that digest.
Separate image push permission from image pull. A CI builder may publish an image, while a running Azure Container Apps service may need only to retrieve it. Microsoft supports various ACR authentication methods and scoped identities, subject to configuration and permissions. For Azure Container Apps, a supported system-assigned or user-assigned managed identity can pull from private ACR when registry permissions and authentication configuration are in place. Confirm its scoped image-pull role, the registry’s accepted token configuration and network path; the administrator’s successful portal login does not grant the workload image-pull access.
If an image fails to start, distinguish a registry token failure from an invalid image platform, missing tag, unsupported architecture, secret reference failure or application process error. Do not solve every 401 by turning on broadly privileged registry credentials. Examine the actual runtime identity and role before granting anything.
ACI executes a container group
ACI provisions a container group without requiring the operator to maintain a VM fleet or a Kubernetes control plane. It can host simple services or one-off work, but its lifecycle model differs from an application platform with revision-based traffic management. Set CPU and memory for the group, registry credentials or identity, restart policy, environment configuration and relevant network endpoints.
For the batch converter, define where source files are read and where results are stored. It should be possible to distinguish a successful process exit from a successful document conversion. A container can exit with a zero code and still have uploaded no expected artifact. A job ledger should track input ID, output ID, validation result and status outside the ephemeral runtime.
Restart behavior needs careful thought. A process that performs an external write and crashes can repeat work if restarted without a durable operation ID. The deployment platform can restart a container; only the business service knows whether that transaction was already committed.
Container Apps adds revisions and scaling decisions
Azure Container Apps provides an environment for containerized applications, including versioned revisions and event- or traffic-driven scaling under supported configurations. A revision represents a version of the application template; changing certain configuration creates a new revision, while other configuration updates behave differently. The administrator should understand which revision receives traffic, how replicas are created and whether existing traffic remains safe during a deployment.
A revision that starts with the intended image but cannot query the database is not ready merely because the control plane accepted the deployment. Test application startup, dependency access, container port, health behavior and relevant HTTP responses before routing production traffic. A candidate revision may use a different secret, identity or ingress setting; never assume image equality makes those settings identical.
A scale-to-zero option can reduce resource usage for intermittent traffic but may increase startup latency. It is not appropriate for every workload or workload profile. Define a capacity floor when response-time requirements or long-running operations justify it. Scaling the frontend beyond the throughput of a database can worsen the incident rather than fix it.
Ingress is not authorization
A container service might expose an HTTP endpoint publicly or privately, while needing outbound access to a storage account. These are different network paths. Ingress rules and the Container Apps environment decide reachability, but the application still needs the correct Azure identity or backend credential to read data.
A health check returning success does not prove the caller is allowed to modify a protected business record. Configure trusted authentication and scope checks in the application or supporting gateway where required. A private endpoint likewise does not waive identity requirements. Keep deployment identities, artifact-read privileges and runtime data permissions separated.
Inspect DNS, routing, port, revision readiness and access control independently. A pull failure occurs before the application becomes useful, while a token or database authorization failure can occur after the container has started. These symptoms require different investigation paths.
Keep secrets out of the image and the logs
A production password should not be baked into a container layer or stored in an example repository. Configure approved secret references and scoped identities for each environment. A staging revision should not receive access to production customer data simply because both revisions are deployed from the same registry.
For a synthetic failure exercise, revoke a registry image-pull permission in the test configuration. The expected result is a clear authorization failure, not a fallback to an unrestricted registry secret. Then simulate a missing storage role after the image starts and compare the two failure traces. Avoid logging bearer credentials or full private connection strings to diagnose either failure.
Releases need traceable artifacts and rollback rules
Before promoting a revision, record its image digest, configuration revision, intended secrets and health checks. Define whether traffic switches fully or progressively under the platform’s supported traffic-splitting capability. Test a bad release in a harmless lab and inspect how to return traffic to the previously accepted revision. Rollback of traffic does not automatically revert a database write or another external side effect.
An operator should also define a registry retention policy so an accepted older image is available when recovery requires it. Deleting the old image to save storage before confirming a rollback path can convert a minor deployment failure into a recovery problem.
A repeatable AZ-104 container exercise
Create a synthetic build manifest for the batch converter and web API. For both, assign a registry artifact, runtime identity, CPU/memory budget, required dependency and accepted completion condition. Choose ACI for one and Container Apps for the other, then explain which features motivated each selection. This is a planning exercise until it has been executed in Azure.
Test four failure cases: a tag changes to point at a different image, the runtime cannot pull the image, the container runs but its database permission is missing, and load increases beyond the downstream service capacity. Record which layer owns the fix. Use a distinct result state when an operation is uncertain rather than reporting every controller event as successful.
The key AZ-104 skill is being able to configure the right Azure container service, prove which image actually ran, enforce suitable resource access and verify the application outcome. A clean build log alone proves none of those operational requirements. These examples do not claim any actual Azure container deployment or exam question.
Diagnose an image pull failure without expanding privileges
Consider a container revision that fails to start because the runtime cannot fetch its image from ACR. Record the immutable digest, repository, Azure identity used for the pull, available registry network path and effective scope of the image-read permission. If a managed identity was recently changed, allow for documented propagation behavior and verify the actual assignment before assuming the credential was copied correctly. Do not "fix" an image pull by enabling administrative credentials for every service in the subscription.
A separate startup failure can look similar in a monitoring dashboard but have a different cause: the container image pulls correctly, then its entry point fails because an environment variable is missing or a dependent service is unavailable. Keep image-acquisition, runtime-startup and business-health states separate in logs and release gates. An ACI process finishing with exit code zero also requires checking its intended output, not simply its process status.
Separate the diagnostic stages: an image reference or registry authorization failure happens before workload startup, whereas a successfully pulled image can still fail its entry point, dependency checks or readiness probes. The corrective action follows the failed stage, not a blanket increase in privileges. An AZ-104 container operations practice scenario should make the administrator differentiate Azure Container Registry, Container Instances and Container Apps by the deployment requirement and the observed failure, rather than assuming that building a container image establishes the correct runtime, scaling and authorization automatically.