Azure Red Hat OpenShift (ARO) is a fully managed, joint-engineered service from Microsoft and Red Hat that delivers OpenShift clusters on Azure. For the AZ-305 exam, this topic appears in Domain 4 (Infrastructure) under Objective 4.1: Design and implement a container orchestration solution. While not a primary focus, it represents a key decision point when choosing between Azure Kubernetes Service (AKS) and OpenShift. Expect 1-2 questions on ARO, primarily testing your understanding of its managed nature, integration with Azure AD, and when to recommend it over AKS. This chapter covers ARO's architecture, deployment, networking, identity, and operational considerations at the depth required for the exam.
Jump to a section
Imagine you want to manufacture a complex product. You could build a factory from scratch: pour concrete, install electrical, set up assembly lines, train workers, and manage inventory. That's running OpenShift yourself on Azure IaaS. Alternatively, you could lease a pre-built, automated factory from a supplier. The supplier provides the building, power, assembly lines, and even a baseline team of trained operators. You bring your product design (your containerized applications) and your specialized raw materials (container images). The supplier handles the factory floor layout (Kubernetes orchestration), worker scheduling (cluster autoscaling), and even routine maintenance (upgrades). You don't have access to the factory's electrical room (the underlying Azure infrastructure) but you can reconfigure the assembly lines (OpenShift cluster) via a control panel (the OpenShift web console and CLI). The supplier ensures the factory floor is always running the latest production line software (OpenShift updates) and will fix any broken machinery (self-healing). This is Azure Red Hat OpenShift: a fully managed OpenShift cluster where Microsoft and Red Hat jointly manage the control plane and infrastructure, while you focus solely on deploying and managing your containerized applications.
What is Azure Red Hat OpenShift?
Azure Red Hat OpenShift (ARO) is a fully managed Kubernetes service co-engineered and supported jointly by Microsoft and Red Hat. It provides a production-grade OpenShift cluster running on Azure infrastructure. The key distinction from AKS is that ARO delivers the full OpenShift platform, including its own container runtime (CRI-O), built-in CI/CD pipelines (OpenShift Pipelines based on Tekton), service mesh (OpenShift Service Mesh based on Istio), serverless (OpenShift Serverless based on Knative), and a developer-focused web console. ARO is intended for enterprises that require the complete OpenShift experience with a consistent hybrid cloud strategy, often because they already use OpenShift on-premises.
How ARO Works Internally
ARO is deployed as a set of Azure resources managed by Microsoft and Red Hat. When you create an ARO cluster, the following components are provisioned:
Control Plane: A set of three master VMs running the OpenShift control plane components (etcd, API server, controllers). These are managed and patched by Red Hat through the service.
Worker Nodes: A set of worker VMs that run your application pods. You can scale these manually or use cluster autoscaler.
Azure Infrastructure: The cluster is deployed into a dedicated Azure subscription managed by Microsoft. The VMs use Azure Disk or Azure File for persistent storage, and networking is provided by Azure Virtual Network with either OpenShift SDN or Azure CNI.
Red Hat OpenShift Cluster Manager: This is the management plane that handles cluster operations like upgrades, monitoring, and health. It runs in Red Hat's infrastructure and communicates with the cluster.
When you interact with ARO, you use the OpenShift CLI (oc) or web console. Authentication can be integrated with Azure Active Directory (Azure AD) via OAuth. The cluster's API server is exposed on a public or private endpoint (depending on configuration).
Key Components, Defaults, and Timers
Cluster Size: Minimum of 3 master nodes (Standard_D8s_v3) and at least 2 worker nodes (Standard_D4s_v3). Default worker node size is Standard_D4s_v3 (4 vCPU, 16 GB RAM).
Networking: By default, ARO uses OpenShift SDN with VXLAN encapsulation. You can also choose Azure CNI for direct VNet integration and faster pod networking. The default pod CIDR is 10.128.0.0/14, service CIDR is 172.30.0.0/16.
Storage: Default storage class is managed-premium (Azure Premium SSD). You can also use Azure Disk or Azure File with appropriate CSI drivers.
Updates: ARO supports two types of updates: platform updates (infrastructure and control plane) and OpenShift version updates. The service manages platform updates automatically, but you control OpenShift version updates via the OpenShift Cluster Manager. The default upgrade window is configurable.
Scaling: The cluster autoscaler is not enabled by default. You must configure it manually. It can scale based on pod resource requests.
Configuration and Verification Commands
To create an ARO cluster, you use the Azure CLI:
az aro create --resource-group myGroup --name myCluster --vnet myVnet --master-subnet masterSubnet --worker-subnet workerSubnetTo get cluster credentials:
az aro list-credentials --name myCluster --resource-group myGroupTo connect to the cluster using the OpenShift CLI:
oc login $(az aro show --name myCluster --resource-group myGroup -o tsv --query apiserverProfile.url) -u kubeadmin -p <password>To check cluster version:
oc get clusterversionInteraction with Related Technologies
ARO integrates with: - Azure Active Directory: For authentication, you can configure Azure AD as an OAuth identity provider. This allows users to log in with their Azure AD credentials. - Azure Monitor: You can enable Azure Monitor for containers to collect metrics and logs from the cluster. - Azure Policy: You can apply Azure policies to the ARO cluster via Azure Policy for Kubernetes. - Azure DevOps: ARO can be integrated with Azure Pipelines for CI/CD. - Azure Private Link: For private cluster access, you can deploy ARO in a private VNet and use Private Link to connect from on-premises.
Exam-Relevant Details
ARO is a joint service between Microsoft and Red Hat. Both companies provide support.
The control plane is fully managed by Red Hat. You cannot SSH into master nodes.
Worker nodes are accessible but managed by the service. You can add custom daemonsets or configurations via MachineConfig.
Pricing: ARO charges per cluster hour, plus the cost of underlying Azure VMs and storage. There is no additional license fee for OpenShift.
SLA: 99.95% uptime for the Kubernetes API server.
Regions: Available in most Azure regions, but not all. Check regional availability.
Network requirements: You must have two empty subnets (one for masters, one for workers) within the same VNet. The VNet must be in the same region as the cluster.
Upgrade process: You can upgrade the OpenShift version via the OpenShift Cluster Manager web console or API. The upgrade is rolling, with node draining and rebooting.
Common Exam Scenarios
When to choose ARO over AKS: If the organization already uses OpenShift on-premises and wants a consistent hybrid cloud experience, or if they need OpenShift-specific features like built-in CI/CD, service mesh, or serverless. Also, if they require Red Hat support.
When to choose AKS over ARO: If the team is already familiar with Kubernetes and doesn't need the extra OpenShift features, or if they want a more lightweight, cost-effective solution. AKS also has a larger ecosystem of add-ons.
Identity integration: The exam may ask how to configure Azure AD for ARO. The answer is to use OAuth with Azure AD as an identity provider in the OpenShift cluster.
Networking: Be aware of the default pod and service CIDRs, and that you can choose between OpenShift SDN and Azure CNI.
Trap Patterns
Trap: Thinking ARO is just AKS with OpenShift branding. Reality: ARO is a different service with a different architecture (e.g., CRI-O instead of containerd, different networking defaults).
Trap: Assuming you can manage the control plane nodes like in AKS. Reality: You cannot SSH into master nodes; they are fully managed.
Trap: Believing ARO is free. Reality: You pay for the underlying VMs, storage, and a per-cluster fee.
Trap: Thinking you can use any Kubernetes add-on. Reality: Some add-ons may conflict with OpenShift's built-in components. Always check compatibility.
Provision an ARO Cluster
First, you need an Azure subscription with the required resource providers registered: Microsoft.RedHatOpenShift, Microsoft.Compute, Microsoft.Storage, and Microsoft.Authorization. You also need a VNet with two empty subnets (one for master nodes, one for worker nodes). The subnets must be in the same VNet and region. Using the Azure CLI, run 'az aro create' with the resource group, cluster name, VNet, and subnet IDs. This command provisions the control plane and worker nodes. The process takes about 30-40 minutes. During this time, the service creates the master VMs, installs the OpenShift control plane, and configures networking. The worker nodes are then bootstrapped and join the cluster.
Configure Authentication with Azure AD
After cluster creation, you get a default kubeadmin user. For production, integrate Azure AD. In the OpenShift web console, go to Administration -> Cluster Settings -> Global Configuration -> OAuth. Add an identity provider of type 'Azure AD'. You need the Azure AD tenant ID, application ID, and client secret. This configures the cluster to authenticate users via Azure AD. Users can then log in with their Azure AD credentials. The integration uses OAuth 2.0. Once configured, you can delete the kubeadmin user for security. The exam expects you to know that Azure AD integration is done via OAuth identity provider configuration in OpenShift.
Deploy an Application
With authentication set up, you can deploy applications. Use the OpenShift web console or CLI. For example, to deploy an NGINX image, run 'oc new-app nginx:latest'. OpenShift creates a deployment, service, and route. The route exposes the application externally via a hostname (e.g., nginx-myproject.apps.example.com). The route uses the OpenShift router (HAProxy) running on the infrastructure nodes. The router proxies HTTP/HTTPS traffic to the service. For the exam, note that OpenShift routes are different from Kubernetes Ingress; routes support features like path-based routing, TLS passthrough, and load balancing algorithms.
Scale the Cluster
To scale worker nodes, you can either manually scale the node pool or enable cluster autoscaler. Manual scaling is done via 'az aro update' with the --worker-count parameter. For autoscaling, you need to install the cluster autoscaler operator from the OpenShift OperatorHub. The autoscaler automatically adds or removes worker nodes based on pod resource requests. The default scale-down delay is 10 minutes after pod requests drop below cluster capacity. The exam may ask about scaling considerations: you cannot scale master nodes; they are fixed at three. Also, scaling operations may take 5-10 minutes due to VM provisioning.
Perform an OpenShift Upgrade
OpenShift versions are updated via the OpenShift Cluster Manager. The cluster administrator can initiate an upgrade from the web console or CLI. The upgrade process is rolling: the cluster updates masters first (one at a time), then workers. Each node is cordoned, drained, updated, and rebooted. The entire upgrade can take 1-2 hours depending on the cluster size and the version gap. The exam may test that you cannot skip minor versions (e.g., from 4.10 to 4.12 requires going through 4.11). Also, platform updates (Azure infrastructure) are managed automatically by the service and do not require user action.
Enterprise Scenario 1: Hybrid Cloud with On-Premises OpenShift
A large financial services company runs OpenShift on-premises for their core banking applications. They want to extend capacity to Azure for burst scenarios and disaster recovery. They deploy ARO in a connected VNet using Azure ExpressRoute to extend their on-premises network. They configure Azure AD as the common identity provider, so users can authenticate with the same credentials. They use OpenShift's multi-cluster management (ACM) to manage both clusters centrally. A challenge they faced was networking: ensuring pod CIDRs don't overlap between on-premises and Azure. They solved it by using different CIDR ranges (e.g., on-premises 10.0.0.0/8, Azure 10.128.0.0/14). They also had to adjust firewall rules to allow communication between clusters. Performance considerations: they use Azure Premium SSD for stateful applications to ensure low latency. Misconfiguration example: initially, they forgot to enable VNet peering between the ARO VNet and their hub VNet, causing connectivity issues.
Enterprise Scenario 2: Regulated Industry with Compliance Requirements
A healthcare company needs to run containerized workloads that handle PHI (Protected Health Information). They choose ARO because it is HIPAA eligible and offers Azure Private Link for private cluster access. They deploy ARO in a private VNet with no public endpoints. They use Azure Policy to enforce encryption at rest (Azure Disk Encryption with SSE) and in transit (TLS). They also enable Azure Monitor with Log Analytics for audit logging. A common mistake: they initially exposed the OpenShift web console via a public route, violating compliance. They fixed it by disabling public routes and using Azure Private Link to access the console from their corporate network. Scaling: they use cluster autoscaler with a minimum of 3 and maximum of 20 worker nodes to handle variable workloads. Performance: they use Azure NetApp Files for persistent storage because of its high IOPS for database pods.
Enterprise Scenario 3: DevOps Transformation with CI/CD
A retail company adopts ARO to modernize their e-commerce platform. They use OpenShift Pipelines (Tekton) for CI/CD and OpenShift GitOps (Argo CD) for deployment. They integrate with Azure DevOps for source control and artifact storage. They use the OpenShift web console's developer perspective for easy application deployment. A challenge: they needed to integrate their existing Azure DevOps pipelines with OpenShift. They solved it by using the OpenShift service account token for authentication. Another issue: they had to configure cluster autoscaler to handle peak shopping seasons. They set the autoscaler to scale up aggressively (scale-up delay 0 seconds) and scale down slowly (scale-down delay 10 minutes) to avoid thrashing. They also use Azure Monitor to set alerts on CPU utilization and pod failures.
What AZ-305 Tests on Azure Red Hat OpenShift
AZ-305 Objective 4.1: Design and implement a container orchestration solution. The exam expects you to:
Compare ARO with AKS and know when to recommend each.
Understand the managed nature: control plane fully managed by Red Hat, workers managed but accessible.
Know the identity integration with Azure AD via OAuth.
Understand networking options: OpenShift SDN vs Azure CNI, default CIDRs.
Know the upgrade process and that platform updates are automatic.
Be aware of pricing: per-cluster fee plus Azure infrastructure costs.
Most Common Wrong Answers and Why
Choosing ARO for cost savings: Many candidates think ARO is cheaper than AKS. Actually, ARO includes an additional per-cluster fee on top of Azure infrastructure costs, making it more expensive. The correct answer for cost-sensitive scenarios is AKS.
Assuming you can manage master nodes: Candidates think you can SSH into master nodes like in AKS. Reality: master nodes are fully managed by Red Hat; you cannot access them.
Thinking ARO uses Docker: OpenShift has used CRI-O as the container runtime since version 4. ARO uses CRI-O, not Docker. This is a common trap.
Believing ARO supports all Kubernetes add-ons: OpenShift has its own ecosystem; some add-ons (e.g., certain CNI plugins) may conflict. Always check compatibility.
Specific Numbers and Values to Memorize
Default worker node size: Standard_D4s_v3 (4 vCPU, 16 GB RAM)
Default pod CIDR: 10.128.0.0/14
Default service CIDR: 172.30.0.0/16
Minimum cluster size: 3 master nodes, 2 worker nodes
SLA for API server: 99.95%
Upgrade process: rolling, cannot skip minor versions
Edge Cases and Exceptions
Private cluster: If you create a private ARO cluster, the API server and ingress are only accessible from the VNet. You must use Private Link or VPN to connect.
Multiple node pools: ARO supports multiple node pools (since OpenShift 4.8). You can have different VM sizes for different workloads.
Azure AD conditional access: You can integrate Azure AD conditional access policies to control access to the OpenShift cluster.
How to Eliminate Wrong Answers
If the question asks about a managed Kubernetes service with built-in CI/CD, service mesh, and serverless, the answer is ARO, not AKS. If the question mentions hybrid cloud consistency with on-premises OpenShift, choose ARO. If the question emphasizes cost and simplicity, choose AKS. Always look for keywords like 'Red Hat', 'OpenShift', 'built-in CI/CD', 'service mesh', 'hybrid' to indicate ARO.
ARO is a fully managed OpenShift service co-engineered by Microsoft and Red Hat.
Control plane is managed by Red Hat; you cannot SSH into master nodes.
Default worker node size is Standard_D4s_v3 (4 vCPU, 16 GB RAM).
Default pod CIDR: 10.128.0.0/14; service CIDR: 172.30.0.0/16.
Authentication integrates with Azure AD via OAuth identity provider.
Upgrades are rolling and cannot skip minor versions.
ARO includes a per-cluster fee plus Azure infrastructure costs.
These come up on the exam all the time. Here's how to tell them apart.
Azure Red Hat OpenShift (ARO)
Fully managed OpenShift platform by Red Hat and Microsoft
Uses CRI-O container runtime
Built-in CI/CD (OpenShift Pipelines), service mesh (Istio), serverless (Knative)
Supports OpenShift-specific features like Routes and Templates
Higher cost due to per-cluster fee and larger VM sizes
Azure Kubernetes Service (AKS)
Managed Kubernetes by Microsoft only
Uses containerd container runtime (or Docker historically)
No built-in CI/CD; relies on Azure DevOps or third-party tools
Standard Kubernetes API, no OpenShift extensions
Lower cost; only pay for Azure VMs and optional add-ons
Mistake
ARO is just AKS with a different name.
Correct
ARO is a different service built on OpenShift, which includes its own container runtime (CRI-O), networking (OpenShift SDN), and additional features like built-in CI/CD, service mesh, and a developer console. AKS is a vanilla Kubernetes service.
Mistake
You can SSH into the master nodes of an ARO cluster.
Correct
Master nodes are fully managed by Red Hat. You cannot SSH into them or modify their configuration. Only worker nodes are accessible, and even then, modifications should be done via MachineConfig or DaemonSets.
Mistake
ARO uses Docker as the container runtime.
Correct
OpenShift 4 uses CRI-O as the container runtime, not Docker. ARO inherits this. Docker support was deprecated in OpenShift 4.
Mistake
ARO is free; you only pay for Azure VMs.
Correct
ARO has a per-cluster hourly fee in addition to the cost of underlying Azure VMs, storage, and networking. This makes it more expensive than AKS.
Mistake
You can use any Kubernetes add-on with ARO.
Correct
OpenShift has its own operators and components. Some third-party add-ons (e.g., certain CNI plugins, ingress controllers) may conflict. Always verify compatibility with OpenShift.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Choose ARO when you need the full OpenShift platform, especially if you already use OpenShift on-premises and want a consistent hybrid cloud experience. Also choose ARO if you require built-in CI/CD, service mesh, or serverless capabilities. ARO is also preferred if your organization has a Red Hat subscription and wants joint support from Microsoft and Red Hat. For simpler Kubernetes needs or cost-sensitive scenarios, AKS is usually the better choice.
Azure AD integration is configured as an OAuth identity provider in the OpenShift cluster. You need an Azure AD application registration with a client secret. In the OpenShift web console, go to Administration -> Cluster Settings -> Global Configuration -> OAuth, and add an Azure AD identity provider. Users can then log in with their Azure AD credentials. The kubeadmin user can be deleted after integration.
Yes, you can specify custom VM sizes when creating the cluster using the --worker-vm-size parameter. You can also create multiple node pools with different VM sizes after cluster creation. However, the master nodes are fixed at Standard_D8s_v3 and cannot be changed.
ARO supports two networking options: OpenShift SDN (default) and Azure CNI. OpenShift SDN uses VXLAN encapsulation and provides network isolation via projects. Azure CNI gives each pod an IP from the VNet, enabling direct connectivity with Azure resources. Azure CNI requires more IP addresses but offers better performance and integration.
Platform updates (Azure infrastructure) are managed automatically by the service. OpenShift version updates are user-initiated via the OpenShift Cluster Manager. You cannot skip minor versions; you must upgrade sequentially. The upgrade process is rolling, with nodes being cordoned, drained, updated, and rebooted one at a time.
ARO pricing includes a per-cluster hourly fee (approximately $0.40 per hour for the control plane) plus the cost of underlying Azure resources: VMs (master and worker), storage (Azure Disk or File), and networking (public IPs, bandwidth). There is no additional OpenShift license fee. The total cost is typically higher than AKS due to the control plane fee and larger default VM sizes.
Yes, you can create a private ARO cluster by using the --private parameter. This makes the API server and ingress only accessible from the VNet. You can then use Azure Private Link or a VPN gateway to connect from on-premises or other networks. The web console is also private and requires connectivity to the VNet.
You've just covered Azure Red Hat OpenShift — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?