Exercise 3: Why Re-Running Start-DscConfiguration Does Nothing — Possible Solution
====================================================================

WHY NOTHING HAPPENS ON A COMPLIANT NODE
------------------------------
Per this chapter's own central finding, every DSC resource has a "check the current state, only act if it's actually different" test built directly into itself as a fundamental design principle. Running Start-DscConfiguration against a node that's already fully compliant with the configuration means every resource's own check reports "already matches," so no action is taken anywhere - no error is raised, nothing is reinstalled, no service is redundantly restarted.

THE CONTRAST WITH THE FUNDAMENTALS CAPSTONE'S Remove-Item
------------------------------
Per this chapter, the Fundamentals capstone's own Remove-Item call had no such built-in safety - Remove-Item simply attempts the deletion every time it's called, with no awareness of whether the file still exists or was already handled. That's exactly why the capstone needed an explicitly hand-written try/catch with -ErrorAction Stop wrapped around it, to safely handle the case of a file that might already be gone. A DSC resource never needs that same manual safety net, because idempotency (checking first, acting only if needed) is the resource's own built-in responsibility rather than something the script's author has to implement themselves.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that DSC resources have built-in state-checking that prevents redundant action on a compliant node, and correctly contrasts this with the Fundamentals capstone's Remove-Item, which required manually written try/catch logic specifically because it lacks that same built-in idempotency.