Adding labels to resources in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Adding a label to a running Pod

You have a running Pod named web-server. Which command will add the label env=production to this Pod without restarting it?

A kubectl edit pod web-server -l env=production

B kubectl label pod web-server env=production

C kubectl set label pod web-server env=production --overwrite

D kubectl patch pod web-server -p '{"metadata":{"labels":{"env":"production"}}}'

💡 Hint

Use the kubectl command that adds labels directly to existing resources.

The kubectl label command adds labels to existing resources without restarting them. Option B correctly adds the label env=production to the Pod named web-server.

Option B requires --overwrite only if the label exists, but it's not necessary here. Option B patches the Pod but is more complex. Option B tries to edit with a label selector, which is incorrect.

❓ Configuration

intermediate

Defining labels in a Deployment manifest

In a Kubernetes Deployment YAML, where should you add labels so that they apply to both the Deployment and the Pods it creates?

A Under <code>metadata.labels</code> and <code>spec.template.metadata.labels</code>

B Under <code>metadata.annotations</code> and <code>spec.template.metadata.annotations</code>

C Only under <code>spec.template.spec.containers.labels</code>

D Only under <code>spec.selector.matchLabels</code>

💡 Hint

Labels must be on both the Deployment and Pod template to work properly.

Labels on the Deployment resource go under metadata.labels. Labels on Pods created by the Deployment go under spec.template.metadata.labels. This ensures selectors match and Pods are labeled correctly.

Option A is only for selectors, not labels. Option A is invalid because containers do not have labels. Option A uses annotations, which are different from labels.

❓ Troubleshoot

advanced

Why does a Pod not get selected by a Service after adding labels?

You added the label app=frontend to a Pod, but the Service with selector app=frontend does not route traffic to it. What is the most likely cause?

A The Pod is in a different namespace than the Service

B The Pod's labels were added after the Service was created and the Service cache is stale

C The Service selector labels do not exactly match the Pod labels

D The Pod's container ports are not exposed

💡 Hint

Check if the labels on the Pod exactly match the Service selector.

For a Service to route traffic to a Pod, the Pod's labels must exactly match the Service's selector labels. Even a small difference causes no matching.

Option C is incorrect because Services dynamically watch labels. Option C is possible but less common if namespaces differ. Option C affects traffic routing but does not prevent selection.

🔀 Workflow

advanced

Labeling multiple resources efficiently

You want to add the label team=devops to all Pods in the namespace production. Which command achieves this in one step?

A kubectl label pods --selector=team=devops -n production

B kubectl label pods -l team=devops -n production

C kubectl label pods -n production team=devops

D kubectl label pods --all team=devops -n production

💡 Hint

Use the flag that targets all Pods regardless of current labels.

The --all flag selects all Pods in the namespace. Option D correctly adds the label team=devops to all Pods in production.

Option D tries to label Pods that already have the label, which is redundant. Option D misses the --all flag and will fail. Option D uses an invalid flag --selector instead of -l.

✅ Best Practice

expert

Best practice for immutable labels on critical resources

You manage a critical Deployment and want to ensure its labels are not accidentally changed after creation. What is the best approach to enforce immutable labels?

A Use an admission controller webhook to reject label changes on the Deployment

B Add labels only in Pod templates, not on the Deployment metadata

C Manually monitor labels and revert changes with scripts

D Use annotations instead of labels for critical metadata

💡 Hint

Think about Kubernetes features that enforce policies automatically.

Admission controller webhooks can enforce policies like immutability by rejecting updates that change labels on critical resources. This is the best automated approach.

Option A is manual and error-prone. Option A does not prevent label changes on the Deployment itself. Option A misuses annotations, which are not selectors and do not replace labels.