Why managed Kubernetes matters in AWS - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to create a managed Kubernetes cluster using AWS EKS CLI.

AWS

aws eks create-cluster --name my-cluster --role-arn [1] --resources-vpc-config subnetIds=subnet-12345,subnet-67890

Drag options to blanks, or click blank then click option'

Aarn:aws:iam::123456789012:role/LambdaExecutionRole

Barn:aws:iam::123456789012:role/EKSClusterRole

Carn:aws:iam::123456789012:role/S3AccessRole

Darn:aws:iam::123456789012:role/EC2InstanceRole

Attempts:

3 left

💡 Hint

Common Mistakes

Using a role meant for EC2 instances instead of the cluster role.

The role-arn must be the IAM role that allows EKS to manage the cluster resources. The EKSClusterRole is the correct role for this.

2fill in blank

medium

Complete the command to update kubeconfig for accessing the managed EKS cluster.

AWS

aws eks update-kubeconfig --name [1]

Drag options to blanks, or click blank then click option'

Amy-cluster

Bmy-old-cluster

Ctest-cluster

Ddev-cluster

Attempts:

3 left

💡 Hint

Common Mistakes

Using a different cluster name that does not exist.

You must specify the exact cluster name you created, which is my-cluster in this case, to update your kubeconfig correctly.

3fill in blank

hard

Fix the error in the command to create a node group for the EKS cluster.

AWS

aws eks create-nodegroup --cluster-name my-cluster --nodegroup-name [1] --subnets subnet-12345 subnet-67890 --node-role arn:aws:iam::123456789012:role/EKSNodeRole

Drag options to blanks, or click blank then click option'

Adefault node group

Bnode group 1

Cnodegroup1

Ddefault-node-group

Attempts:

3 left

💡 Hint

Common Mistakes

Including spaces in the node group name causing syntax errors.

Node group names cannot contain spaces. Use a single string like default-node-group.

4fill in blank

hard

Fill both blanks to define a Kubernetes deployment YAML snippet for a managed cluster.

AWS

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:[1]
        ports:
        - containerPort: [2]

Drag options to blanks, or click blank then click option'

Alatest

B80

C8080

Dstable

Attempts:

3 left

💡 Hint

Common Mistakes

Using invalid image tags or wrong port numbers.

The image tag should specify a valid tag like latest. The default HTTP port for nginx is 80.

5fill in blank

hard

Fill all three blanks to create a Kubernetes service YAML snippet exposing the deployment.

AWS

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: [1]
  selector:
    app: [2]
  ports:
  - protocol: TCP
    port: [3]
    targetPort: 80

Drag options to blanks, or click blank then click option'

ALoadBalancer

Bnginx

C80

DClusterIP

Attempts:

3 left

💡 Hint

Common Mistakes

Using wrong service type or mismatched selector labels.

The service type LoadBalancer exposes the service externally. The selector must match the deployment label nginx. The port exposed is 80.

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