Rule Evaluation for components that are out of the configuration scope

Summary of the new feature / enhancement

We want to be able to evaluate the compliance of all current instances of a given Resource, even those not specified as part of the config, against an assertion. For example:

I have my config define 2 AADConditionalAccessPolicy instances with all their key/value pair: PolicyA and PolicyB. My config specifies that both policy needs to have their EnableMFA property set to $true. This part is easy to monitor.

Now, I want to make sure that if someone comes in and creates a 3rd Conditional Access Policy (PolicyC), that if this new policy doesn't have EnableMFA set to true, that we treat it as a drift, even if my config doesn't explicitly include the definition for PolicyC.

Proposed technical implementation details (optional)

It would be great to specify a rule to evaluate at the DSC Resource level and not the instance level.

In the example given above with the 2 policies, you don't want each instance to expose this property. For example, we don't want to end up with something like the following:

AADConditionalAccessPolicy PolicyA
{
ID = "PolicyA"
RuleToEvaluate ="EnableMFA eq true"
}

AADConditionalAccessPolicy PolicyB
{
ID = "PolicyB"
RuleToEvaluate ="EnableMFA eq true"
}

Instead, we should have something more generic that applies to all instances of a given resource. E.g.:

DSCRuleToEvaluate CAP
{
ResourceName = "AADConditionalAccessPolicy"
RuleDefinition = "EnableMFA eq true"
}

Another less appealing option would be to let the user specify that any instance not captured as part of the configuration scope be detected as a drift. For example, if the config was to define 2 AADConditionalAccessPolicy instances, and someone was to create a 3rd one which is not defined in the config, that the mere fact that an instance of AADConditionalAccessPolicy exists on the tenant and is not captured in the config is a drift. There could be a lot of noise generated from adopting this approach.

The issue names no files, tests, or entry points, so begin by locating the configuration and assertion-evaluation paths. Clarify how a resource-level rule should represent scope and evaluate out-of-scope instances, then add coverage showing that an unconfigured PolicyC is checked. Done means the resulting drift behavior is defined and tested.