You must complete this task on the following cluster/nodes: Cluster: KSCH00301 Master node: ksch00301-master Worker node: ksch00301-worker1 You can switch the cluster/configuration context using the…

Question

Exhibit

Explanation

Kubernetes ServiceAccount Security - Exam Explanation

Overall Goal

The cluster has a security policy requiring ServiceAccounts to:

• Not automount API credentials (prevents pods from accessing the Kubernetes API unless explicitly needed)
• Have names ending in -sa (naming convention for auditability)

A Pod manifest already exists but references a ServiceAccount that doesn't exist yet, so it fails to schedule. Your job is to create the correct ServiceAccount, deploy the Pod, then clean up stale ServiceAccounts.

Step 0 - Switch context

kubectl config use-context KSCH00301

Why: Ensures all subsequent commands target the correct cluster. Every task starts here.

Step 1 - Create the ServiceAccount

kubectl create serviceaccount frontend-sa -n qa --dry-run=client -o yaml > frontend-sa.yaml

Edit the YAML to add automountServiceAccountToken: false, then apply:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: frontend-sa
  namespace: qa
automountServiceAccountToken: false

kubectl apply -f frontend-sa.yaml

Or imperatively (kubectl ≥1.24):

kubectl create sa frontend-sa -n qa
kubectl patch sa frontend-sa -n qa -p '{"automountServiceAccountToken": false}'

Why automountServiceAccountToken: false: By default, Kubernetes automatically mounts a token into every Pod at /var/run/secrets/kubernetes.io/serviceaccount/. This gives the Pod implicit API access - a security risk if the app doesn't need it. Setting this to false enforces least-privilege.

Why this must come before Step 2: The Pod manifest references frontend-sa. If it doesn't exist, the Pod stays in Pending with a "ServiceAccount not found" error.

Step 2 - Inspect and create the Pod

First, read the manifest to understand what ServiceAccount it references:

cat /home/candidate/KSCH00301/pod-manifest.yaml

It likely references a ServiceAccount that doesn't follow the -sa convention (e.g., frontend) - that's the bug. The manifest may already be corrected to use frontend-sa, or you may need to confirm it points to the one you just created.

Then create the Pod:

kubectl apply -f /home/candidate/KSCH00301/pod-manifest.yaml

Verify it schedules:

kubectl get pod -n qa

Why: The manifest file is provided - you shouldn't recreate the Pod from scratch. Using kubectl apply -f respects all other spec fields (image, resources, volumes) already defined.

Step 3 - Clean up unused ServiceAccounts

List all ServiceAccounts in namespace qa:

kubectl get sa -n qa

Find which ones are not referenced by any Pod:

kubectl get pods -n qa -o yaml | grep serviceAccountName

The default ServiceAccount always exists and should be left alone. Any custom ServiceAccount that no Pod references (e.g., frontend - the incorrectly named one that caused the original failure) should be deleted:

kubectl delete sa frontend -n qa   # or whatever the unused one is named

Why: "Unused ServiceAccounts" are an attack surface. If they have associated RoleBindings, they could be exploited even if no Pod currently uses them. Cleanup is part of the security policy.

What goes wrong if skipped: The task is incomplete and the exam will likely check for the presence of stale ServiceAccounts. You won't get full marks.

What Goes Wrong If Steps Are Out of Order

Memory Tip

Think of it as "Build → Use → Clean":

1. Build the correct foundation (ServiceAccount with policy-compliant settings)
2. Use it (deploy the Pod via the provided manifest)
3. Clean up what's no longer needed (unused ServiceAccounts)

The -sa suffix rule is a mnemonic hint: if a ServiceAccount doesn't end in -sa, it's either wrongly named or unused - either fix it or delete it.

No community discussion yet for this question.