Why managed Kubernetes matters in Azure - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why choose managed Kubernetes over self-managed?

Which of the following is the main advantage of using a managed Kubernetes service like Azure Kubernetes Service (AKS) instead of setting up Kubernetes manually?

A You get full control over every node without any restrictions.

B You must manually install and configure all Kubernetes components.

C The cloud provider handles cluster maintenance and upgrades automatically.

D Managed Kubernetes does not support scaling applications automatically.

💡 Hint

Think about who takes care of updates and maintenance in managed services.

Managed Kubernetes services like AKS automate cluster maintenance, upgrades, and patching, reducing manual work and errors.

💻 Command Output

intermediate

Output of AKS cluster creation command

What is the expected output after successfully running this Azure CLI command to create an AKS cluster?

az aks create --resource-group myResourceGroup --name myAKSCluster --node-count 3 --enable-addons monitoring --generate-ssh-keys

A Provisioning succeeded with cluster details including node count and monitoring addon status.

B Error: SSH keys are missing and must be provided manually.

C Command runs but no cluster is created or shown in Azure portal.

D Syntax error: missing required parameters for node count.

💡 Hint

Check what the command does with the --generate-ssh-keys flag and monitoring addon.

The command creates a 3-node AKS cluster with monitoring enabled and generates SSH keys automatically, resulting in a success message with cluster details.

🔀 Workflow

advanced

Correct order to deploy an app on AKS

Arrange the steps in the correct order to deploy a containerized app on Azure Kubernetes Service (AKS).

A 1,2,3,4

B 3,2,1,4

C 1,3,2,4

D 2,1,3,4

💡 Hint

Think about what must exist before deploying the app and applying configs.

You first create the cluster, then build and push the image, prepare deployment files, and finally apply them to the cluster.

❓ Troubleshoot

advanced

Diagnosing AKS node scaling failure

You tried to scale your AKS cluster nodes using az aks scale but the node count did not change. What is the most likely cause?

A You forgot to update the Kubernetes deployment replicas count.

B The cluster autoscaler is disabled or not configured properly.

C The Azure CLI command syntax is incorrect and did not run.

D The container image is missing from the registry.

💡 Hint

Scaling nodes depends on autoscaler settings in AKS.

If autoscaler is disabled or misconfigured, scaling commands won't change node count even if the command runs.

✅ Best Practice

expert

Best practice for securing AKS cluster access

Which option is the best practice to securely control access to your AKS cluster?

A Store cluster admin credentials in plain text files on developer machines.

B Allow anonymous access to the Kubernetes API server for ease of use.

C Disable network policies to avoid connectivity issues.

D Use Azure Active Directory integration with role-based access control (RBAC).

💡 Hint

Think about how to control who can do what in the cluster securely.

Integrating AKS with Azure AD and using RBAC ensures only authorized users can access and perform actions on the cluster.

Practice

1. What is the main benefit of using managed Kubernetes services like Azure Kubernetes Service (AKS)?

easy

A. It handles infrastructure tasks like updates and scaling automatically.

B. It requires you to manually configure all cluster components.

C. It only supports Windows containers.

D. It eliminates the need for containerization.

Solution

1. Step 1: Understand managed Kubernetes purpose

   Managed Kubernetes services automate infrastructure tasks such as updates, scaling, and security.

2. Step 2: Compare options

   Options B, C, and D are incorrect because they either require manual setup, limit container types, or misunderstand containerization benefits.

3. Final Answer:

   It handles infrastructure tasks like updates and scaling automatically. -> Option A

4. Quick Check:

   Managed Kubernetes automates infrastructure tasks = A [OK]

Hint: Managed means cloud handles setup and scaling for you [OK]

Common Mistakes:

• Thinking you must manage all cluster setup manually
• Believing managed Kubernetes only supports certain container types
• Confusing containerization with Kubernetes management

2. Which of the following is the correct Azure CLI command to create a managed Kubernetes cluster named myCluster in resource group myGroup?

easy

A. az aks create --resource-group myGroup --name myCluster --node-count 3 --enable-addons monitoring

B. az k8s create --group myGroup --cluster myCluster --nodes 3

C. az aks deploy --resource-group myGroup --cluster-name myCluster --count 3

D. az container create --resource-group myGroup --name myCluster --count 3

