{"id":3971,"date":"2026-10-11T18:43:46","date_gmt":"2026-10-11T18:43:46","guid":{"rendered":"https:\/\/www.examtopics.info\/blog\/az-104-acr-aci-container-apps\/"},"modified":"2026-10-11T18:47:59","modified_gmt":"2026-10-11T18:47:59","slug":"az-104-acr-aci-container-apps","status":"publish","type":"post","link":"https:\/\/www.examtopics.info\/blog\/az-104-acr-aci-container-apps\/","title":{"rendered":"Azure Containers in AZ-104: ACR, ACI, and Apps"},"content":{"rendered":"

An Azure container image does not become a running production service just because it has been pushed to a registry. The Microsoft AZ-104 exam<\/a> includes deploying and managing container-related Azure resources: understanding the difference between image storage, a scheduled or on-demand container instance, and an application runtime that provides revisions, ingress and scaling.<\/p>\n

Suppose a team publishes a nightly conversion tool and a separate customer-facing API from the same repository. The registry can store both images, but the execution model should be chosen for the workload. One tool runs for twenty minutes and exits; the API needs a stable endpoint, revision control, request-driven scale and error monitoring. Matching the platform to each need matters more than memorizing service acronyms.<\/p>\n

Treat Azure Container Registry as a supply-chain boundary<\/h2>\n

Azure Container Registry (ACR) stores container images and related artifacts. It does not by itself execute them. The image should have a traceable build provenance, a stable version reference and clear access rules. Mutable tags such as ‘latest’ are convenient for experiments but can make a rollback or incident investigation ambiguous if the underlying image changes after deployment.<\/p>\n

Choose image permissions so build identities can push to the intended repository and runtime identities can pull only what they need. Managed identity<\/a> support and registry authentication details depend on the consuming service. Avoid embedding a long-lived registry admin password into deployment configuration. Record which digest was deployed so a security update can be tied to a specific artifact rather than a marketing release name.<\/p>\n

A registry controls artifacts the runtime will execute. For a regulated workload, ask who can push an image, who can pull it, whether tags are mutable, how vulnerable or obsolete images are found, and how deployment verifies that the intended build is being used. A trusted image name does not guarantee the tag still points to the reviewed digest. Use versioned images or immutable digests where your release controls require them, and assign registry roles to workload identities rather than embedding long-lived admin credentials. Test a failed image pull separately from application crash loops to avoid blaming the container code for a registry authorization problem.<\/p>\n

Recognize when Azure Container Instances fits<\/h2>\n

Azure Container Instances (ACI) is useful for relatively direct container execution without managing a VM cluster. Container groups provide the scheduling unit; resource settings, environment variables, restart policy and network configuration affect the run. A short batch workload may benefit from the simplicity, while a sophisticated web application’s traffic control and deployment management could be awkward to recreate manually.<\/p>\n

Consider a container that starts, processes an exported file and terminates. Its restart behavior should reflect whether a nonzero exit means transient failure or bad input. An infinite restart loop can repeat an invalid destructive operation. Inspect logs, exit status and resource limits and design the process to be safe when restarted after partial completion.<\/p>\n

Azure Container Instances fits certain bursty or stand-alone jobs when you want an Azure-managed container runtime without operating a VM cluster. Consider a quarterly CSV conversion that runs for minutes, writes results to a storage service and then stops. The task needs an image, environment configuration, network route, identity for its output and a clear completion signal; it may not need service discovery or advanced application revisions. A continuously serving public API with sophisticated traffic management has different needs. Do not force it into ACI simply because the first ‘run container’ command is easy to understand.<\/p>\n

Understand the Container Apps operational model<\/h2>\n

Azure Container Apps is an application platform for containerized workloads with managed ingress, revisions and scaling. It can suit web APIs, microservices and event-driven jobs. Revisions are immutable snapshots of revision-scoped configuration; some application-scope settings can change without creating a new revision. The distinction is essential when diagnosing why a new image version is serving traffic while a changed secret has not taken effect inside a running container.<\/p>\n

For customer-facing traffic, define ingress exposure, authentication expectations, health probes, revision mode and autoscale boundaries. Multiple-revision mode can support controlled traffic splitting, but it does not make incompatible database migrations safe automatically. If state changes across revisions, test old and new code against the shared dependency during the transition.<\/p>\n

Container Apps separates application revision lifecycle, ingress and scaling from direct container orchestration. A revision can represent one immutable deployable configuration, while environment-level concerns such as network integration, logging and application communication remain shared. Choose a revision strategy based on whether traffic must shift gradually or a new release should replace its predecessor directly. An operator troubleshooting a new revision must identify which revision receives requests, which image digest and secrets it uses, and whether scale-to-zero is intentional. A healthy container process is not enough when ingress directs traffic to another revision or a dependent service cannot be resolved.<\/p>\n

Make ingress and network access intentional<\/h2>\n

A container that can run successfully inside a managed environment might still need a private endpoint, controlled outbound connectivity or restricted ingress to satisfy policy. Public ingress is not automatically appropriate for a service that processes internal financial documents. Review the platform’s supported network and environment configuration rather than assuming every ACI and Container Apps networking option is interchangeable.<\/p>\n

Troubleshoot the access path in layers: DNS, network routing, TLS, ingress and application authentication. A 403 from an application has a different cause from a missing route to an internal endpoint. Don’t fix a network reachability problem by removing all access control; the right endpoint may require a controlled private path and a valid workload identity.<\/p>\n

Network design should start from callers and dependencies. Does the container require a public HTTPS endpoint, a private connection from an internal application or only outbound access to a queue? A public ingress setting is not a substitute for authentication, and adding a private network path does not create data-plane permissions at Storage or Key Vault. Document DNS names, permitted sources, outbound firewall rules and what happens when the image registry itself is private. Validate each hop from a test caller, rather than testing only that the platform resource reached a ‘Running’ state.<\/p>\n

Use managed identity to retrieve secrets and images<\/h2>\n

A containerized workload commonly needs Key Vault access, storage access or registry image pulls. Managed identities can reduce the need to store credentials, subject to each service’s support and configuration. Identity provisioning and Azure role assignments are distinct tasks: the runtime may have a valid identity that still lacks the target service’s data action.<\/p>\n

For example, a worker reads from Blob Storage but cannot start because it cannot pull its private registry image. Troubleshoot the registry pull identity before adding Blob Data Reader. If the image pulls but file reads fail, verify the storage role and network access separately. Use the least powerful identity for the specific workload boundary; do not grant subscription-wide Contributor to make a container start.<\/p>\n

A managed identity assigned to the runtime can eliminate registry passwords or downstream API secrets in supported scenarios, but it does not grant automatic access. Give an image-pull role to the actual identity that retrieves the image, and narrow data-plane roles for storage or queue operations. If a deployment returns an unauthorized registry error, first confirm the identity selected by the service and its role assignment. If the image starts but the worker cannot write to the blob container, that is a separate authorization path. Splitting those paths reduces the temptation to distribute a powerful registry admin key throughout the deployment system.<\/p>\n

Control scale, cost and capacity<\/h2>\n

A continuously running service and a scheduled job have different consumption patterns. Set minimum and maximum replicas according to cold-start sensitivity, workload spikes and cost tolerance. Container Apps can scale with supported HTTP, TCP or event signals, but event backlog and downstream rate limits still need explicit protection. Scaling a consumer more aggressively than a database can handle may turn a small queue into a downstream outage.<\/p>\n

For an occasional document conversion process, a job model or short-lived container may be economical. For a latency-sensitive API, keeping warm replicas can be justified. Measure real request latency, container startup time, retry rate and spending under test conditions. Compare a platform’s claimed scalability with the team’s operational skills and expected release frequency.<\/p>\n

Diagnose failures from artifact to process<\/h2>\n

When deployment fails, inspect whether the image reference exists and is accessible, whether startup configuration is valid and whether resource limits support the process. If the container starts then exits, examine application logs and restart settings. If it runs but cannot serve a request, inspect the ingress and readiness path. A successful image push is not a complete release verification.<\/p>\n

An effective runbook records the registry digest, environment or container group, execution identity, network configuration, revision or image version and failure symptoms. This makes it possible to determine whether a previous release can be restored without assuming every failure is a software bug. Keep secret values out of logs even while making diagnostics useful.<\/p>\n

Design a three-way AZ-104 service selection case<\/h2>\n

Write down three workloads: a manually triggered test that finishes in minutes, a nightly bulk processor, and a public API with variable demand. Decide which service fits each one, how its image is obtained from ACR and what events require an alert. The exercise should mention cost, identity, ingress, logs and restart semantics, not just the three product names.<\/p>\n

Then deliberately break one image pull by withholding registry access and one storage operation by withholding the correct data-plane role. Recover each without broad role grants. A successful lab demonstrates that the administrator knows which service owns which part of the container’s lifecycle and how to troubleshoot its boundaries.<\/p>\n

For an AZ-104 choice question, use three workloads: a short-lived import, a continuously running internal web service with revision-based rollout, and a long-lived custom server needing guest-OS extensions. The import may fit ACI; the managed HTTP workload may fit Container Apps or App Service<\/a> depending on its features; the custom server may justify a VM. Document why each choice meets networking, identity, cost and lifecycle requirements. In a lab, build and push a minimal safe image, deploy to one supported runtime and intentionally revoke its pull role in a disposable environment to see how image access failures surface. Restore the role and verify the running digest.<\/p>\n","protected":false},"excerpt":{"rendered":"

Choose Azure Container Registry, Container Instances and Container Apps, then configure image access, ingress and operational scaling.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8,11],"tags":[],"class_list":["post-3971","post","type-post","status-publish","format-standard","hentry","category-certifications","category-cloud-computing"],"_links":{"self":[{"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/posts\/3971","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/comments?post=3971"}],"version-history":[{"count":1,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/posts\/3971\/revisions"}],"predecessor-version":[{"id":3997,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/posts\/3971\/revisions\/3997"}],"wp:attachment":[{"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/media?parent=3971"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/categories?post=3971"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/tags?post=3971"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}