Monitoring PCI-Tagged Compute Instances with External IPs
Short answer
D Use the PUBLIC_IP_ADDRESS Security Health Analytics (SHA) detector to identify Compute Engine instances with external IP addresses and determine whether the compliance=pci tag exists on the instances.
Question
You work for a large international company that has several Compute Engine instances running in production. You need to configure monitoring and alerting for Compute Engine instances tagged with compliance=pci that have an external IP address assigned. What should you do?
Key Takeaways
The core concept tested is utilizing Security Health Analytics to detect security posture issues, specifically external IP exposure on tagged instances, rather than creating custom threat detection modules or using organization policies for reactive monitoring.
This question addresses configuring health monitoring and alerting for specific cloud assets using Security Health Analytics (SHA). It establishes that leveraging built-in SHA detectors combined with asset inventory filtering is the correct approach for identifying compliance-related risks.
Common mistake: Many learners incorrectly choose Option C, believing a custom module is necessary for specific tagging logic. However, SHA provides standard detectors like PUBLIC_IP_ADDRESS that can be filtered by tags via Cloud Asset Inventory, making custom modules unnecessary and more complex.
Expert Analysis
Why the Answer Is Correct
The correct approach is to use the PUBLIC_IP_ADDRESS Security Health Analytics (SHA) detector. SHA is designed to assess your environment against Google's best practices and industry standards. The PUBLIC_IP_ADDRESS detector identifies resources that are exposed to the public internet. Since the requirement is to monitor instances tagged with 'compliance=pci', you can configure SHA to generate findings for this specific detector and then filter or scope these findings based on the resource tags. This provides immediate visibility and alerting for non-compliant configurations without needing custom code.Why the Other Options Are Wrong
Option A suggests creating a custom Event Threat Detection module. ETD is primarily for detecting active threats and attacks (like malware execution or suspicious API calls), not for static configuration compliance checks like having an external IP. Option B proposes using an Organization Policy constraint. While OCPs can prevent the creation of such instances, the question asks for 'monitoring and alerting,' which implies detecting existing or new violations for visibility rather than hard-blocking them at policy level. Option C suggests a custom SHA module. While possible, it is over-engineered; the built-in PUBLIC_IP_ADDRESS detector already performs the core function of identifying external IPs, and SHA supports filtering by tags natively or through integration with Cloud Asset Inventory, so a custom module is not required.Community Comment Notes
Community consensus strongly favors Option D. One user noted that the category name in the API is PUBLIC_IP_ADDRESS, confirming the existence of this standard detector. Another user argued for a custom module but was corrected by the fact that SHA has out-of-the-box capabilities for this exact scenario, making the custom approach redundant. The discussion highlights the importance of knowing the built-in detectors available in Security Command Center before resorting to custom solutions.Official Reference
Exam Strategy
Always check if a built-in Security Health Analytics detector exists for the issue described before considering custom modules or event-based detections. For configuration compliance (like external IPs), SHA is the primary tool, whereas Event Threat Detection is for active threats.
Frequently Asked Questions
Why not use Organization Policy to block external IPs?
Organization Policies enforce compliance by preventing changes, but the question specifically asks for 'monitoring and alerting' to identify existing or new violations, which SHA provides via findings.
Can SHA filter findings by resource tags?
Yes, SHA findings are associated with resources, and you can filter or create alerts based on resource labels and tags within Security Command Center.
Discussion 2 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded.
From public community threads 2
-
c3tluna 👍 4 Answered CCreate a custom Security Health Analytics module. Scan Cloud Asset Inventory for Compute Engine instances. Filter on compute.googleapis.com/Instance assets. Match the compliance=pci tag. Check for the presence of an external IP address. Generate findings when both conditions match. This delivers targeted monitoring and alerting for PCI scoped workloads.
-
ssdny 👍 1 Answered DJust D. Category name in the API: PUBLIC_IP_ADDRESS ref : https://docs.cloud.google.com/security-command-center/docs/concepts-vulnerabilities-findings
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.