Service accounts in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Output of listing service accounts in a namespace

What is the output of the following command when run in a namespace with two service accounts named default and custom-sa?

Kubernetes

kubectl get serviceaccounts

A

NAME        SECRETS   AGE
custom-sa   1         5d
default     1         10d

B

serviceaccounts/default created
serviceaccounts/custom-sa created

C

NAME        AGE
custom-sa   5d
default     10d

D

NAME        SECRETS
custom-sa   1
default     1

💡 Hint

Use kubectl get serviceaccounts to list all service accounts with their secrets and age.

The kubectl get serviceaccounts command lists all service accounts in the current namespace showing their names, number of secrets, and age.

🧠 Conceptual

intermediate

Purpose of Kubernetes service accounts

Which option best describes the main purpose of a Kubernetes service account?

A To manage network policies between pods in different namespaces.

B To store configuration files for pods to use during startup.

C To provide an identity for processes running in pods to access the Kubernetes API securely.

D To schedule pods onto specific nodes based on resource availability.

💡 Hint

Think about how pods authenticate to the Kubernetes API server.

Service accounts provide an identity for pods so they can securely communicate with the Kubernetes API server.

❓ Configuration

advanced

Correct YAML for creating a service account

Which YAML snippet correctly creates a service account named my-service-account in the production namespace?

A

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
  namespace: production

B

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
  labels:
    namespace: production

C

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
  namespace: prod

D

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
namespace: production

💡 Hint

Namespace must be under metadata and spelled exactly as 'production'.

The namespace must be specified under metadata with the exact name. Labels do not set namespace. The field namespace outside metadata is invalid.

❓ Troubleshoot

advanced

Reason for pod failing to access Kubernetes API with service account

A pod using a service account custom-sa cannot access the Kubernetes API and gets a 403 Forbidden error. What is the most likely cause?

A The pod is running in the wrong namespace.

B The pod specification is missing the <code>serviceAccountName</code> field.

C The Kubernetes API server is down.

D The service account <code>custom-sa</code> does not have the necessary Role or ClusterRole bindings.

💡 Hint

Check if the service account has permissions assigned via roles.

A 403 Forbidden error usually means the service account lacks permissions granted by Role or ClusterRole bindings.

🔀 Workflow

expert

Order of steps to create and use a service account in a pod

Arrange the steps in the correct order to create a service account and use it in a pod.

A 1,2,3,4

B 1,3,2,4

C 3,1,2,4

D 2,1,3,4

💡 Hint

Permissions must be granted before the pod uses the service account.

First create the service account, then assign permissions, then reference it in the pod spec, and finally deploy the pod.

Practice

1. What is the main purpose of a ServiceAccount in Kubernetes?

easy

A. To schedule pods on specific nodes

B. To give a pod an identity and control its permissions inside the cluster

C. To manage network policies between pods

D. To store container images for pods

Solution

1. Step 1: Understand what identity means in Kubernetes

   A ServiceAccount provides an identity for pods so they can authenticate to the Kubernetes API.

2. Step 2: Recognize the role of permissions

   ServiceAccounts are linked to permissions (via Roles or ClusterRoles) to control what pods can do.

3. Final Answer:

   To give a pod an identity and control its permissions inside the cluster -> Option B

4. Quick Check:

   ServiceAccount = Pod identity and permissions [OK]

Hint: ServiceAccount = pod identity + permissions [OK]

Common Mistakes:

• Confusing ServiceAccount with image storage
• Thinking ServiceAccount manages pod scheduling
• Mixing ServiceAccount with network policies

2. Which of the following is the correct YAML snippet to create a ServiceAccount named my-service-account?

easy

A. apiVersion: apps/v1
kind: Deployment
metadata:
name: my-service-account

B. apiVersion: v1
kind: Pod
metadata:
name: my-service-account

C. apiVersion: v1
kind: ServiceAccount
metadata:
name: my-service-account

D. apiVersion: v1
kind: Namespace
metadata:
name: my-service-account

Solution

