Why managed Kubernetes matters in AWS - 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 AWS EKS instead of setting up Kubernetes yourself?

A You get automatic updates and security patches managed by the provider.

B You must manually configure the control plane and worker nodes.

C You can avoid paying for cloud resources since it runs on your local machine.

D You have full control over every node and component without restrictions.

💡 Hint

Think about what tasks managed services handle for you automatically.

Managed Kubernetes services handle control plane management, updates, and security patches, reducing your operational burden.

💻 Command Output

intermediate

Output of AWS EKS cluster creation command

What is the expected output when you successfully create an AWS EKS cluster using the AWS CLI command aws eks create-cluster?

AWS

aws eks create-cluster --name my-cluster --role-arn arn:aws:iam::123456789012:role/EKSRole --resources-vpc-config subnetIds=subnet-abc123,subnet-def456

A { "cluster": { "name": "my-cluster", "status": "ACTIVE", "endpoint": "https://1234567890.gr7.us-east-1.eks.amazonaws.com" } }

B { "cluster": { "name": "my-cluster", "status": "CREATING", "endpoint": null } }

C Error: Missing required parameter 'region'

D SyntaxError: Unexpected token in JSON

💡 Hint

Right after creation, the cluster status is not yet ACTIVE.

When you create an EKS cluster, the initial status is 'CREATING'. It becomes 'ACTIVE' only after setup completes.

🔀 Workflow

advanced

Correct order to deploy an app on AWS EKS

Arrange the steps in the correct order to deploy a containerized app on AWS EKS.

A 3,1,2,4

B 1,3,2,4

C 1,2,3,4

D 2,1,3,4

💡 Hint

Think about what must exist before you configure tools or deploy apps.

You first create the cluster, then configure kubectl to access it, then push your image, and finally deploy your app manifests.

❓ Troubleshoot

advanced

Diagnosing EKS node group connection issues

You created an EKS cluster and a managed node group, but your pods stay in Pending state. What is the most likely cause?

A The node group IAM role lacks permissions to join the cluster.

B The EKS cluster control plane is not yet ACTIVE.

C The Docker image is missing from the container registry.

D kubectl is not installed on your local machine.

💡 Hint

Think about what allows nodes to register with the cluster.

If the node group's IAM role lacks the right permissions, nodes cannot join the cluster, so pods remain Pending.

✅ Best Practice

expert

Best practice for securing AWS EKS clusters

Which practice is considered best for securing access to your AWS EKS cluster?

A Disable encryption at rest for etcd to improve performance.

B Allow unrestricted access to the Kubernetes API server from any IP.

C Store all secrets as plain text in ConfigMaps for easy access.

D Use AWS IAM roles for service accounts (IRSA) to grant pod permissions.

💡 Hint

Consider how to limit permissions for pods securely.

Using IAM roles for service accounts (IRSA) allows fine-grained, secure permissions for pods without sharing node IAM roles.

Practice

1. What is the main benefit of using managed Kubernetes services like AWS EKS?

easy

A. They handle cluster setup and maintenance for you

B. They require you to manually configure all nodes

C. They only work with specific programming languages

D. They eliminate the need for containers

Solution

1. Step 1: Understand managed Kubernetes role

   Managed Kubernetes services automate cluster setup and ongoing maintenance tasks.

2. Step 2: Compare options

   Options B, C, and D are incorrect because manual configuration, language restrictions, or removing containers are not true benefits of managed Kubernetes.

3. Final Answer:

   They handle cluster setup and maintenance for you -> Option A

4. Quick Check:

   Managed Kubernetes automates cluster management = A [OK]

Hint: Managed means less manual setup and maintenance [OK]

Common Mistakes:

• Thinking you must configure all nodes manually
• Believing managed Kubernetes limits programming languages
• Assuming containers are not needed

2. Which AWS CLI command correctly creates an EKS cluster named my-cluster?

easy

A. aws eks create-cluster --cluster-name my-cluster --role-arn --resources-vpc-config subnetIds=

