{"id":426,"date":"2026-10-14T08:01:27","date_gmt":"2026-10-14T08:01:27","guid":{"rendered":"http:\/\/www.scmgalaxy.com\/tutorials\/2015\/09\/02\/chef-configuration-management-interview-questions-and-answers\/"},"modified":"2026-10-14T08:01:27","modified_gmt":"2026-10-14T08:01:27","slug":"chef-configuration-management-interview-questions-and-answers","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/chef-configuration-management-interview-questions-and-answers\/","title":{"rendered":"Chef Interview Questions, Explained: Resources, Run-Lists, Bootstrapping, and Test Kitchen"},"content":{"rendered":"\n

Chef interviews and day-to-day operations often revolve around the same fundamentals: resources, recipes, cookbooks, run-lists, node bootstrapping, and local testing. This guide is for DevOps engineers who want clear, interview-ready answers plus production-oriented examples.<\/p>\n\n\n\n

Originally published on 2015-09-02; fully revised and updated.<\/em><\/p>\n\n\n\n

Source material: learn.chef.io<\/a> (original Q&A format), reorganized here into a structured reference.<\/em><\/p>\n\n\n\n

Core Chef concepts interviewers ask most often<\/h2>\n\n\n\n
Concept<\/th>What it means in practice<\/th>Interview-ready answer<\/th><\/tr><\/thead>
Resource<\/td>A unit of desired state (package, service, file, template, user, etc.).<\/td>A resource describes what state must exist<\/em>, not just a command to run.<\/td><\/tr>
Recipe<\/td>An ordered collection of resources.<\/td>A recipe defines configuration policy for part of a system.<\/td><\/tr>
Cookbook<\/td>A package of recipes plus templates, files, attributes, and metadata.<\/td>A cookbook is the reusable delivery unit; a recipe is one part inside it.<\/td><\/tr>
Run-list<\/td>Ordered list of recipes\/roles a node applies.<\/td>Run-list controls what<\/em> runs and in which order<\/em>.<\/td><\/tr>
Node<\/td>Any managed machine (VM, bare metal, or instance).<\/td>A node is the compute target that runs chef-client and converges policy.<\/td><\/tr>
Starter Kit<\/td>Workstation files and credentials for secure Chef Server access.<\/td>It contains keys\/config needed for authenticated communication.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Why resource order and action order matter<\/h2>\n\n\n\n

Chef applies resources in the order they are declared during convergence. That means ordering can decide whether a run succeeds or fails.<\/p>\n\n\n

package 'httpd'<\/span>\n\nservice 'httpd'<\/span> do<\/span>\n  action [:enable, :start]\nend<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
The example above typically works because the package is installed before the service is managed.<\/p>\n\n\n
service 'httpd'<\/span> do<\/span>\n  action [:enable, :start]\nend\n\npackage 'httpd'<\/span><\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
This order can fail if the service provider cannot manage httpd<\/code> before the package exists.<\/p>\n\n\n\n
Case<\/th>Equivalent?<\/th>Why<\/th><\/tr><\/thead>
package then service<\/td>No (vs service then package)<\/td>Resource declaration order changes convergence behavior.<\/td><\/tr>
action [:enable, :start] vs [:start, :enable]<\/td>Not strictly identical<\/td>Actions are executed in listed order; boot\/runtime side effects may differ.<\/td><\/tr>
Different ordering of attributes inside one resource<\/td>Usually yes<\/td>Attribute line order inside the same resource does not typically change outcome.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n
file '\/etc\/motd'<\/span> do<\/span>\n  owner 'root'<\/span>\n  group 'root'<\/span>\n  mode '0755'<\/span>\n  action<\/span> :create\nend\n\nfile '\/etc\/motd'<\/span> do<\/span>\n  action<\/span> :create\n  mode '0755'<\/span>\n  group 'root'<\/span>\n  owner 'root'<\/span>\nend<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
chef-apply vs chef-client<\/h2>\n\n\n\n
Command<\/th>Best for<\/th>Typical scope<\/th>Common use<\/th><\/tr><\/thead>
chef-apply<\/td>Quick local experiments<\/td>Single recipe file<\/td>Learning, prototyping, one-off validation<\/td><\/tr>
chef-client<\/td>Managed node convergence<\/td>Run-list and cookbook content<\/td>Production configuration runs via Chef Server or local mode<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Chef Server options and bootstrap prerequisites<\/h2>\n\n\n\n
The original material describes two common server patterns: self-hosted Chef Server and hosted Chef offerings.<\/p>\n\n\n\n
Option<\/th>Control<\/th>Operational overhead<\/th><\/tr><\/thead>
Self-hosted Chef Server<\/td>High<\/td>You manage installation, upgrades, backup, and availability.<\/td><\/tr>
Hosted Chef service<\/td>Lower<\/td>Provider operates the control plane; you focus on policy and nodes.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
For bootstrapping a node from your workstation, you generally need:<\/p>\n\n\n\n