Design security solutions for applications and data →hardMultiple Choice

SC-100 Practice Question: Design security solutions for applications and data

Exhibit

Refer to the exhibit.

```
$resources = Get-AzResource | Where-Object {$_.Tags.Keys -contains 'Confidentiality' -and $_.Tags.Values -contains 'High'}
foreach ($resource in $resources) {
    $lock = Get-AzResourceLock -ResourceName $resource.Name -ResourceGroupName $resource.ResourceGroupName
    if ($lock.LockLevel -ne 'CanNotDelete') {
        New-AzResourceLock -LockName 'HighConfLock' -LockLevel CanNotDelete -ResourceName $resource.Name -ResourceGroupName $resource.ResourceGroupName -Force
    }
}
```

Refer to the exhibit. You run the PowerShell script to protect high-confidentiality resources. After execution, you find that some resources with tag 'Confidentiality=High' are still unprotected. What is the most likely reason?

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Some resources are in a different resource group than expected.

The correct answer is A: some resources are in a different resource group than expected. If the PowerShell script scopes its protection (for example, applying locks or policies) to a specific resource group, any resource tagged 'Confidentiality=High' that resides in another resource group is outside the script's scope and remains unprotected, which matches the symptom of some tagged resources still being unprotected. Option B is not the likely cause because the failure is about scope, not lock-detection logic. Option C is incorrect because tag inheritance from resource groups is not the issue here—the resources already carry the tag. Option D is irrelevant because overwriting existing locks would not leave tagged resources unprotected.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Some resources are in a different resource group than expected.
Why this is correct
When the script enumerates Azure resources, it derives the target resource group from the `ResourceGroupName` property of each resource object. This property is accurate for resources inside a resource group, but some resources (e.g., subscription-level policy or role assignments) return a null value, and if the script falls back to a variable or default group, those resources are processed against the wrong resource group. As a result, the lock is created on a scope that does not match the actual resource, leaving the resource unprotected. This is the root cause that also makes the existence-check behavior misleading.
✗
The script does not check for existing locks properly.
Why it's wrong here
The script does include a check for existing locks before creating a new one, typically by calling `Get-AzResourceLock` and testing whether the returned object is null. The flaw is not the absence of a check, but the fact that the check is performed against the incorrectly derived resource group, so it can miss a lock that already exists on the true resource scope. This option is wrong because the script's guard logic is present; its effectiveness is undermined by the resource group mismatch, not by failing to call the check.
✗
Tags are not inherited from resource groups.
Why it's wrong here
This option confuses a tagging model with the lock scenario. In Azure, tags are applied directly to resources, and resource group tags are not inherited by the resources inside the group, so the script cannot rely on group-level tags to determine resource membership or protection status. The script's lock operations are based on resource identity and scope, not on tags, and the observed issue is a lock being applied to the wrong resource group, which has no connection to tag inheritance.
✗
The script overwrites existing locks.
Why it's wrong here
The script only calls `New-AzResourceLock` inside an `if` block that verifies the absence of an existing lock, so it cannot overwrite a lock that is already present. Overwriting would require either the `-Force` parameter or an explicit update/removal command, neither of which appears in the script. This option is wrong because the script's conditional creation is designed to preserve existing locks, even though the scope for that condition may be incorrect due to the resource group issue.

Go deeper

SC-100 Practice Question: Design security solutions for applications and data

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question