Chart templates and values.yaml in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Output of Helm template rendering with values.yaml

Given the following Helm chart template snippet and values.yaml, what will be the output of helm template command for the container image name?

Kubernetes

---
# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  template:
    spec:
      containers:
        - name: app
          image: {{ .Values.image.repository }}:{{ .Values.image.tag }}

---
# values.yaml
image:
  repository: nginx
  tag: stable

A image: nginx:latest

B image: nginx:stable

C image: myapp:stable

D image: nginx

💡 Hint

Look at how the template uses .Values.image.repository and .Values.image.tag from values.yaml.

The template uses the values from values.yaml exactly as .Values.image.repository and .Values.image.tag, so the image will be nginx:stable.

🧠 Conceptual

intermediate

Purpose of values.yaml in Helm charts

What is the main purpose of the values.yaml file in a Helm chart?

A To define the Kubernetes API versions supported

B To store Kubernetes cluster credentials

C To provide default configuration values that templates use during rendering

D To list all Helm chart dependencies

💡 Hint

Think about what values.yaml controls in the chart rendering process.

values.yaml holds default values that templates reference to customize Kubernetes manifests during Helm install or template rendering.

❓ Troubleshoot

advanced

Why does Helm fail rendering with missing value?

You have this template snippet:

{{ .Values.service.port }}

and your values.yaml does NOT define service.port. What error will Helm produce when running helm template?

A Error: template: deployment.yaml: nil pointer evaluating interface {}.port

B Error: template: deployment.yaml: missing value for key "service.port"

C No error, renders with empty string for port

D Error: values.yaml file not found

💡 Hint

Consider what happens when you try to access a nested key that does not exist in Helm templates.

Accessing a missing nested key like .Values.service.port causes a nil pointer error because .Values.service is nil and you try to get .port from nil.

🔀 Workflow

advanced

Order of Helm chart rendering steps

What is the correct order of steps Helm follows when rendering a chart with templates and values.yaml?

A 1,2,3,4

B 2,3,1,4

C 1,3,2,4

D 2,1,3,4

💡 Hint

Think about when values are merged and when templates are rendered.

Helm first loads templates, then merges values.yaml with any overrides, then renders templates with those values, and finally outputs manifests.

✅ Best Practice

expert

Best practice for managing sensitive data in Helm charts

Which is the best practice for handling sensitive data like passwords in Helm charts using values.yaml?

A Store sensitive data directly in values.yaml committed to version control

B Leave sensitive fields empty and manually edit manifests after deployment

C Hardcode sensitive data in templates for security

D Use Helm secrets or external secret management tools and avoid committing secrets in values.yaml

💡 Hint

Think about security risks of storing secrets in plain text files.

Best practice is to use Helm secrets plugins or external secret managers to keep sensitive data encrypted and out of version control.

Practice

1. What is the main purpose of the values.yaml file in a Helm chart?

easy

A. To store default configuration values for templates

B. To define Kubernetes resource limits

C. To write deployment scripts

D. To list all Kubernetes nodes

Solution

1. Step 1: Understand Helm chart structure

   Helm charts use templates with placeholders to create Kubernetes manifests dynamically.

2. Step 2: Role of values.yaml

   The values.yaml file provides default values for these placeholders, allowing customization without changing templates.

3. Final Answer:

   To store default configuration values for templates -> Option A

4. Quick Check:

   values.yaml = default settings [OK]

Hint: Remember: values.yaml holds default settings for templates [OK]

Common Mistakes:

• Confusing values.yaml with deployment scripts
• Thinking it defines resource limits directly
• Assuming it lists Kubernetes nodes

2. Which of the following is the correct syntax to reference a value named replicaCount from values.yaml inside a Helm template?

easy

A. {{ .Values.replicaCount }}

B. {{ .replicaCount }}

C. {{ values.replicaCount }}

D. {{ .Config.replicaCount }}

Solution

1. Step 1: Understand Helm template syntax

   Helm templates access values using the .Values object followed by the key name.

2. Step 2: Match syntax for replicaCount

   The correct way is {{ .Values.replicaCount }} to get the value from values.yaml.

3. Final Answer:

   {{ .Values.replicaCount }} -> Option A

