Chef Interview Q&A (Part 2): Resources, Run-Lists, Bootstrap, and Test Kitchen

Chef interview rounds usually go beyond definitions and test whether you understand convergence behavior, resource order, and node lifecycle operations. This revised guide turns the original Q&A into a concise field reference for interview prep and real operations work.

Originally published on 2015-09-02; fully revised and updated.

Original source attribution in the post pointed to learn.chef.io. Community cookbooks referenced in the material are available through Chef Supermarket.

Core Chef concepts interviewers expect

• Resource: A unit of desired state (for example, a package, service, or file).
• Recipe: An ordered collection of resources that applies configuration policy.
• Cookbook: A package of recipes plus supporting files (templates, attributes, libraries, etc.).
• Node: A managed compute instance (VM, physical host, or container host context).
• Run-list: The ordered list of recipes/roles a node applies during a Chef run.

Resource execution order and default actions

Chef processes resources in the order they appear in a recipe. That ordering can be the difference between a successful converge and a failed run.

Default action behavior

If you omit an explicit action, Chef uses that resource type’s default action. For example, package resources typically default to install behavior.

package 'httpd'
# No action specified; package resource uses its default action.Code language: PHP (php)

Order-sensitive versus order-insensitive cases

# Works in expected sequence: package first, service second
package 'httpd'

service 'httpd' do
  action [:enable, :start]
endCode language: PHP (php)

# Risky sequence: service before package
service 'httpd' do
  action [:enable, :start]
end

package 'httpd'Code language: PHP (php)

service 'httpd' do
  action [:stop, :disable]
endCode language: JavaScript (javascript)

Recipe, cookbook, and run-list relationships

Interviews often probe whether you can connect authoring to execution: resources live in recipes, recipes are packaged as cookbooks, and run-lists define what each node applies and in what order.

knife node run_list add web1 'recipe[apache::default]'
knife node show web1 -a run_listCode language: JavaScript (javascript)

The original material also highlights two server consumption models: running Chef Server on your own infrastructure or using a hosted offering, and using the Starter Kit credentials to securely connect with knife.

chef-apply vs chef-client vs knife

chef-apply ./example.rb
chef-client
knife node listCode language: PHP (php)

Node bootstrap and first converge workflow

flowchart TD
    A[Prepare workstation credentials] --> B[Run knife bootstrap]
    B --> C[Node installs chef-client]
    C --> D[Node registers with Chef Server]
    D --> E[Node pulls assigned run-list]
    E --> F[Chef Infra Client converges resources]
    F --> G{Configuration drift remains}
    G -- yes --> H[Update cookbook and upload]
    H --> F
    G -- no --> I[Node stays in desired state]

knife bootstrap NODE_IP \
  -x USER \
  -P 'PASSWORD' \
  --sudo \
  --node-name web1 \
  --run-list 'recipe[apache::default]'Code language: PHP (php)

Uploading and applying cookbook updates

After editing a cookbook, upload it to Chef Server and trigger a converge on target nodes.

knife cookbook upload awesome_customers
knife ssh 'name:web1' 'sudo chef-client'
ssh user@web1.example.com 'sudo chef-client'Code language: JavaScript (javascript)

The source also references Semantic Versioning guidance: setting cookbook version 1.0.0 once it is considered production-ready.

Template example: render node data into an HTML page

This ERB example from the original content demonstrates using node attributes in a template:

<html>
<body>
<h1>hello from <%= node['fqdn'] %></h1>

<pre>
<%= node['hostname'] %>
<%= node['platform'] %> - <%= node['platform_version'] %>
<%= node['memory']['total'] %> RAM
<%= node['cpu']['total'] %> CPUs
</pre>
</body>
</html>Code language: HTML, XML (xml)

Then upload the cookbook and run chef-client on the node to apply the updated template.

Local cookbook testing with Test Kitchen

For faster development cycles, Test Kitchen can create ephemeral instances, converge cookbooks, and tear instances down after validation.

---
driver:
  name: vagrant

provisioner:
  name: chef_zero

platforms:
  - name: centos-6.6
  - name: centos-6.5

suites:
  - name: default
    run_list:
      - recipe[motd::default]Code language: CSS (css)

kitchen list
kitchen converge
kitchen login default-centos-66
kitchen login default-centos-65
kitchen destroyCode language: PHP (php)

Best practices and common pitfalls

• Explain resource order clearly in interviews; it is one of the most common failure patterns.
• Use run-lists intentionally; sequence across cookbooks can affect service readiness.
• Test cookbook changes in ephemeral environments before production convergence.
• Keep cookbook versions meaningful and increment with change impact.
• Do not assume old platform examples (for example, CentOS 6.x) are suitable for current production baselines.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.