You're a great admin... on-prem. Now, become a great admin in the cloud and prove it by passing the Microsoft Certified: Azure Administrator Associate exam!
Gauge your current knowledge
Gauge your current knowledge
Azure Container Registry (ACR) is a managed Docker registry that stores container images for Azure deployments. To authenticate without managing credentials, you can use a managed identity on an Azure resource such as a Linux virtual machine or an Azure Kubernetes Service (AKS) cluster. The identity can be user-assigned (created and managed separately) or system-assigned (tied to the resource’s lifecycle). The flow is: enable the identity on the resource, grant it a role like AcrPull on ACR, and then the resource uses that identity to pull images without storing any passwords.
You create a registry using the Azure CLI or Azure PowerShell. After creating the registry, you push a sample container image from a local Docker installation. Registry settings such as name, service tier, and public access are verified at creation time. The chosen tier (Basic, Standard, or Premium) determines storage limits, throughput, and whether advanced features like geo-replication are available.
Securing images means controlling who can pull or push to the registry. Managed identities are assigned roles with specific permissions, such as AcrPull for read-only access or AcrPush for write access. Azure Active Directory integrates as the authentication source, so no local admin accounts are needed. You should disable the built-in admin user account and rely on managed identities or service principals. Additional security policies can scan images for vulnerabilities before they are deployed.
Image management includes pulling from and pushing to the registry, tagging versions, and deleting outdated images. For registries on Azure Stack Edge devices, you must retrieve the endpoint details, download and install the device’s certificate, then sign in using Docker commands. The certificate establishes a trust boundary between the local tooling and the edge registry.
ACR offers three service tiers: Basic, Standard, and Premium. The Premium SKU is required for geo-replication, which synchronizes registry content across multiple Azure regions. When you choose a SKU, consider your throughput needs (number of concurrent pulls/pushes), storage capacity, and whether low-latency access in several regions is important. Geo-replication automatically ensures that a host in Europe pulls from a European replica, while a host in Asia pulls from an Asian replica, reducing network distance.
Administrators manage the lifecycle of container images through four operations: push (upload a new image), pull (download for deployment), tag (assign a version label), and delete (remove unused images). Proper tagging strategies, such as using semantic versioning or timestamps, enable rollback to a known-good version. Regularly deleting stale images reduces storage costs and keeps repository clutter low.
ACR supports service endpoints and private endpoints to restrict access to specific virtual networks. A private endpoint gives the registry a private IP address inside your VNet, so traffic never leaves the Microsoft backbone. Virtual network rules deny access from public IPs. Authentication is handled by managed identities (system-assigned or user-assigned), which let Azure resources like Azure Container Apps pull images without storing credentials. For the highest security, disable the admin user account.
ACR plugs into CI/CD pipelines and Azure services like Azure Kubernetes Service (AKS) and Azure App Service. You can set up continuous deployment: when an image is pushed, an automatic deployment updates the running application. ACR Tasks build and patch images in the cloud using the az acr build command, removing the need for a local Docker engine. Logs and diagnostics from the registry flow to Log Analytics, giving you metrics on push/pull activity and errors.
Geo-replication is a Premium-tier feature that manages a single registry across multiple Azure regions. The registry automatically replicates content to regional replicas, so container hosts pull from the nearest replica. This provides regional outage resilience (if one region fails, replicas in other regions remain available) and network-close access for globally distributed deployments. You manage one registry centrally, and replication uses Azure regional pairings to maintain data consistency during disaster recovery.
ACR Tasks automate image building, testing, and patching directly in the cloud. Using the az acr build command, developers can create images without a local Docker engine, streamlining the development pipeline. Tasks can trigger automatically on source code commits to a GitHub repository or when a base image (e.g., the OS layer) is updated. This ensures that images stay patched with the latest security fixes without manual intervention.
Webhooks and Azure Event Grid monitor registry events such as ImagePushed, ImageDeleted, or ChartPushed. When one of these events fires, it triggers an external workflow—for example, starting a CI/CD deployment when a new image version is pushed, or logging a deletion for auditing. This event-driven architecture keeps your container environment synchronized with the latest registry changes without polling.
To harden the registry further, disable public internet access and use Private Links, so only traffic from specific virtual networks reaches the registry. Attribute-Based Access Control (ABAC) provides fine-grained repository permissions based on image metadata or tags, ensuring a user or identity can only pull or push to specific repositories. The Domain Name Label (DNL) feature appends a unique hash to the registry’s DNS name, preventing subdomain takeover attacks. Managed identities with roles like AcrPull remain the recommended way to grant access without administrative credentials.
Azure Container Instances (ACI) is a serverless service that runs containers without requiring you to manage any underlying virtual machines. It is designed for isolated workloads that need to start quickly and scale on demand. The deployment process begins with storing your container image in an Azure Container Registry. To securely access this registry without embedding passwords, you can use managed identities, which are automatically handled credentials assigned to your VM or AKS cluster.
A key benefit of ACI is its ability to provide strong security boundaries. Confidential containers offer enhanced protection by running within a hardware-backed Trusted Execution Environment (TEE), such as those provided by AMD EPYC™ processors. This environment ensures data and code integrity through full guest attestation and secure policy enforcement. For data encryption, you can use customer-managed keys stored in Azure Key Vault, giving you control over the encryption keys for your container resources.
When creating a container instance, you define its basic properties, including a unique name, the operating system type, and the source of the container image. You must allocate CPU cores and memory appropriately to match your application’s needs. For private images stored in an Azure Container Registry, you must provide registry credentials so ACI can pull the image. You can also pass environment variables to the container at startup, which is the preferred method for injecting dynamic configuration like API endpoints without hardcoding them into the image.
Networking determines how your container is accessed. You can assign a public IP address and a DNS name label to give your container a public-facing web address. You must also open specific ports, such as TCP port 80 for web traffic, to allow communication. For more secure deployments, ACI supports virtual network integration, which places the container inside your private Azure network so it can communicate with other resources like databases without exposing them to the internet.
Because containers are stateless, any data written inside is lost when the container stops. To persist data, you mount an Azure File Share as a volume within the container instance. This allows the application to read and write files that survive container restarts or deletions. For security, you can enable a managed identity (either system-assigned or user-assigned) on the container, allowing it to authenticate to services like Azure Key Vault without handling secrets in your code.
To maintain a healthy application, you configure liveness probes and readiness probes. These checks tell Azure if the container is running correctly and ready to accept traffic, triggering restarts if necessary. You can also deploy container groups into specific availability zones to protect against failures within a single data center. Monitoring is done by viewing container logs directly in the Azure portal or by sending them to a log analytics workspace.
The cornerstone of security is using managed identities to grant your container access to other Azure services. This follows the principle of least privilege and eliminates the need to store passwords in your code or configuration. For storing sensitive data like connection strings, you should use Azure Key Vault. The container uses its managed identity to retrieve these secrets at runtime. When you must use environment variables, you should configure them as secure environment variables in your deployment to prevent them from being displayed in plain text.
Azure Monitor is the primary tool for tracking container performance and activity. It collects logs from the container’s standard output and error streams. By enabling Log Analytics, you can run detailed queries to audit activity and detect anomalies. You must configure diagnostic settings to send these logs to a workspace for long-term analysis. The Diagnose and solve problems tool in the portal provides automated troubleshooting for common configuration issues.
To prevent unauthorized access, you can deploy container instances into an Azure Virtual Network. This isolates them from the public internet and allows communication only through private endpoints. It is also critical to set resource limits for CPU and memory on your container groups. This prevents a single misbehaving container from consuming all available host resources and affecting other workloads, ensuring system stability and fair resource governance.
Azure Container Apps is a serverless platform that lets you run containerized applications without managing the underlying Kubernetes infrastructure. When you provision a container app, you first create an environment that acts as a secure boundary where multiple container apps live and share the same network and logging configurations. This environment handles the complex Kubernetes details so you can focus on your application code.
The container app definition includes a template section where you specify the container image and resource settings. You must define the vCPU and memory requirements based on the chosen workload profile, which determines the compute power available to your application. Advanced configurations allow for sidecar containers that run helper processes alongside your main app, init containers that run setup tasks before the main application starts, and environment variables that control application behavior.
Ingress rules determine how network traffic reaches your application and support both HTTP and TCP protocols. You can configure external ingress for public internet access or internal ingress to keep services private within your virtual network. The ingress proxy handles TLS termination to decrypt incoming traffic, provides session affinity for stateful connections, and allows IP restrictions to control who can access your endpoint.
Scaling policies in Azure Container Apps are powered by KEDA, an event-driven autoscaler that can scale your application to zero when there is no demand, saving costs on compute resources. You can trigger scaling based on HTTP traffic volume, CPU or memory utilization, or custom triggers like message queue depth. This automatic scaling responds to demand changes without manual intervention.
Secrets management stores sensitive data like API keys and connection strings securely. Secrets are defined at the application level and can be referenced as environment variables or mounted as files. For enhanced security, integrate with Azure Key Vault and use managed identities to pull images from private registries without hard-coding credentials.
Revision control creates immutable snapshots of your configuration, allowing you to manage the application lifecycle. You can use traffic splitting to direct specific percentages of users to different versions for Blue/Green deployments, which ensures high availability and lets you safely test new features before a full rollout.
Deploying a container app starts with choosing a container registry such as Azure Container Registry (ACR) or Docker Hub where your image is stored. You can deploy using the Azure portal, Azure CLI, or ARM templates. For example, the az containerapp up command creates the environment, registers the container app, and configures ingress in a single operation, specifying the image, target port, and whether the ingress is external or internal.
Environment variables configure your application behavior and can be set during app creation or later by creating a new revision. When you update environment variables, Azure Container Apps creates a new revision rather than modifying the running app, which preserves the ability to roll back if needed. This revision-based approach means you can update configuration without downtime.
Secrets in Azure Container Apps securely store sensitive configuration values that can be referenced from Azure Key Vault using URIs. To use Key Vault secrets, you enable a managed identity for your container app and grant it access to Key Vault. The app then retrieves secrets at runtime without exposing them in configuration files.
The deployment process involves building a container image in your Azure Container Registry, then specifying deployment settings such as the target port and ingress type. For applications requiring persistent storage, you can mount Azure File shares. The container app pulls the image from the registry, starts in the environment, and begins accepting traffic based on your ingress configuration.
An Azure Container Apps environment serves as the foundational host where container apps run and share network and logging infrastructure. Before creating an environment, you must register the Microsoft.App resource provider in your subscription. You can provision the environment through the Azure portal during initial container app creation or deploy it separately using the Azure CLI.
There are two primary environment types: Workload profiles and Consumption only. Workload profiles offer dedicated compute resources including memory-optimized or GPU-enabled instances for specific tasks, while Consumption only environments are designed for simpler workloads and do not support dedicated hardware or advanced egress controls like NAT Gateways. Choose workload profiles when your application needs consistent performance or specialized compute.
VNet integration is essential for building a secure foundation. Workload profile environments require a subnet with a minimum size of /27, while Consumption only requires a larger /23 subnet. This integration enables private endpoints and secure communication with other internal Azure services. Without proper VNet configuration, your containers cannot communicate privately with other Azure resources.
To achieve high reliability, enable zone redundancy during environment creation since this setting cannot be changed afterward. Zone redundancy automatically distributes application replicas across different physical data centers within a region, protecting against localized outages. For optimal resiliency, set a minimum replica count of three so your application remains available even if one zone fails.
Security and observability rely on managed identities and Log Analytics workspaces. A managed identity provides an automatically managed identity in Microsoft Entra ID that allows your app to access protected resources like Key Vault without embedding secrets in your code. A Log Analytics workspace collects and analyzes system logs, providing the detailed data needed to monitor complex microservice interactions and troubleshoot issues.
When deploying containerized applications, resource allocation is the first step to balance application stability against running costs. In Azure Container Apps, developers must configure specific combinations of CPU and memory, ranging from 0.25 vCPUs to 4.0 vCPUs in the consumption plan. Selecting the correct sizing strategy helps prevent performance bottlenecks and ensures that organizations do not pay for unused computing power.
Azure Container Apps offers different workload profiles to match specific application requirements. The Consumption plan is ideal for serverless, rapid-scaling tasks, while Dedicated profiles provide specialized hardware for resource-intensive workloads. Selecting the right profile ensures that memory-heavy or compute-heavy tasks have the necessary resources to run efficiently.
Specialized runtimes like Java require unique configurations because older Java Virtual Machine (JVM) versions might not automatically detect container boundaries. Using the MaxRAMPercentage flag ensures the JVM respects the memory allocated by Azure, which prevents Out-of-Memory (OOM) errors. Once the application is running, health probes monitor stability and dictate traffic flow:
Dynamic scaling allows Azure Container Apps to automatically adjust running instances in response to real-time traffic or system load. This is achieved through horizontal scaling, which scales out by adding container replicas or scales in by removing them. To power this process, the system relies on Kubernetes Event-driven Autoscaling (KEDA) to monitor external event sources and scale the containers accordingly.
Administrators configure scaling rules by specifying the minimum and maximum replica boundaries, such as setting a minimum of one replica and a maximum of ten replicas. These boundaries can be managed using the Azure CLI, ARM templates, Bicep, or the Azure portal. KEDA evaluates these rules and triggers scaling actions based on three main types of parameters:
When traffic drops, KEDA can scale applications down to zero replicas, which completely eliminates computing costs for idle workloads. However, when a new request arrives, it triggers a cold start, creating minor latency while the image pulls and the infrastructure provisions. To manage updates safely, developers use revision traffic splitting to route a percentage of traffic to new revisions, allowing for canary or blue/green deployments without causing application downtime.
Azure Container Instances (ACI) provide a fast and simple way to run isolated containers without the overhead of managing virtual machines or adopting complex orchestrators. Scaling in ACI focuses on defining clear policies based on workload demands to maintain both application responsiveness and cost efficiency. To manage this effectively, administrators must track performance metrics such as CPU utilization, memory usage, and network throughput.
To apply autoscaling policies to these container instances, administrators use Azure Monitor to set up automated rules. These rules react to changing resource demands or environmental patterns, helping to ensure the application remains cost-effective. These rules can be based on several different criteria:
Maintaining an optimal state in ACI requires a continuous lifecycle of monitoring and adjustment. First, administrators define autoscale rules in the Azure portal or via the Azure CLI. Next, they monitor performance metrics to verify that the active rules are handling the workload correctly. Finally, they adjust resource allocations as needed to preserve the desired level of service.
Azure Container Instances (ACI) is a serverless service that runs containers without requiring you to manage any underlying virtual machines. It is designed for isolated workloads that need to sta…
Azure Container Instances (ACI) is a serverless service that runs containers without requiring you to manage any underlying virtual machines. It is designed for isolated workloads that need to sta…
Azure Container Registry (ACR) is a managed Docker registry that stores container images for Azure deployments. To authenticate without managing credentials, you can use a managed identity on an…
Azure Container Registry (ACR) is a managed Docker registry that stores container images for Azure deployments. To authenticate without managing credentials, you can use a managed identity on an…
When deploying containerized applications, resource allocation is the first step to balance application stability against running costs. In Azure Container Apps, developers must configure spec…
When deploying containerized applications, resource allocation is the first step to balance application stability against running costs. In Azure Container Apps, developers must configure spec…
Azure Container Apps is a serverless platform that lets you run containerized applications without managing the underlying Kubernetes infrastructure. When you provision a container app, you firs…
Azure Container Apps is a serverless platform that lets you run containerized applications without managing the underlying Kubernetes infrastructure. When you provision a container app, you firs…
StudyCerts
StudyCerts