You are choosing how to manage machine state for a fleet that is mostly Windows with a growing Linux share. What is the honest case for PowerShell DSC today against Ansible or Terraform, and how would you decide?
answer
- different layers, not competitors
- provisioning versus in-guest state
- who runs the loop: agent or operator
- the rewrite changed the whole model
- cheapest convergence is a rebuild
basics
~20 sThey solve different problems: Terraform provisions infrastructure, Ansible pushes configuration on demand, and DSC runs an on-node agent that can continuously correct drift on Windows. Choose by whether you need continuous convergence, how strong your Linux story must be, and whether rebuilding beats converging.
solid answer
~60 sStart by separating the jobs. Terraform provisions and tracks infrastructure lifecycle against a state file; it is not an in-guest configuration tool. Ansible is agentless push — it reaches Windows over WinRM or SSH, runs a play, and stops; convergence happens when you run it. DSC is the only one of the three with an agent that lives on the node and can re-evaluate and auto-correct on its own schedule. That continuous-convergence property is DSC's real differentiator, plus deep Windows resource coverage and being in-box on Windows PowerShell 5.1. The honest counterweight: the DSC ecosystem stalled for years, the classic MOF/pull-server model is Windows-bound and its managed hosting has moved on, and DSC v3 is a promising but young cross-platform rewrite. For a mixed fleet I would usually make Terraform own provisioning and Ansible own configuration for uniformity across both operating systems, and reach for DSC only where a Windows-specific resource or a hard continuous-correction requirement justifies a second system — including invoking DSC resources from Ansible rather than running two control planes.
go deeper
Know that these are different kinds of tool — one creates machines, the others configure what is inside them — and that DSC is the Windows-native declarative option. You are not expected to arbitrate the choice.
Be able to place each tool on its layer and describe the agent-versus-agentless distinction, including that only DSC re-evaluates on its own schedule without an operator or scheduler triggering a run.
Show you weigh operational cost, not features: two control planes mean two credential and audit stories, resource-ecosystem health is a real risk, and a scheduled agentless run may satisfy the drift requirement more cheaply than an agent.
Own the framing. Establish whether drift must self-heal, whether Linux is first-class, and whether rebuild beats repair before naming any tool — and be prepared to argue that the right answer is to eliminate in-guest convergence rather than optimise it.
## First, refuse the false comparison The question is usually posed as a three-way contest, and part of the answer is declining it. These tools occupy different layers. **Terraform** manages *infrastructure lifecycle*: create, change and destroy resources at a provider's API — virtual machines, networks, load balancers, DNS, managed services. It keeps a state file mapping declared resources to real ones and computes a plan to reconcile them. What it is deliberately weak at is configuring the *inside* of a machine. You can bolt provisioners on, but that is widely regarded as an escape hatch, not a design. **Ansible** manages *in-guest configuration*, agentlessly. A control node connects — SSH for Linux, WinRM (or SSH) for Windows — copies modules over, runs them, and disconnects. Windows targets need PowerShell present, but no persistent Ansible agent. Convergence is an event: it happens when a play runs. **DSC** also manages in-guest configuration, but with an **agent**. On Windows PowerShell 5.1 the Local Configuration Manager is already there, and in pull mode with `ConfigurationMode = 'ApplyAndAutoCorrect'` it re-evaluates on its own timer and repairs drift without anyone launching anything. No other option in this list does that natively. ## The genuine case for DSC * **Continuous convergence.** If the requirement is "this service must be running and this setting must hold, even if someone changes it at 3am", an on-node agent is the mechanism that satisfies it. A scheduled Ansible run approximates it, at the cost of a control plane that must reach every node on schedule. * **Windows depth.** The DSC resource ecosystem covers Windows features, roles, registry, certificates and IIS with a fidelity born of being written by Windows people. * **In-box.** On Windows PowerShell 5.1 there is nothing to install on the node, which matters in locked-down or air-gapped estates. * **Composability.** DSC does not have to be your control plane. Ansible ships a module for invoking DSC resources on Windows hosts, and Azure's machine-configuration offering builds on the DSC resource model. You can keep one orchestration tool and still consume DSC resources. ## The honest counterweight * **The ecosystem stalled.** Between roughly the mid-2010s peak and the v3 rewrite, DSC saw little investment; many community resource modules aged, and "is DSC still a thing?" became a fair question rather than a rude one. * **The classic model is Windows-shaped.** MOF compilation, the LCM and pull servers grew up inside Windows PowerShell 5.1. PowerShell 7 did not simply inherit them, and running DSC on Linux was never a first-class story in v1/v2. * **Hosted pull moved.** The managed pull service most people used was Azure Automation State Configuration; Microsoft has since steered customers toward Azure machine configuration. If your plan assumed the old service, verify its current status before designing around it. * **v3 is a rewrite, not an upgrade.** DSC v3 is a standalone cross-platform `dsc` executable with JSON/YAML resource manifests and no MOF, and it does not require PowerShell. That is the right direction, but adopting a young tool is a different risk calculus from adopting a mature one, and v1/v2 knowledge does not transfer wholesale. * **Two systems cost more than one.** Running Ansible for Linux and DSC for Windows means two DSLs, two credential stories, two audit trails and two on-call runbooks. Uniformity has real value that pure per-platform optimisation ignores. ## The question that actually decides it Before comparing tools, establish three things. 1. **Is drift a real risk, and must it self-heal?** If humans log into these machines and change things, an agent that corrects continuously earns its keep. If the machines are built by a pipeline and nobody touches them, convergence-on-demand is enough — and the better answer may be to stop converging altogether. 2. **Are the Linux hosts first-class or incidental?** "A growing Linux share" usually means they will not stay incidental. Choosing a Windows-first tool because Windows is the majority today buys a migration later. 3. **Is rebuild cheaper than repair?** Immutable infrastructure changes the frame entirely. If a node can be replaced from a golden image or a container in minutes, drift correction is a solution to a problem you deleted: Terraform (or your cloud's equivalent) replaces the instance, Packer or a container build bakes the state, and you need no in-guest convergence loop at all. The strongest senior answer often ends here rather than at a tool. ## How I would answer under pressure "Terraform owns provisioning regardless — it is not competing with the other two. For in-guest state I would default to one tool across both operating systems for uniformity, which today usually means Ansible. I would use DSC where a specific Windows resource or a hard continuous-correction requirement justifies it, ideally invoked from the same orchestrator rather than as a parallel control plane. And I would push hard on whether these machines need to be converged at all, because the cheapest configuration management is the kind you replaced with a rebuild."
- Where does Terraform stop and a configuration tool start?Terraform reconciles infrastructure objects at a provider API against a state file — instances, networks, DNS, managed services. It has no opinion about what runs inside a booted machine. Configuration tools own that interior. Using Terraform provisioners to configure a guest is widely treated as an escape hatch, because it puts imperative in-guest steps inside a declarative resource graph and undermines plan/apply.
- Can you use DSC and Ansible together rather than choosing?Yes, and it is often the pragmatic answer. Ansible provides one control plane, credential story and audit trail across Linux and Windows, while a dedicated module invokes DSC resources on Windows hosts where the DSC ecosystem has coverage you would otherwise reimplement. Azure's machine-configuration offering likewise builds on DSC's resource model. You consume DSC resources without running a second orchestrator.
- How does immutable infrastructure change this decision?It can remove it. If nodes are built from a golden image or shipped as containers and replaced rather than repaired, drift has no time to accumulate and no convergence agent is needed — provisioning plus an image build covers the ground. In-guest configuration management then matters mainly for long-lived pets, physical hosts and estates where rebuild is slow or politically expensive.
- What changed in DSC v3 that affects a long-term bet?v3 is a rewrite rather than an increment: a standalone cross-platform `dsc` executable, resources described by JSON/YAML manifests, no MOF, and no dependency on PowerShell itself. That fixes the Windows-shaped constraints of v1/v2, but it also means existing MOF-and-LCM expertise and tooling do not carry over unchanged, and you are adopting a young ecosystem.
saying these in an interview costs you the question
- Treats Terraform and DSC as competitors for one job
- Says DSC is dead so never evaluate it
- Claims Ansible needs an agent installed on Windows
- Assumes DSC v3 is just a newer version of v1
- Picks a tool before asking whether drift must self-heal