Manage Containers and App Service for AZ-104

Understand Azure Container Registry, Container Instances, Container Apps, and App Service administration for AZ-104.

This part of AZ-104 is about administrative fluency across lighter-weight application hosting options. You are not being tested as an application developer. You are being tested on whether you can provision, connect, scale, and maintain the hosting surface that the scenario calls for.

What Microsoft explicitly includes

The current outline covers Azure Container Registry, Azure Container Instances, Azure Container Apps, sizing and scaling for containers, App Service plans, App Services, certificates and TLS, custom DNS names, backups, networking settings, and deployment slots.

The operational frame to use

ACR stores images. ACI runs simple container workloads quickly. Container Apps adds a managed app platform with scaling and ingress behavior. App Service is the higher-level web app platform with plan-based compute, deployment slots, and common web-hosting controls. If you know which layer each service owns, many exam questions become much easier.

Common traps

The common misses are mixing up the App Service plan and the app itself, assuming every container scenario needs the same platform, and forgetting that networking, TLS, and deployment slots are part of operations, not optional polish.

Lab moves worth practicing

  • push an image into Azure Container Registry
  • deploy one simple workload to ACI or Container Apps
  • create an App Service, attach a custom domain, and inspect the plan and slot configuration

Hosting chooser

NeedStrongest first fitWhy
Store and manage container imagesAzure Container RegistryIt is the image registry, not the runtime
Run a simple container quickly with minimal platform setupAzure Container InstancesLightweight container execution
Run a containerized app with managed scaling and ingressAzure Container AppsHigher-level app platform for container workloads
Host a web app with plan-based compute, slots, TLS, and common web controlsApp ServiceMature managed web-hosting platform

App Service admin checklist

If a question leans toward App Service, look for these operational controls:

  • the App Service plan decides region, pricing tier, and scale boundary
  • the web app carries app-specific configuration and deployment behavior
  • deployment slots reduce release risk by giving you a staging path before swap
  • custom domains and certificates control the public hostname and TLS posture
  • backups and networking settings improve recoverability and connectivity, but they do not replace a full disaster-recovery design

Container runtime chooser

Use ACI when you want the smallest, quickest container runtime with minimal platform scaffolding. Use Container Apps when you need a managed application platform with ingress and scale behavior. Use App Service when the scenario is clearly web-app administration with slots, custom domains, TLS, and the rest of the App Service operating model.

Objective coverage inside this page

This one page carries two dense objective groups, so keep the boundaries clear:

  • containers: ACR, ACI, Container Apps, and sizing or scaling decisions
  • App Service: plan provisioning, plan scaling, app creation, TLS and certificates, custom DNS, backups, networking settings, and deployment slots

If the scenario is mostly about image storage or lightweight container execution, stay on the container side. If it is about managed web-hosting operations, shift to the App Service side.

Bicep example: App Service plan and app boundary

This example shows the distinction between the compute plan and the hosted app.

 1resource plan 'Microsoft.Web/serverfarms@2023-12-01' = {
 2  name: 'app-plan'
 3  location: resourceGroup().location
 4  sku: {
 5    name: 'P1v3'
 6    capacity: 1
 7  }
 8  kind: 'linux'
 9  properties: {
10    reserved: true
11  }
12}
13
14resource app 'Microsoft.Web/sites@2023-12-01' = {
15  name: 'examdemo-web'
16  location: resourceGroup().location
17  properties: {
18    serverFarmId: plan.id
19    httpsOnly: true
20  }
21}

What to notice:

  • the plan is the compute boundary that controls scale tier and region
  • the app attaches to that plan and carries workload-specific behavior
  • httpsOnly belongs to the app-level operational posture, not to the abstract idea of “having a website”

Deployment slots are a release-control feature

Slots matter on AZ-104 because they reduce release risk without forcing a brand-new production cutover every time.

    flowchart LR
	  B["New build"] --> S["Staging slot"]
	  S --> V["Validate config, TLS, and app behavior"]
	  V --> W["Swap into production"]

The lesson is simple: a slot is not just another app copy. It is a safer deployment path that lets you validate before production traffic takes the new version.

Quiz

Loading quiz…

The next domain is Virtual Networking, where most of these compute services start interacting with real connectivity and security constraints.