Describing Containers in Azure

Core container concepts (non-Azure specific)#

Dockerfile: the “recipe” that defines:

your app code

dependencies/libraries

runtime/config instructions needed to run it

Container image: the built artifact produced from the Dockerfile (a portable “package”). It’s not running yet—it’s like a VM image/template.

Container registry: a repository for storing and versioning images (e.g., Docker Hub, or Azure Container Registry).

Container host/runtime: where images are pulled and started as running containers (e.g., Docker host, Kubernetes, Azure services).

Why containers exist (the “works on my machine” problem):#

Before containers: apps often failed elsewhere due to missing dependencies or config drift.

With containers: the image carries the dependencies + runtime expectations, so it runs consistently across environments.

What the Azure demo did (step-by-step, conceptually)#

1) Create an Azure Container Registry (ACR)#

• ACR is Azure’s managed private registry: <registryname>.azurecr.io
• Picked a pricing tier (Standard in the demo).
• Chose networking defaults (public endpoint in the demo, but private is possible).

Important security note from the demo:#

Enabled Admin user (access keys) to simplify authentication for the lab. In real environments, you typically avoid admin user and prefer Entra ID/RBAC (more below). ()

2) Pull sample app code (Git clone)#

Cloned a repo containing:

• Python app (Flask)
• requirements.txt

Dockerfile#

3) Review the Dockerfile (what it’s doing)#

Typical pattern shown:

• Base image: python:3.8-slim
• WORKDIR /app
• COPY app + requirements into the container filesystem
• pip install -r requirements.txt
• EXPOSE 80
• CMD runs the Flask app

4) Build + push the image using ACR Tasks (no local Docker build needed)#

Used az** acr build** to:

• send the source context to ACR
• build remotely (ACR Tasks)
• push the resulting image into the registry
• This is a common “cloud build” workflow and is part of ACR Tasks capabilities. ()

5) Verify the image exists in ACR repositories#

After the build, the ACR Repositories blade shows something like:

• sample/hostnameapp
• tag v1

6) Run a quick test execution from ACR#

Used az** acr run** to run a container “on demand” (good for quick validation)

In the portal, this appears under Tasks → Runs (build run + run command history)

Deeper understanding & “exam-worthy” details#

ACR authentication options (what to use when)#

Common methods (best practice order in many orgs):

• Microsoft Entra ID + Azure RBAC (recommended for users/automation)
• Managed Identity (best for Azure resources pulling/pushing without secrets)
• Service principal (CI/CD scenarios where MI isn’t possible)
• Admin user (username/password) (easy for labs; generally avoid in production)
• The “push/pull using Docker CLI” walkthrough shows ACR sign-in patterns and discusses authentication approaches. ()

RBAC roles you’ll see a lot#

• AcrPull: pull images
• AcrPush: push + pull
• Owner/Contributor: broader management (use sparingly)
• These built-in roles are central to securing ACR access.

ACR Tasks vs local Docker build#

Why ACR Tasks (az acr build) is useful#

• Build happens in Azure (repeatable environment)
• No need for Docker installed on your machine/agent
• Logs are captured, and runs are tracked
• Fits CI/CD patterns well ()

Networking hardening (big in real projects)#

Two common patterns:

• Public endpoint (simple; restrict with firewall rules where possible)
• Private Link / private endpoint (preferred in enterprise): access ACR privately from VNets, block public network access ()

Where you run the image after it’s in ACR#

Once images are in ACR, you typically run them on:

• AKS (Kubernetes)
• Azure Container Instances (ACI)
• App Service (Web App for Containers)
• other container platforms
• Example: ACI can pull images from ACR as part of its workflow. ()

Quick mental model to remember#

Dockerfile → Image → Registry → Host → Running container#

In Azure demo terms:

Dockerfile/code → built by ACR Tasks → stored in ACR → validated via az** acr run** → then typically deployed to AKS/ACI/App Service

If you want, paste the next transcript (or tell me which AZ-104 objective you’re mapping this to), and I’ll convert it into an “exam cheat sheet” format: terms → key facts → common pitfalls → 5 likely exam questions + answers.