skip to content

In PowerShell Desired State Configuration, what does a configuration compile into, and how does the Local Configuration Manager apply it in push mode versus pull mode?

level: middleimportance: should knowfreq 35%

answer

  1. describe the end state, not the steps
  2. invoking it compiles rather than runs
  3. an agent on the node does the work
  4. one function decides whether to act
  5. who initiates: operator or agent

basics

~20 s

A DSC configuration compiles into one MOF document per target node describing desired state. The Local Configuration Manager agent on the node applies it: in push mode you send the MOF with Start-DscConfiguration; in pull mode the agent fetches it on a schedule and can re-correct drift.

solid answer

~50 s

A `Configuration` block is not a script that runs — invoking it *compiles* it, producing a MOF file per node that declares desired state as resource instances. The agent that consumes it is the Local Configuration Manager, which runs on the target machine. In push mode an operator sends the MOF with `Start-DscConfiguration -Path .\mof -Wait -Verbose`; nothing further happens until someone pushes again, so drift goes uncorrected. In pull mode the LCM is configured with a meta-configuration pointing at a pull server or service, and it fetches configurations and required resource modules itself on a refresh interval, then re-evaluates on its own schedule — with `ConfigurationMode` deciding whether it merely reports drift (`ApplyAndMonitor`) or fixes it (`ApplyAndAutoCorrect`). Idempotence comes from each resource implementing Get, Set and Test: the LCM calls Test first and only invokes Set when the node is out of state.

code

powershell · 21 lines
powershell
Configuration WebServer {
    Import-DscResource -ModuleName PSDesiredStateConfiguration

    Node 'localhost' {
        File SiteRoot {
            DestinationPath = 'C:\inetpub\site'
            Type            = 'Directory'
            Ensure          = 'Present'
        }

        Service W3SVC {
            Name      = 'W3SVC'
            State     = 'Running'
            DependsOn = '[File]SiteRoot'
        }
    }
}

WebServer -OutputPath .\mof          # compiles to .\mof\localhost.mof
Start-DscConfiguration -Path .\mof -Wait -Verbose   # push
Test-DscConfiguration -Detailed                     # check for drift

go deeper

for a junior

Be able to say DSC is declarative — you describe the end state and an agent makes the machine match — and that compiling a configuration produces a MOF file per node rather than running anything.

for a middle

Explain the pipeline end to end: configuration compiles to MOF, the Local Configuration Manager applies it, resources expose Get/Set/Test, and Test-before-Set is what makes re-application a no-op. Contrast push with pull.

for a senior

Demonstrate operational judgment — choosing pull with ApplyAndAutoCorrect when drift must self-heal versus push from a pipeline when changes are gated, handling credential encryption via certificates, and knowing how to report compliance across a fleet.

for a principal

Own the estate-level question: whether continuous convergence is the right model at all, how you version and promote configurations, and what you do about nodes whose desired state is defined by an image or a container rather than an agent.

