The current AZ-104 compute objectives include creating and managing Azure Container Registry, provisioning containers with Azure Container Instances and Azure Container Apps, managing container sizing and scaling, and administering Azure App Service plans and apps. The AZ-104 exam can therefore test several hosting models that all run applications but expose different operational responsibilities.
The exam-friendly way to approach the topic is to ask how much platform management the workload needs. A single container instance, a scalable container application, and an App Service web application are not interchangeable simply because each can host code. The deployment artifact, scaling model, networking, state, and operational controls should drive the choice.
Understand the role of Azure Container Registry
Containerized workloads need a reliable place to store and distribute images. Azure Container Registry provides that image registry inside Azure and becomes part of the deployment chain for Container Instances, Container Apps, and other container platforms. Administrators should think about image identity, versioning, access, and how deployments authenticate to the registry.
If the container model itself is unfamiliar, the existing Docker fundamentals material can clarify images and containers. For AZ-104, move quickly from the concept to Azure operations: create the registry, make the image available, and ensure the target runtime can pull it without exposing unnecessary credentials.
Image tags are convenient, but operational processes should make deployed versions traceable. A production incident is easier to investigate when the team can identify the exact image digest or release associated with the running instance.
Use Container Instances for simple container execution
Azure Container Instances provide a straightforward way to run containers without managing virtual machines. They fit workloads that need container isolation and rapid provisioning but do not require a full orchestrator or a complex application platform. The administrator still needs to size resources appropriately and configure networking and environment settings.
Do not assume that “container” automatically means Kubernetes. The current AZ-104 objective specifically calls out Container Instances and Container Apps. The correct answer may be the simpler service when the scenario asks for a small, isolated container workload with minimal platform management.
The key is matching runtime complexity to the requirement. Adding an orchestration layer that the workload does not need increases operational work without improving the outcome.
Use Container Apps for scalable application-style container workloads
Azure Container Apps provides a managed environment for containerized applications with application-oriented scaling and revision concepts. It is a stronger fit when the workload needs a managed container application platform rather than one isolated container execution. Sizing and scaling decisions remain part of the administrator’s responsibility.
State should be treated carefully. Containers are designed around replaceable instances, so important state should not depend on the local lifetime of one running replica. External data services, storage, or other durable components should hold information that must survive scaling and replacement.
The distinction between a pod and a container is explained in the existing pods and containers discussion, but AZ-104 does not require turning every Azure container question into a Kubernetes design. Focus on the Azure services named in the current blueprint.
Know what an App Service plan controls
Azure App Service separates the application from the App Service plan that provides compute capacity. The plan affects region, pricing tier, available features, and scaling capacity for the apps hosted on it. If several apps share a plan, they also share the underlying plan resources, which can affect performance and cost decisions.
Scaling can mean changing the capacity or characteristics of the plan as well as increasing the number of instances. Read the scenario carefully to determine whether the problem is insufficient instance capability or the need for more instances to handle load.
An App Service is a platform-managed web application environment. The administrator configures the app and plan rather than managing the underlying guest operating system like a VM.
Configure TLS, custom domains, and networking as separate concerns
The blueprint includes certificates and TLS, custom DNS names, networking settings, and backup for App Service. These are independent administrative areas even though they are often configured for the same application. Mapping a domain name does not by itself prove the TLS certificate is correct, and enabling TLS does not define how the application reaches private backend services.
Networking requirements may include inbound access, outbound connectivity, or integration with other Azure resources. Identify the traffic direction and security boundary before changing settings. A web application that must call a private database has a different problem from an application that must accept public traffic under a custom hostname.
Treat certificates as lifecycle items. Expiration and replacement should be operationalized rather than discovered during an outage.
Use deployment slots to reduce release risk
Deployment slots allow an App Service application to maintain separate deployment environments under the same app context and can support controlled swaps. They are useful when a new version should be validated before it becomes the production experience. Slot-specific settings need careful handling so environment configuration does not move unexpectedly.
This is a release-management feature, not simply another copy of the application. Use it to separate deployment validation from production traffic and to create a safer transition path. The exact release process should still include application testing and monitoring after the swap.
For exam scenarios, look for wording about staging, minimizing deployment interruption, validating a new version, or swapping environments.
Choose between VM, container, and App Service by operational responsibility
The container-versus-hypervisor distinction provides useful background: VMs expose a full guest operating system, while containers package applications with a lighter abstraction. App Service removes even more infrastructure responsibility by giving the application a managed web-hosting platform.
A requirement for full operating-system control points toward a VM. A requirement to run a packaged container may fit Container Instances or Container Apps depending on application and scaling needs. A conventional web application that benefits from managed deployment, custom domains, TLS, backups, networking, and slots may fit App Service.
The exam rarely needs philosophical debates about which model is universally best. It needs the service whose responsibility boundary matches the scenario with the least unnecessary management.
Practice the hosting decision as a sequence
Start by identifying the deployment artifact: machine image, container image, or application package. Next decide whether the workload needs operating-system control. Then identify scaling needs, state requirements, networking constraints, and release strategy. That sequence narrows the hosting choice quickly.
Finally, connect the result back to the wider Microsoft certifications only as context. AZ-104 expects you to administer the selected service: registry access for containers, sizing and scaling for Container Instances or Container Apps, and plan, TLS, domains, backup, networking, and slots for App Service.
Build one small reference application three ways and compare what you are responsible for in each model. The exercise makes the platform boundaries memorable and helps you recognize which administrative burden a scenario is trying to remove.
Operate scaling without confusing platform models
Scaling looks different across the services in this domain. Container Instances are typically provisioned as discrete container groups with explicit resources. Container Apps can scale application replicas according to configured behavior. App Service scales through the App Service plan and app configuration. The common word “scale” should not hide those platform differences.
For each scenario, identify whether the problem is per-instance capacity or the number of instances. Then check whether the application is stateless enough to add replicas safely. If sessions or files live only on one instance, scaling out can expose design problems that were invisible on a single host.
Monitoring should validate the result. Adding replicas is useful only if throughput, latency, or availability improves as intended. Cost and limits also matter because automatic scaling without guardrails can create unexpected consumption.
Treat App Service backup and networking as operational dependencies
App Service backup configuration belongs to the application’s recovery plan, while networking settings determine how the app reaches or is reached by other resources. Neither should be added only after an incident. Understand what data and configuration the backup covers, where it is stored, and how restoration will be tested for the workload.
Networking should be read directionally. A requirement for private outbound access to a backend is not the same as restricting inbound public traffic. DNS, certificates, custom domains, and network integration can interact, but each solves a different part of the application path. Troubleshoot from client to app and from app to dependency rather than changing several settings at once.
The exam can combine hosting and networking in one story. Keep the hosting choice separate from the connectivity control so you can explain why both are needed.
Use a responsibility matrix for exam decisions
A quick responsibility matrix can clarify the choice. With a VM, you manage the guest operating system and most of the runtime environment. With a container service, you package the application and configure the container runtime while Azure manages more of the infrastructure. With App Service, you focus on the web application, plan, scaling, deployment, domain, TLS, networking, and backup settings exposed by the platform.
When a scenario asks for least administrative effort, the service with the smallest responsibility boundary that still meets the requirement is often attractive. When the application requires operating-system customization, that same managed service may be too restrictive. The correct choice follows the workload constraint, not a universal preference for one hosting model.
Practice by rewriting one scenario three times so that a different requirement forces each hosting option. That makes the decision boundary much easier to recognize under exam pressure.
Continue exploring the technologies and certification concepts that matter most to you.