4. Quick Check:

   Use .Values.key to access values [OK]

Hint: Use .Values.key to get values in templates [OK]

Common Mistakes:

• Omitting the .Values prefix
• Using lowercase 'values' instead of .Values
• Confusing .Config with .Values

3. Given this snippet in values.yaml:

replicaCount: 3
image:
  repository: nginx
  tag: stable

What will be the output of this Helm template snippet?

{{ .Values.replicaCount }} replicas of {{ .Values.image.repository }}:{{ .Values.image.tag }}

medium

A. replicaCount replicas of image.repository:image.tag

B. Error: undefined values

C. 3 replicas of nginx:latest

D. 3 replicas of nginx:stable

Solution

1. Step 1: Read values.yaml keys and values

   replicaCount is 3, image.repository is 'nginx', and image.tag is 'stable'.

2. Step 2: Substitute values in template

   The template outputs: '3 replicas of nginx:stable' by replacing placeholders with values.

3. Final Answer:

   3 replicas of nginx:stable -> Option D

4. Quick Check:

   Values replaced correctly = 3 replicas of nginx:stable [OK]

Hint: Match keys exactly to get correct output [OK]

Common Mistakes:

• Using wrong tags like 'latest' instead of 'stable'
• Not accessing nested keys properly
• Expecting literal placeholders in output

4. You have this template snippet:

{{ if .Values.enableFeature }}Feature is enabled{{ else }}Feature is disabled{{ end }}

But the output always shows "Feature is disabled" even when you set enableFeature: true in values.yaml. What is the likely cause?

medium

A. The template syntax is incorrect and missing a closing tag

B. enableFeature is set as a string "true" instead of boolean true

C. The values.yaml file is not saved properly

D. Helm does not support boolean values in values.yaml

Solution

1. Step 1: Check boolean handling in values.yaml

   YAML treats unquoted true as boolean, but quoted "true" is a string, which evaluates as true in some contexts but false in Helm conditionals.

2. Step 2: Understand Helm conditional evaluation

   Helm expects boolean true, so if enableFeature is a string, the condition fails and goes to else.

3. Final Answer:

   enableFeature is set as a string "true" instead of boolean true -> Option B

4. Quick Check:

   Boolean true must be unquoted in values.yaml [OK]

Hint: Use unquoted true/false for booleans in values.yaml [OK]

Common Mistakes:

• Quoting booleans as strings
• Assuming template syntax error without checking values
• Not saving values.yaml after changes

5. You want to create a Helm chart template that sets the container port only if service.port is defined in values.yaml. Which template snippet correctly implements this conditional logic?

hard

A. {{- if .Values.service.port }}
containerPort: "{{ .Values.service.port }}"
{{- else }}
containerPort: 80
{{- end }}

B. {{- if .service.port }}
containerPort: {{ .service.port }}
{{- end }}

C. {{- if .Values.service.port }}
containerPort: {{ .Values.service.port }}
{{- end }}

D. {{- if .Values.service.port != null }}
containerPort: {{ .Values.service.port }}
{{- end }}

Solution

1. Step 1: Identify correct value reference

   Use .Values.service.port to access the port value from values.yaml.

2. Step 2: Use proper conditional syntax

   Helm templates use {{- if .Values.service.port }} to check if the value exists and is non-empty.

3. Step 3: Evaluate options

   {{- if .Values.service.port }} containerPort: {{ .Values.service.port }} {{- end }} correctly uses the conditional and outputs the port only if defined. {{- if .service.port }} containerPort: {{ .service.port }} {{- end }} misses .Values. {{- if .Values.service.port }} containerPort: "{{ .Values.service.port }}" {{- else }} containerPort: 80 {{- end }} adds an else block which is not requested. {{- if .Values.service.port != null }} containerPort: {{ .Values.service.port }} {{- end }} uses invalid syntax (!= null is not valid in Helm templates).

4. Final Answer:

   {{- if .Values.service.port }} containerPort: {{ .Values.service.port }} {{- end }} -> Option C

5. Quick Check:

   Use if .Values.key for conditionals [OK]

Hint: Check existence with if .Values.key, no need for != null [OK]

Common Mistakes:

• Omitting .Values prefix
• Using invalid comparison operators
• Adding unnecessary else blocks