6.7 Platform Compute Case Lab

Scenario

Contoso has three workloads moving to Azure. The first is a nightly invoice export that runs for 20 minutes and exits. The second is an orders API packaged as a container, expected to receive unpredictable HTTP traffic and later process queue events. The third is a customer portal currently hosted as a web app that needs custom domain TLS, staging deployments, backups, autoscale, and private access to a database.

The administrator must create a private image workflow, deploy the workloads, secure registry access, configure platform networking, and prepare operational controls. This is the kind of mixed scenario AZ-104 uses to test whether you can separate similar services.

Service selection

The service choice comes before the command. If you choose ACI for the orders API, you will struggle with revision rollout and event scale. If you choose Container Apps for the customer portal, you may lose familiar App Service operational features such as slots and built-in backup. If you choose App Service for the nightly invoice job, it may run, but it is not the simplest platform for a short container task.

Build the registry workflow

Create an ACR in a tier that supports the required network and replication features. Use Premium when private endpoint or geo-replication is required. Import base images or build application images into the registry. Assign runtime identities AcrPull instead of distributing registry admin passwords.

az acr create -g rg-platform -n contosoprodacr --sku Premium --location eastus
az acr build -r contosoprodacr -t jobs/invoice-export:v1 ./invoice-export
az acr build -r contosoprodacr -t apps/orders-api:v1 ./orders-api
az acr build -r contosoprodacr -t apps/customer-portal:v1 ./customer-portal

Exam trap: building and pushing an image does not deploy it. The target service must be configured to use the image. If the app still runs an old tag, update the container reference or deployment pipeline.

Deploy the invoice job with ACI

The invoice export runs nightly and exits, so deploy it as an ACI container group with CPU, memory, and restart policy that matches job behavior. OnFailure is appropriate if failed jobs should retry. Never is appropriate when retries are handled elsewhere. Store secrets as secure environment variables or pull them from a managed dependency where supported.

az container create \
  -g rg-platform \
  -n aci-invoice-export \
  --image contosoprodacr.azurecr.io/jobs/invoice-export:v1 \
  --cpu 2 \
  --memory 4 \
  --restart-policy OnFailure

Troubleshooting: if the job never starts, check ACR pull permissions and image tag. If it starts and fails, check logs. If it completes and then starts again unexpectedly, check restart policy and scheduling design.

Deploy the orders API with Container Apps

The orders API needs HTTP ingress and future event scaling. Create a Container Apps environment, deploy the app, configure external or internal ingress based on the requirement, set min and max replicas, and configure registry identity. If public access is required, external ingress is acceptable. If only internal services should call it, choose internal ingress.

az containerapp env create -g rg-platform -n cae-orders -l eastus
az containerapp create \
  -g rg-platform \
  -n orders-api \
  --environment cae-orders \
  --image contosoprodacr.azurecr.io/apps/orders-api:v1 \
  --target-port 8080 \
  --ingress external \
  --min-replicas 1 \
  --max-replicas 10

For a cost-sensitive queue worker, set minimum replicas to zero if cold start is acceptable. For the API, keep at least one replica if a warm endpoint is required. The exam will often include that one sentence to decide the setting.

Deploy the customer portal with App Service

Create a Linux App Service plan in a production-capable tier, then create the web app from the container image. Enable managed identity and assign pull permission to ACR. Configure app settings, connection strings, logs, and health checks before binding production traffic.

az appservice plan create -g rg-platform -n asp-portal-prod --is-linux --sku P1v3 -l eastus
az webapp create \
  -g rg-platform \
  -p asp-portal-prod \
  -n contoso-customer-portal \
  --deployment-container-image-name contosoprodacr.azurecr.io/apps/customer-portal:v1
az webapp identity assign -g rg-platform -n contoso-customer-portal

Add the custom domain by creating the DNS records shown in Custom domains. Bind the hostname, then bind a certificate and require HTTPS. Configure VNet integration for outbound private database access and make sure DNS resolves the database private endpoint from the integrated network.

Deployment slot workflow

Create a staging slot before the next release. Mark production database connection strings, API endpoints, and environment values as slot settings. Deploy the new container tag to staging, validate logs and health, warm it up, then swap. Keep the old version in the previous slot until monitoring confirms the release.

az webapp deployment slot create -g rg-platform -n contoso-customer-portal --slot staging
az webapp config appsettings set \
  -g rg-platform \
  -n contoso-customer-portal \
  --slot staging \
  --settings ENVIRONMENT=staging
az webapp deployment slot swap \
  -g rg-platform \
  -n contoso-customer-portal \
  --slot staging \
  --target-slot production

Rollback is another swap if the prior version remains healthy in the non-production slot. This is why direct deployment to production is usually a weaker answer when slots are available and the requirement says minimize downtime.

Backups and scaling

Configure App Service backups to a storage account before major releases and on a schedule that matches recovery needs. Verify that the plan tier supports backups. For scaling, use scale up when you need a higher tier, larger workers, or feature support. Use scale out when you need more instances. Use autoscale when capacity should follow metrics or schedules.

Autoscale should include minimum, maximum, and default instance counts. A rule with no max can create budget pressure. A rule with a max that is too low can fail during peak demand. Monitor CPU, memory, HTTP queue length, response time, and dependency errors.

Integrated troubleshooting drill

If the portal container returns 502 after a staging deployment, check image pull, container startup logs, expected port, app settings, and database connectivity. If private database calls fail but public endpoints work, check VNet integration, private DNS, database firewall, and managed identity permissions. If the custom domain fails only over HTTPS, check certificate binding and hostname. If the staging swap connects production to a test database, review slot settings.

If the orders API stops scaling, inspect min/max replicas, scale rule triggers, ingress, and downstream throttling. If the invoice job runs repeatedly, inspect restart policy and scheduling. If none of the services can pull images after ACR public access is disabled, inspect private endpoint, private DNS, and whether each runtime is on a network path that can reach the registry.

Exam traps checklist

Do not confuse storage, runtime, and hosting features. ACR stores images. ACI runs simple container groups. Container Apps runs scalable app containers with revisions. App Service hosts web apps with plan-based features, slots, domains, TLS, backups, and autoscale.

Do not choose public admin credentials when a managed identity and AcrPull satisfy least privilege. Do not use VNet integration as the answer for private inbound web app access. Do not forget that Microsoft exams may include interactive components and typically have 40-60 questions, but the count can vary; use Microsoft Learn access only for targeted lookup because no extra time is added.