B. aws eks create-cluster --name my-cluster --role-arn --resources-vpc-config subnetIds=

C. aws eks create cluster --name my-cluster --role-arn --vpc-config subnetIds=

D. aws eks create-cluster my-cluster --role --vpc

Solution

1. Step 1: Review AWS CLI syntax for EKS cluster creation

   The correct command uses aws eks create-cluster with flags --name, --role-arn, and --resources-vpc-config.

2. Step 2: Identify correct option

   aws eks create-cluster --name my-cluster --role-arn --resources-vpc-config subnetIds= matches the correct syntax. Options A, B, and C have syntax errors or wrong flag names.

3. Final Answer:

   aws eks create-cluster --name my-cluster --role-arn <role-arn> --resources-vpc-config subnetIds=<subnet-ids> -> Option B

4. Quick Check:

   Correct AWS CLI syntax = D [OK]

Hint: Use exact AWS CLI flags as in docs [OK]

Common Mistakes:

• Using wrong flag names like --cluster-name
• Omitting --resources-vpc-config
• Incorrect command spacing or missing dashes

3. Given this AWS CLI output after creating an EKS cluster, what is the cluster status?

{
  "cluster": {
    "name": "my-cluster",
    "status": "ACTIVE",
    "endpoint": "https://1234567890.gr7.eks.amazonaws.com"
  }
}

medium

A. CREATING

B. FAILED

C. ACTIVE

D. DELETING

Solution

1. Step 1: Read the JSON output carefully

   The status field shows "ACTIVE", indicating the cluster is ready.

2. Step 2: Match status to options

   Only ACTIVE matches the status value "ACTIVE". Others are different lifecycle states.

3. Final Answer:

   ACTIVE -> Option C

4. Quick Check:

   Status field = ACTIVE [OK]

Hint: Look for "status" field in output JSON [OK]

Common Mistakes:

• Confusing status with cluster name
• Choosing 'CREATING' when cluster is ready
• Ignoring JSON structure

4. You tried to create an EKS cluster but got this error: InvalidParameterException: Role ARN is missing. What is the most likely cause?

medium

A. You did not specify the IAM role ARN in the create command

B. Your VPC subnets are not public

C. The cluster name is too long

D. You used an unsupported AWS region

Solution

1. Step 1: Analyze the error message

   The error says "Role ARN is missing", meaning the IAM role ARN parameter was not provided.

2. Step 2: Identify the cause

   You did not specify the IAM role ARN in the create command matches the error cause. Other options relate to different issues.

3. Final Answer:

   You did not specify the IAM role ARN in the create command -> Option A

4. Quick Check:

   Error about missing Role ARN = A [OK]

Hint: Check if IAM role ARN is included in command [OK]

Common Mistakes:

• Assuming subnet or region issues cause this error
• Ignoring the exact error message
• Confusing cluster name length with role ARN

5. Why does using a managed Kubernetes service improve application availability compared to self-managed clusters?

hard

A. Managed services require manual patching which improves control

B. Managed services limit the number of nodes to prevent overload

C. Self-managed clusters automatically scale better than managed ones

D. Managed services automate updates and handle failures reducing downtime

Solution

1. Step 1: Understand managed Kubernetes benefits for availability

   Managed Kubernetes automates updates, monitors health, and recovers from failures to keep apps running.

2. Step 2: Evaluate options

   Managed services automate updates and handle failures reducing downtime correctly states this. Managed services require manual patching which improves control is false because manual patching increases risk. Self-managed clusters automatically scale better than managed ones is incorrect; self-managed scaling is harder. Managed services limit the number of nodes to prevent overload is wrong; managed services do not limit nodes arbitrarily.

3. Final Answer:

   Managed services automate updates and handle failures reducing downtime -> Option D

4. Quick Check:

   Automation reduces downtime = B [OK]

Hint: Automation and failure handling boost availability [OK]

Common Mistakes:

• Thinking manual patching improves availability
• Believing self-managed clusters scale better automatically
• Assuming node limits improve availability