Solution

1. Step 1: Identify correct Azure CLI syntax for AKS creation

   The correct command uses az aks create with parameters --resource-group, --name, and --node-count.

2. Step 2: Evaluate options

   az aks create --resource-group myGroup --name myCluster --node-count 3 --enable-addons monitoring matches the correct syntax. Options B, C, and D use incorrect commands or parameters.

3. Final Answer:

   az aks create --resource-group myGroup --name myCluster --node-count 3 --enable-addons monitoring -> Option A

4. Quick Check:

   Correct Azure CLI command for AKS creation = A [OK]

Hint: Use 'az aks create' with resource group and name [OK]

Common Mistakes:

• Using 'az k8s' instead of 'az aks'
• Mixing parameters like --cluster-name instead of --name
• Confusing container creation with cluster creation

3. Given the following Azure CLI command output snippet after creating an AKS cluster, what does the nodeResourceGroup field represent?

{
  "name": "myCluster",
  "nodeResourceGroup": "MC_myGroup_myCluster",
  "kubernetesVersion": "1.24.6",
  "provisioningState": "Succeeded"
}

medium

A. The resource group for Azure Active Directory.

B. The resource group where the AKS cluster nodes are deployed.

C. The resource group for Azure Container Registry.

D. The resource group where user applications are stored.

Solution

1. Step 1: Understand nodeResourceGroup meaning

   The nodeResourceGroup is a system-generated resource group that contains the infrastructure resources for the AKS nodes.

2. Step 2: Eliminate incorrect options

   Options A, B, and C refer to unrelated resource groups for identity services, user applications, or container registry.

3. Final Answer:

   The resource group where the AKS cluster nodes are deployed. -> Option B

4. Quick Check:

   nodeResourceGroup = AKS nodes resource group [OK]

Hint: nodeResourceGroup holds cluster node resources [OK]

Common Mistakes:

• Confusing nodeResourceGroup with app resource group
• Assuming it relates to container registry
• Mixing it up with identity or directory groups

4. You tried to scale your AKS cluster using the command az aks scale --resource-group myGroup --name myCluster --node-count 5 but got an error. What is the most likely cause?

medium

A. The az aks scale command does not exist; you should use az aks update instead.

B. You must delete the cluster before changing node count.

C. Scaling is not supported on managed Kubernetes clusters.

D. You need to specify the node pool name with --nodepool-name when scaling.

Solution

1. Step 1: Check correct command usage for scaling AKS

   Scaling requires specifying the node pool name using --nodepool-name with az aks scale.

2. Step 2: Analyze options

   The az aks scale command does not exist; you should use az aks update instead. is wrong because az aks scale exists. Scaling is not supported on managed Kubernetes clusters. is false; scaling is supported. You must delete the cluster before changing node count. is incorrect; no need to delete cluster.

3. Final Answer:

   You need to specify the node pool name with --nodepool-name when scaling. -> Option D

4. Quick Check:

   Scaling AKS requires node pool name = B [OK]

Hint: Always include --nodepool-name when scaling nodes [OK]

Common Mistakes:

• Omitting --nodepool-name parameter
• Thinking scaling is unsupported
• Trying to delete cluster to scale nodes

5. You want to ensure your AKS cluster automatically updates to the latest patch version for security without downtime. Which managed Kubernetes feature should you enable?

hard

A. Disable node auto-scaling

B. Manual upgrade triggered by user only

C. Cluster auto-upgrade with surge upgrades enabled

D. Use a single-node cluster to avoid complexity

Solution

1. Step 1: Identify feature for automatic, zero-downtime upgrades

   Cluster auto-upgrade with surge upgrades allows patch updates with minimal downtime by upgrading nodes in batches.

2. Step 2: Evaluate other options

   Manual upgrade requires user action, disabling auto-scaling doesn't affect upgrades, and single-node clusters increase downtime risk.

3. Final Answer:

   Cluster auto-upgrade with surge upgrades enabled -> Option C

4. Quick Check:

   Auto-upgrade with surge = zero downtime updates [OK]

Hint: Enable auto-upgrade with surge for smooth updates [OK]

Common Mistakes:

• Relying on manual upgrades only
• Disabling auto-scaling thinking it helps upgrades
• Using single-node clusters for production