Cloud Digital Leader Scaling with Google Cloud operations Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  Organization Policy custom constraint to prevent creation of resources without the 'cost-center' label (preventive), plus Cloud Asset Inventory to identify existing unlabeled resources for remediation (detective)

  Why this is correct

  This is the complete two-layer approach: prevention (org policy blocks future non-compliant resources at creation time) and detection/remediation (Cloud Asset Inventory finds existing unlabeled resources so they can be labeled retroactively). Together they address both the future and existing state.

• ✗

  Only organization policy — once new resources are blocked, existing unlabeled resources don't matter

  Why it's wrong here

  An organization policy that only blocks future unlabeled resources does nothing to correct resources that already exist. Cost allocation by label requires every resource, including pre-existing ones, to carry the cost-center label; otherwise, those resources are misattributed or excluded from reports. The org policy is purely preventive, so without a separate discovery-and-remediation step, the billing data remains incomplete. In practice, you must pair the policy with Cloud Asset Inventory or similar to find and fix legacy resources, making this option insufficient on its own.

• ✗

  Only Cloud Asset Inventory monitoring — alerting on unlabeled resources is sufficient without preventing their creation

  Why it's wrong here

  Relying solely on Cloud Asset Inventory to detect unlabeled resources leaves a window of non-compliance between resource creation and the next inventory scan or alert. Even with real-time alerts, the resource already exists and may incur costs or be used for days before remediation, and detection alone does not enforce labeling. A detective control like Cloud Asset Inventory answers 'what is unlabeled now' but cannot answer 'how do we stop this from happening again.' Without an org policy constraint, engineers can still create unlabeled resources, so this approach is reactive, not preventive, and therefore incomplete.

• ✗

  Grant all engineers the 'Labels Admin' role to encourage them to add labels voluntarily

  Why it's wrong here

  Granting the 'Labels Admin' role to all engineers simply delegates the ability to modify labels, but it does not require them to apply the cost-center label—labeling remains voluntary and unenforced. In a large organization, engineers often skip labels under deadline pressure, and a permissive role does not create a hard check at resource creation time. Furthermore, giving every engineer high-level label admin privileges increases the risk of accidental or malicious label changes, undermining the integrity of cost data. This approach conflates permission with enforcement; a custom org policy constraint is the only way to make labeling a mandatory technical requirement.

Go deeper

Related to this question