The LCM service runs under the system account and has high privilege access to the system. However, the system account is not a user account, which causes trouble when you assume DSC can perform an action just like you did a moment ago. Common gotchas include accessing network file shares or accessing parts of the system that require user credentials. In PowerShell V4, these will typically fail with a generic Access Denied, which will most likely lead you down the wrong path when troubleshooting. Unfortunately, the only way to know this beforehand is to hope that the DSC resource or application you are executing documented the permissions they needed to run in PowerShell V4. Some DSC resources have parameters that accept a PSCredential object for this very purpose, so ensure that you inspect examples or the DSC resource itself to find out how to best handle access permissions in PowerShell V4. Trial and error will prove things one way or the other for you here.

This awkwardness is fixed in PowerShell V5, where a new parameter called PSDSCRunAsCredential is added to each DSC resource by the DSC engine. When specified, this parameter will indicate to DSC that the DSC resource needs to run under alternate credentials. This handles all the problems mentioned in the previous paragraph.

As described in the Execution phase in the The general workflow section, when first deploying using push or pull and trying out new configurations or troubleshooting existing ones, the frequent executions often cause problems. If the configuration run is interrupted or stopped mid-run, a pending.mof file is often left in place. This signals to DSC that a configuration is either in flight or that something else occurred and it should not run. When you try to run another configuration, you get an error saying that a configuration is currently in flight. To solve this, you need to delete the pending.mof file before running the Update-DscConfiguration or Start-DscConfiguration -Force cmdlet.