The DSC language extensions, cmdlets, and resources provide a standardized way of testing whether the expected state is present on a target system.

This allows the different aspects of the actual execution of configuring a system to be codified away from the information, deciding what settings to change or software to install. While the what dealt with writing down the expected state, the how is concerned with how to make it happen that way. Or, as Captain Picard would say, how to make it so.

This separation is important because it is expected that the list of things to do on a target computer will change, but it is not expected that how to execute that setting will change frequently. For example, there will be many types of files that you will create on many filesystems, but there are only a few ways to create these files. By separating the listing of the what, it allows the how to reduce variation by employing the idempotent DSC resources, an important part of a DevOps workflow.

To summarize the preceding content, we can say:

• The DSC DSL defines a standardized way of describing the expected configuration of a target system, whether that is one system or several thousand systems
• The DSC set of language extensions, cmdlets, and resources provide a standardized way of testing whether the expected state is present on the target system(s)
• The DSC engine provides a structured way of executing this expected state in an idempotent manner

We have seen the word idempotent in several places in this chapter so far, yet we haven't really defined it or covered why it is important. Let's clarify what exactly idempotence means now.