A team builds a container image, pushes it to a registry and tells the Azure administrator to “just run it.” That request hides several decisions: who may pull the image, where the container runs, whether inbound traffic is allowed, how secrets are supplied, whether replicas must scale, and how updates are rolled out. The same image can be appropriate for a short batch job and unsuitable for a high-availability customer-facing application.
A container registry does not schedule an application, and a successful image pull does not prove that the workload has durable state or a safe update path. Azure Container Registry stores versioned images, Azure Container Instances can run bounded container workloads without maintaining a VM fleet, and Azure Container Apps provides application revisions, ingress and scaling behavior. Those differences belong in a Microsoft AZ-104 container decision, but the workload contract comes first. A nightly data processor, a public API and an internal event-driven service can share an image yet need different network exposure, identity, replica behavior and release controls. Select the runtime by those constraints, not by product familiarity.
Treat the image as a versioned supply-chain artifact
A container image packages an application and its dependencies, but that does not make it trustworthy. The administrator must know where the image originated, what version is being deployed and which identity can push or pull from its registry. Azure Container Registry provides a private image repository that can participate in automated build and deployment pipelines.
Avoid using a mutable latest tag as the only production identity. If an upstream build overwrites the tag, a restart can deploy different bits from those that passed testing. Record immutable image digests or versioned tags as appropriate and retain the release manifest. A registry being reachable proves little about the content of the image or the security of its dependencies.
Image pull permission deserves least privilege. A running service generally needs permission to pull the required image, not to overwrite repository content or manage registry configuration. A failed startup may result from a missing image, wrong credentials, network restrictions or an incompatible architecture. Diagnose the exact stage before broadening registry access.
ACI suits bounded execution without a cluster
Azure Container Instances can start container groups without an administrator managing the underlying host infrastructure. That makes it useful for discrete processing, development tasks and simple workloads whose scheduling and networking fit the service model. It should not be treated as a complete replacement for every orchestration feature found in a managed application platform.
Plan CPU, memory, restart policies, network access and output storage as part of the container group. A task that imports data may need access to a private storage endpoint and a way to persist results after the container finishes. If the workload writes only to its ephemeral local filesystem, the result may disappear when the instance is replaced or removed.
Build retry behavior into the job design. Starting a second container after a client timeout can execute the same external write twice. Use an operation identifier, log its result to durable storage and make the task resumable where possible. This matters as much as whether ACI successfully allocated resources.
Container Apps is an application lifecycle platform
Azure Container Apps combines container execution with managed ingress, networking, revisions and scale rules. It can run web-facing services, internal components and event-driven consumers without asking the application team to operate a general-purpose Kubernetes cluster. That convenience changes what the administrator manages; it does not remove responsibility for authorization, secrets, deployment versions and operational diagnosis.
An environment can provide shared networking and logging foundations for multiple apps. Decide whether ingress is external, internal or disabled, and what can call a service. A private application should not be given public ingress merely to make its initial test easier. Validate the caller path, DNS and required identity before opening exposure.
A service may scale to zero on supported triggers, but not every scaling method behaves the same way. Scale rules, minimum replicas, application startup time and downstream dependencies influence user experience. For a critical API, keeping at least one warm replica may be more appropriate than accepting cold starts; for intermittent batch work, scaling down can reduce idle cost.
Revisions and traffic splits control change risk
A Container Apps revision is a versioned snapshot of revision-scoped configuration. Updating a container image or applicable scale setting creates a new revision. In single-revision mode, the platform can keep the old revision serving traffic until the new one is ready. Multiple-revision mode supports more explicit activation and traffic distribution, which is useful for controlled rollout and comparison.
Readiness probes matter. A container can report that its process started while still being unable to reach a database or initialize a model. Configure health checks around genuine readiness, then verify the rollout from the application’s external or internal client path. A stable traffic split is not useful if the candidate revision depends on a schema that production has not migrated.
These concerns are related to App Service deployment slots, but the mechanisms are not interchangeable. Revision management and slot swapping each have their own configuration scopes, traffic behavior and rollback expectations. Choose the platform from the workload instead of assuming all managed deployment systems use identical lifecycle semantics.
Secrets and registry credentials need explicit ownership
A runtime may require a connection string or API token, but the value does not belong inside the image. Azure Container Apps distinguishes application-scope changes, including secret updates, from revision-scope template changes such as a new image or scale rule. Changing an application secret does not by itself create a revision, and a running revision may need to restart to read the updated value. Managed identities reduce the need for static service secrets where the workload supports token-based authentication; registry credentials still need controlled rotation.
Prefer managed identities and narrow role assignments where supported. A container processing customer records should reach only the permitted account or data service. Audit management-plane permissions separately from the workload’s runtime access: Azure Container Apps listSecrets operations return secret values in plaintext, and some built-in roles can include that permission through wildcard actions. Inspect the effective role actions granted to operators and automation rather than trusting a role name. Azure RBAC role scopes determine which resource operations an identity can perform; merely running a workload inside Azure provides no authorization grant.
Review log destinations and retention. Container stdout can contain errors and operational context, but it should not become a dumping ground for secrets or full personal-data payloads. Route useful diagnostic signals to the monitoring platform and limit access to sensitive traces.
Scaling can expose dependencies the container hides
When an application scales out, each replica may create additional database connections or compete for rate-limited external APIs. A setting that improves HTTP responsiveness can overwhelm a single downstream queue or storage account. Capacity planning needs to include total concurrency across replicas, not only CPU inside one container.
Choose scale triggers that represent actual demand. HTTP concurrency may suit an API; queue depth may suit a consumer. Minimum and maximum replica settings bound cost and recovery speed. Test whether a deployment remains useful while the platform scales, and what happens when a shared service is throttled or unavailable.
Azure Monitor and Network Watcher can help explain connectivity problems, while application logs and Container Apps metrics reveal startup failures, replica churn and delayed processing. Put those signals together when a user reports intermittent errors. Simply increasing the maximum replica count without examining the bottleneck may worsen the incident.
Use infrastructure as code for repeatable container releases
A container application depends on an environment, registry identity, networking and telemetry as well as image configuration. The release principles in Bicep and ARM deployments help keep these resources consistent across development and production. A version-controlled manifest should identify image digest, ingress exposure, resource limits, identity, scale policy and appropriate rollout state.
Test a production-like release path with one internal workflow and one failure. Verify a deliberately denied registry pull, an unavailable dependency, a rollback to the previous revision and a request after scaling from idle. Those checks reveal whether the platform is merely able to run a container or whether the application is administratively ready.
For AZ-104, practice interpreting which service is being asked for: a private repository, a short-running container, or a managed service with deployment revisions and demand-driven replicas. Then identify the identity, network, lifecycle and monitoring decisions for each. The best answer follows the operational requirement rather than an assumption that the most feature-rich platform is always preferable.
Use a workload scenario to choose the platform
Suppose a research team needs to convert a fixed batch of files every weekend. A registry can store the image and a supported container execution service can run the bounded job with controlled permissions. Now change the requirement: the service must answer unpredictable public API traffic, scale with queue length, retain several application versions and let operators shift traffic gradually. Those demands make application revisions, ingress and scaling policy much more central to the choice of runtime. The container artifact may be identical, but the administrative answer changes because the workload contract changed.
A third case is a sensitive internal processor that must never receive internet-origin traffic. Before selecting its service, confirm whether it needs only outbound access to storage, internal service discovery or connections from a private corporate network. The chosen environment, ingress and registry identity must match that path. For every case, document how it starts, where it writes durable state, what restarts mean and who investigates a failed execution. This makes the service selection explainable rather than a product popularity contest.