The last item on the list of resources is the composite resource. The composite resource actually plays a special role in the DSC universe. A composite resource consists of one or more configurations that fulfill generic tasks and are mainly used to abstract some of the complexity of DSC, or aid developers with shipping their application.

Take a complex SQL Always On configuration which is needed to support applications. The developer knows how they want their database to look, but doesn't necessarily care much about the infrastructure layer beyond that. As an Ops person, you can provide this infrastructure layer as a composite resource that only takes a few simple parameters, such as DatabaseName, Collation, and PreferredSite:

# The folder structure reminds us of MOF-based resource modules
# MyInfrastructureResources
# ---> MyInfrastructureResources.psd1
# ---> MyInfrastructureResources.psm1
# ---> DscResources
# ---> SqlConfiguration
# ---> SqlConfiguration.psd1
# ---> SqlConfiguration.psm1

configuration HidingTheComplexity
{
    param
    (
        $DatabaseName,

        $Collation
    )

    Import-DscResource -ModuleName MyInfrastructureResources

    SqlConfiguration SqlConfig
    {
        DatabaseName = 'MyAwesomeDb'
        Collecation = 'Some crazy collation'
    }
}

The infrastructure layer then becomes just another DSC resource that the developer can use to configure the database as needed without caring about the underlying infrastructure.

This kind of collaboration is recommended over the use of partial configurations, which would also fit the bill. The benefit of composite resources is that errors in the configuration are thrown during the build process of the MOF, while partial configurations will only ever throw errors on the client while being assembled.