Puppet Interview Questions

31. What if I haven’t signed a CLA?
Answer: If you haven’t signed a CLA, then we can’t yet accept your code contribution into Puppet or Factor. Signing a CLA is very easy: simply log into your GitHub account and go to our CLA page to sign the agreement.

We’ve worked hard to try to find to everyone who has contributed code to Puppet, but if you have questions or concerns about a previous contribution you’ve made to Puppet and you don’t believe you’ve signed a CLA, please sign a CLA or contact us for further information. 

32. What are Resource types in Puppet?
Answer:

• Every resource is associated with a resource type, which determines the kind of configuration it manages.
• Puppet has many built-in resource types, like files, cron jobs, services, etc. See the resource type reference for information about the built-in resource types. 

33. What is Puppet Kick?
Answer: By default Puppet Agent request to Puppet Master after a periodic time which was known as “run interval”. Puppet Kick is a utility which allows you to trigger Puppet Agent from Puppet Master.

34. Why shouldn’t I use auto-sign for all my clients?
Answer: It is very tempting to enable auto-sign for all nodes, as it cuts down on the manual steps required to bootstrap a new node (or indeed to move it to a new puppet master).

Typically this would be done with a *.example.com or even * in the auto-sign.conf file.

This, however, can be very dangerous as it can enable a node to masquerade as another node and get the configuration intended for that node. The reason for this is that the node chooses the certificate common name (‘CN’ – usually its fqdn, but this is fully configurable), and the puppet master then uses this CN to look up the node definition to serve. The certificate itself is stored, so two nodes could not connect with the same CN (e.g. Alice. example.com), but this is not the problem.

The problem lies in the fact that the puppet master does not make a 1-1 mapping between a node and the first certificate it saw for it, and hence multiple certificates can map to the same node, for example,

Alice.example.com connects, gets node Alice { } definition.
bob.example.com connects with CN Alice. bob.example.com, and also matches the node Alice { } definition.
Without auto signing, it would be apparent that bob was trying to get Alice’s configuration – as the puppet cert process lists the full fqdn/CN presented. With auto-sign turned on, bob silently retrieves Alice’s configuration.

35. What are the chef and puppet used for?
Answer: Puppet and Chef are the major configuration management systems on Linux, along with CFEngine, Ansible. More than a configuration management tool, Chef, along with Puppet and Ansible, is one of the industry’s most notable Infrastructure as Code (IAC) tools.

36. What are the core commands of Puppet?
Answer:

Core commands of Puppet are:

• • Pupper Agent
  • Pupper Server
  • Puppet Apply
  • Puppet Cert
  • Puppet Module
  • Puppet Resource
  • Puppet Config
  • Puppet Parser
  • Puppet Help
  • Puppet Man

37. What’s Special About Puppet’s Model-driven Design?
Answer: Traditionally, managing the configurations of a large group of computers has meant a series of imperative steps; in its rawest state, SSH and a for a loop. This general approach grew more sophisticated over time, but it retained the more profound limitations at its root.

Puppet takes a different approach, which is to model everything — the current state of the node, the desired configuration state, the actions taken during configuration enforcement — as data: each node receives a catalog of resources and relationships, compares it to the current system state, and makes changes as needed to bring the system into compliance.

The benefits go far beyond just healing the headaches of configuration drift and unknown system state: modeling systems as data let Puppet simulate configuration changes, track the history of a system over its lifecycle, and prove that refactored manifest code still produces the same system state. It also drastically lowers the barrier to entry for hacking and extending Puppet: instead of analyzing code and reverse-engineering the effects of each step, a user can just parse data, and sysadmins have been able to add significant value to their Puppet deployments with an afternoon’s worth of Perl scripting.

38. How does merging work?
Answer: An external node Every node always gets a node object (which may be empty or may contain classes, parameters, and an environment) from the configured node_terminus. (This setting takes effect where the catalog is compiled; on the puppet master server when using an agent/master arrangement, and on the node, itself when using puppet apply. The default node terminus is plain, which returns an empty node object; the exec terminus calls an ENC script to determine what should go in the node object.) Every node may also get a node definition from the site manifest (usually called site.pp).

When compiling a node’s catalog, Puppet will include all the following: Any classes specified in the node object is received from the node terminus Any classes or resources which are in the site manifest but outside any node definitions Any classes or resources in the most specific node definition in the site.pp that matches the current node (if site.pp contains any node definitions)

Note 1: If site.pp contains at least one node definition, it must have a node definition that matches the current node; compilation will fail if a match can’t be found.

Note 2: If the node name resembles a dot-separated fully qualified domain name, Puppet will make multiple attempts to match a node definition, removing the right-most part of the name each time. Thus, Puppet would first try agent1. example.com, then agent1. example, then agent1. This behavior isn’t mimicked when calling an ENC, which is invoked only once with the agent’s full node name. 

Note 3: If no matching node definition can be found with the node’s name, Puppet will try one last time with a node name of default; most users include a node default {} statement on their site.pp file. This behavior isn’t mimicked when calling an ENC.

39. What are the classes?
Answer: Classes are named blocks of Puppet code that are stored in modules for later use and are not applied until they are invoked by name. They can be added to a node’s catalog by either declaring them in your manifests or assigning them from an ENC.

Classes generally configure large or medium-sized chunks of functionality, such as all of the packages, config files, and services needed to run an application. 

40. Explain what you mean by ordering and relationships?
Answer: By default, Puppet applies resources in the order they’re declared in their manifest. However, if a group of resources must always be managed in a specific order, you should explicitly declare such relationships with relationship meta parameters, chaining arrows, and the require function. Puppet uses four meta parameters to establish relationships, and you can set each of them as an attribute in any resource. The value of any relationship meta parameter should be a resource reference (or array of references) pointing to one or more target resources. before – Applies a resource before the target resource. require – Applies a resource after the target resource. notify – Applies a resource before the target resource. The target resource refreshes if the notifying resource changes. subscribe – Applies a resource after the target resource. The subscribing resource refreshes if the target resource changes.

If two resources need to happen in order, you can either put a before attribute in the prior one or a required attribute in the subsequent one; either approach creates the same relationship. The same is true of notifying and subscribe.