## The declarative model DSC asks you to describe *what the machine should look like*, not the steps to get there. That description is written in a `Configuration` block, which looks like PowerShell but is a distinct keyword with its own parser: ```powershell Configuration WebServer { Import-DscResource -ModuleName PSDesiredStateConfiguration Node 'web01' { File SiteRoot { DestinationPath = 'C:\inetpub\site' Type = 'Directory' Ensure = 'Present' } Service W3SVC { Name = 'W3SVC' State = 'Running' DependsOn = '[File]SiteRoot' } } } ``` Inside a `Node` block, each entry is a **resource instance**: a resource type (`File`, `Service`, `Registry`, `Environment`, `Archive`, `Package`, `Script`, `User`, `Group`, plus community and vendor resources), a name you choose, and a hashtable of properties. `DependsOn` expresses ordering between instances — otherwise the engine is free to order them itself, because you declared state, not a sequence. ## Compilation produces MOF Running `WebServer -OutputPath .\mof` does not configure anything. It **compiles**: the output is one `.mof` file per node, named after the node. MOF (Managed Object Format) is a plain-text, tool-neutral document describing the desired resource instances. Two consequences follow: * Errors in resource property names and types surface at compile time, on your workstation, before any machine is touched. * MOF is plain text. Any credential you embed lands in it in the clear unless you encrypt it with a certificate — which is why `PSDscAllowPlainTextPassword` exists as a deliberately alarming opt-in, and why real deployments configure the LCM with a `CertificateID` so credentials are encrypted to the node's public key. ## The Local Configuration Manager The LCM is the agent baked into Windows PowerShell on the target. It receives or fetches the MOF, and for each resource instance calls the resource's three operations: * **Get** — report current state (`Get-TargetResource`, or `Get()` on a class-based resource). * **Test** — return a boolean: is the node already in the declared state? * **Set** — make it so. The LCM calls **Test first and only calls Set when Test returns false**. That is the whole source of idempotence — applying the same configuration twice changes nothing the second time, provided the resource author wrote an honest Test. A badly written resource whose Test always returns `$false` turns every run into a re-apply, which is one of the classic DSC bugs. The LCM's own settings live in a separate **meta-configuration**, compiled from a `[DSCLocalConfigurationManager()]` block and applied with `Set-DscLocalConfigurationManager`. That is where `RefreshMode`, `ConfigurationMode`, the intervals and the certificate thumbprint are set. `Get-DscLocalConfigurationManager` reads them back. ## Push versus pull **Push** (`RefreshMode = 'Push'`): an operator or pipeline delivers the MOF and starts the run. ```powershell Start-DscConfiguration -Path .\mof -Wait -Verbose ``` Simple, immediate, and easy to wire into CI. Its weakness is that it is an event, not a loop: after the push, nothing revisits the machine. Someone edits a config file by hand and the drift sits there until the next push. Push also requires the pushing host to reach the target and to carry any resource modules the node needs, since push does not distribute modules. **Pull** (`RefreshMode = 'Pull'`): the LCM is pointed at a pull endpoint — historically an HTTPS pull server, or a managed service — and it does the fetching. It downloads the configuration keyed by a configuration name or a GUID, downloads the resource modules it needs (with checksums), and applies them. Two timers govern it: `RefreshFrequencyMins` (how often to check the server, default 30) and `ConfigurationModeFrequencyMins` (how often to re-evaluate the current configuration, default 15). `ConfigurationMode` decides what a re-evaluation does: * `ApplyOnly` — apply once, never re-check. * `ApplyAndMonitor` — re-check and *report* drift, but do not fix it. The default. * `ApplyAndAutoCorrect` — re-check and re-apply, actively correcting drift. That continuous-correction loop is DSC's distinctive claim, and it is only available in pull mode with auto-correct on. Pull also scales without the pushing host needing line-of-sight to every node, and it distributes modules for you. ## Inspecting state `Test-DscConfiguration` answers "is this node compliant?" as a boolean, or with `-Detailed` names the non-compliant resources. `Get-DscConfiguration` reports the current state of each resource as the resources themselves see it. `Get-DscConfigurationStatus` shows the outcome of recent runs, including failures. These are the drift-reporting surface an operator actually uses. ## Version caveat Everything above describes DSC v1/v2 as it exists in Windows PowerShell 5.1, which is where MOF, the LCM and pull servers live. DSC v3 is a rewrite along different lines — a standalone cross-platform `dsc` executable with resources described by JSON/YAML manifests and no MOF — so state the version you are talking about rather than blending the two.

  • What exactly makes a DSC configuration idempotent?
    The resource contract. Every DSC resource implements Get, Set and Test, and the Local Configuration Manager calls Test before Set — Set runs only when Test reports the node is out of the declared state. Re-applying an already-compliant configuration is therefore a no-op. A resource whose Test always returns false destroys that property and makes every run re-apply.
  • How do you detect configuration drift on a node without changing it?
    `Test-DscConfiguration` returns a compliance boolean, and `-Detailed` names the non-compliant resource instances; `Get-DscConfiguration` reports current state per resource, and `Get-DscConfigurationStatus` shows recent run outcomes. For continuous reporting, set the LCM's `ConfigurationMode` to `ApplyAndMonitor`, which re-evaluates on schedule and reports drift without correcting it.
  • What happens to a credential you put in a DSC configuration?
    It is written into the compiled MOF, and MOF is plain text. PowerShell blocks this by default; embedding one unencrypted requires the explicit `PSDscAllowPlainTextPassword` flag in configuration data, which should be treated as a red flag. The supported route is to configure the LCM with a `CertificateID` so credentials are encrypted to the node's certificate at compile time and decrypted only on the node.

saying these in an interview costs you the question

  • Thinks a Configuration block executes top to bottom
  • Says push mode continuously corrects drift
  • Forgets the LCM is what applies the MOF
  • Assumes MOF files encrypt credentials automatically
  • Confuses Test-TargetResource with Get-TargetResource

context

resolving links…