1. Step 1: Identify the correct kind for ServiceAccount

   The kind must be ServiceAccount to create a service account resource.

2. Step 2: Check the apiVersion and metadata

   ServiceAccount uses apiVersion: v1 and metadata with the name field.

3. Final Answer:

   apiVersion: v1 kind: ServiceAccount metadata: name: my-service-account -> Option C

4. Quick Check:

   ServiceAccount YAML uses kind: ServiceAccount [OK]

Hint: ServiceAccount YAML always uses kind: ServiceAccount [OK]

Common Mistakes:

• Using wrong kind like Pod or Deployment
• Wrong apiVersion for ServiceAccount
• Confusing Namespace with ServiceAccount

3. Given this command: kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}', what does it output?

medium

A. The name of the first secret linked to the default ServiceAccount

B. The list of all pods using the default ServiceAccount

C. The token value inside the secret

D. An error because jsonpath is invalid

Solution

1. Step 1: Understand the command structure

   The command fetches the ServiceAccount named 'default' and extracts the first secret's name using jsonpath.

2. Step 2: Interpret the jsonpath expression

   The expression {.secrets[0].name} selects the name of the first secret linked to the ServiceAccount.

3. Final Answer:

   The name of the first secret linked to the default ServiceAccount -> Option A

4. Quick Check:

   jsonpath extracts secret name from ServiceAccount [OK]

Hint: jsonpath {.secrets[0].name} gets first secret name [OK]

Common Mistakes:

• Thinking it lists pods instead of secrets
• Expecting secret token value instead of secret name
• Assuming jsonpath syntax is wrong

4. You created a ServiceAccount but your pod fails to use it. Which of these is the most likely cause?

medium

A. The ServiceAccount was created in a different namespace

B. The pod image is missing

C. The ServiceAccount has no secrets linked

D. The pod spec does not specify the ServiceAccount name

Solution

1. Step 1: Check namespace consistency

   ServiceAccounts are namespace-scoped. If the pod is in one namespace but the ServiceAccount in another, the pod cannot use it.

2. Step 2: Verify pod spec and ServiceAccount existence

   Even if the ServiceAccount exists in the same namespace, the pod must specify the ServiceAccount name in its spec to use it.

3. Final Answer:

   The pod spec does not specify the ServiceAccount name -> Option D

4. Quick Check:

   Pod spec must specify serviceAccountName to use it [OK]

Hint: Pod spec must specify serviceAccountName [OK]

Common Mistakes:

• Forgetting to specify serviceAccountName in pod spec
• Assuming missing secrets cause pod failure
• Blaming pod image unrelated to ServiceAccount

5. You want a pod to use a custom ServiceAccount named app-sa and access the Kubernetes API with limited permissions. Which steps should you follow?

hard

A. Create the ServiceAccount app-sa, create a Role with permissions, bind the Role to app-sa, then specify serviceAccountName: app-sa in the pod spec

B. Create a RoleBinding for the default ServiceAccount, then deploy the pod without specifying serviceAccountName

C. Create a ClusterRole with full permissions and assign it to the pod directly

D. Deploy the pod first, then create the ServiceAccount and Role

Solution

1. Step 1: Create the custom ServiceAccount

   Define and create app-sa in the pod's namespace to give the pod an identity.

2. Step 2: Define permissions and bind them

   Create a Role with limited permissions and bind it to app-sa using a RoleBinding.

3. Step 3: Specify the ServiceAccount in the pod spec

   Set serviceAccountName: app-sa in the pod spec so the pod uses this identity and permissions.

4. Final Answer:

   Create the ServiceAccount app-sa, create a Role with permissions, bind the Role to app-sa, then specify serviceAccountName: app-sa in the pod spec -> Option A

5. Quick Check:

   Custom ServiceAccount + Role + RoleBinding + pod spec = correct setup [OK]

Hint: Create SA, Role, RoleBinding, then assign SA to pod [OK]

Common Mistakes:

• Assigning permissions to default ServiceAccount instead of custom
• Creating ClusterRole with too many permissions
• Deploying pod before creating ServiceAccount and Role