Init container pattern in Docker - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Purpose of Init Containers in Kubernetes

What is the main purpose of using an init container in a Kubernetes Pod?

A To provide a user interface for the application

B To run setup tasks before the main application container starts

C To scale the number of application containers automatically

D To replace the main application container after it crashes

💡 Hint

Think about tasks that must finish before the main app runs.

Init containers run before app containers to prepare the environment, such as setting up files or waiting for services.

💻 Command Output

intermediate

Output of Init Container Status

Given the following kubectl get pod mypod -o json snippet showing init container status, what is the state of the init container?

{
  "status": {
    "initContainerStatuses": [
      {
        "name": "init-setup",
        "state": {
          "terminated": {
            "exitCode": 0,
            "reason": "Completed"
          }
        }
      }
    ]
  }
}

A Init container finished successfully

B Init container is still running

C Init container failed to start

D Init container was skipped

💡 Hint

Look at the exitCode and reason fields.

The init container terminated with exit code 0 and reason 'Completed', meaning it finished successfully.

❓ Configuration

advanced

Correct Init Container YAML Configuration

Which YAML snippet correctly defines an init container that copies files from a shared volume before the main container starts?

A

initContainers:
  - name: init-copy
    image: busybox
    command: ['sh', '-c', 'cp /source/* /dest/']
    volumeMounts:
      - name: shared-data
        mountPath: /dest
containers:
  - name: app
    image: myapp
    volumeMounts:
      - name: shared-data
        mountPath: /app/data
volumes:
  - name: shared-data
    emptyDir: {}

B

initContainers:
  - name: init-copy
    image: busybox
    command: ['sh', '-c', 'cp /source/* /dest/']
containers:
  - name: app
    image: myapp
volumes:
  - name: shared-data
    emptyDir: {}

C

initContainers:
  - name: init-copy
    image: busybox
    command: ['cp', '/source/*', '/dest/']
    volumeMounts:
      - name: shared-data
        mountPath: /dest
containers:
  - name: app
    image: myapp
    volumeMounts:
      - name: shared-data
        mountPath: /app/data
volumes:
  - name: shared-data
    emptyDir: {}

D

containers:
  - name: init-copy
    image: busybox
    command: ['sh', '-c', 'cp /source/* /dest/']
    volumeMounts:
      - name: shared-data
        mountPath: /dest
initContainers:
  - name: app
    image: myapp
    volumeMounts:
      - name: shared-data
        mountPath: /app/data
volumes:
  - name: shared-data
    emptyDir: {}

💡 Hint

Check the placement of initContainers and volume mounts.

Option A correctly places the init container under initContainers, uses a shell command to copy files, and mounts the shared volume in both containers.

❓ Troubleshoot

advanced

Init Container Fails to Complete

You have an init container that never completes and blocks the main container from starting. Which of the following is the most likely cause?

A The Kubernetes node is out of disk space

B The main container image is missing

C The pod has no resource limits set

D The init container command is stuck waiting for input or a service that is not available

💡 Hint

Think about what can cause a container to hang during startup.

If the init container command waits indefinitely (e.g., for input or a service), it will block the pod from progressing.

🔀 Workflow

expert

Init Container Execution Order

Consider a Pod with three init containers named init1, init2, and init3. Which statement correctly describes their execution order?

A They run randomly and independently of order

B They run in parallel and the Pod starts when all finish

C They run sequentially in the order defined in the Pod spec, each must complete before the next starts

D Only the first init container runs; the others run only if the first fails

💡 Hint

Think about how Kubernetes ensures setup tasks complete before the app runs.

Init containers run one after another in the order they appear in the Pod spec. Each must finish successfully before the next starts.