Node pools and scaling in Azure - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Node Pool Scaling Behavior

You have an Azure Kubernetes Service (AKS) cluster with two node pools: system and user. The system node pool is set to a fixed size of 3 nodes, and the user node pool has autoscaling enabled with a minimum of 1 and maximum of 5 nodes.

What happens when the workload on the user node pool increases beyond the capacity of 5 nodes?

A The <em>system</em> node pool automatically scales up to help with the <em>user</em> node pool workload.

B The <em>user</em> node pool scales beyond 5 nodes to handle the workload automatically.

C The cluster rejects new pods scheduled to the <em>user</em> node pool once it reaches 5 nodes, causing pending pods.

D AKS automatically creates a new node pool to handle the extra workload beyond 5 nodes.

💡 Hint

Think about the maximum node count set for autoscaling and how AKS manages node pools independently.

Autoscaling respects the maximum node count set for each node pool. Once the user node pool reaches 5 nodes, it cannot scale further. New pods that require more capacity remain pending until resources free up or manual scaling occurs.

❓ Configuration

intermediate

Configuring Node Pool Autoscaling Limits

You want to configure an AKS node pool named compute to autoscale between 2 and 6 nodes. Which Azure CLI command correctly sets this autoscaling configuration?

A az aks nodepool create --resource-group myRG --cluster-name myAKS --name compute --enable-autoscale --min-nodes 2 --max-nodes 6

B az aks nodepool scale --resource-group myRG --cluster-name myAKS --name compute --min-count 2 --max-count 6

C az aks update --resource-group myRG --name myAKS --nodepool-name compute --autoscale true --min 2 --max 6

D az aks nodepool update --resource-group myRG --cluster-name myAKS --name compute --enable-cluster-autoscaler --min-count 2 --max-count 6

💡 Hint

Remember that autoscaling is enabled or updated on existing node pools with specific flags.

The az aks nodepool update command with --enable-cluster-autoscaler, --min-count, and --max-count correctly configures autoscaling limits on an existing node pool.

❓ Architecture

advanced

Designing Node Pools for Mixed Workloads

You need to design an AKS cluster to run two types of workloads: latency-sensitive services and batch jobs. Latency-sensitive services require dedicated nodes with high availability, while batch jobs can run on cheaper, spot-priced nodes that can be preempted.

Which node pool architecture best fits this requirement?

A Create two node pools: one with standard VMs for latency-sensitive services and one with spot VMs for batch jobs, each with appropriate scaling policies.

B Use only spot VM node pools and rely on pod priority to manage latency-sensitive services.

C Create a single node pool with mixed VM sizes and enable autoscaling to handle both workloads.

D Create multiple node pools with spot VMs only and use taints to separate workloads.

💡 Hint

Consider workload isolation and cost optimization strategies.

Separating workloads into dedicated node pools allows tuning VM types and scaling policies per workload. Spot VMs are suitable for batch jobs but not for latency-sensitive services that require stability.

❓ security

advanced

Securing Node Pools with Azure AD Integration

You want to restrict access to the system node pool in your AKS cluster so that only cluster administrators can deploy pods there. Which approach enforces this security requirement?

A Use Azure AD RBAC to assign <code>Azure Kubernetes Service RBAC Cluster Admin</code> role only to administrators and use node pool labels with Kubernetes RBAC to restrict pod deployment.

B Enable network policies on the <code>system</code> node pool to block all traffic except from admin IPs.

C Use Azure Policy to deny pod creation on the <code>system</code> node pool for non-admin users.

D Configure pod security policies to allow only admin users to schedule pods on the <code>system</code> node pool.

💡 Hint

Think about combining Azure AD roles with Kubernetes RBAC and node labels.

Azure AD RBAC controls who can perform cluster admin actions. Kubernetes RBAC combined with node labels can restrict pod scheduling to specific node pools. This combination enforces deployment restrictions effectively.

❓ service_behavior

expert

Behavior of Node Pool Scaling with Multiple Workloads

An AKS cluster has two node pools: np1 and np2. Both have autoscaling enabled with min 1 and max 3 nodes. The cluster runs two deployments: app1 scheduled only on np1 and app2 scheduled only on np2.

If app1 suddenly requires 10 pods and app2 requires 2 pods, what is the expected scaling behavior?

A <code>np2</code> scales up to 3 nodes to help <code>np1</code> handle the extra pods from <code>app1</code>.

B <code>np1</code> scales up to 3 nodes but cannot satisfy all 10 pods, causing some pods to remain pending; <code>np2</code> scales to 2 nodes to handle <code>app2</code> pods.

C Both <code>np1</code> and <code>np2</code> scale to 3 nodes each to balance the load between deployments.

D <code>np1</code> scales beyond 3 nodes to handle all 10 pods; <code>np2</code> remains at 1 node since <code>app2</code> pods fit there.

💡 Hint

Remember that node pools scale independently and pods are scheduled only on their assigned node pools.

Each node pool autoscaler respects its max node count. np1 can only scale to 3 nodes, so it cannot run all 10 pods, leaving some pending. np2 scales to 2 nodes to run its 2 pods. Node pools do not share capacity.