Practice Test #3

Domain contestation is designed for situations where domain ownership is disputed or an unauthorized party controls the domain in a tenant. Here, the domain is already used internally with 850 accounts and SAML SSO, so contestation would be highly disruptive and unnecessary. It risks account conflicts, service interruption, and complex migration. It does not align with the “least disruption” requirement and is not the right tool for internal segmentation.

Using a new domain (analytics-example.com) could technically enable a separate Cloud Identity tenant, but it violates the spirit of “all identities remain company-owned” under the primary corporate domain and creates identity fragmentation. Users would need alternate usernames or aliases, complicating lifecycle management, group membership, and access governance. It also increases operational overhead and can introduce inconsistent SSO and policy enforcement across tenants.

Granting Super Admin to a marketing program manager is excessive and violates least privilege. Super Admin has broad control over identity, security settings, and domain-wide configurations, creating significant risk. The requirement is to onboard a unit with minimal disruption and maintain policy, not to delegate top-level tenant control. Proper onboarding should be done by existing admins with scoped admin roles and group/OU-based controls.

VPC Service Controls creates service perimeters to reduce data exfiltration risk and control access to Google-managed services from outside a perimeter. It does not provide a scalable delegation model for IAM administration, nor does it inherently prevent a studio admin from viewing/changing IAM on other studios’ projects if they have permissions. It addresses boundary protection, not organizational access administration.

Cloud Identity Organizational Units (OUs) are used for applying identity and device policies within Cloud Identity/Google Workspace. Google Cloud IAM does not support assigning IAM policies directly to Cloud Identity OUs as principals or as a scoping mechanism. Access control in Google Cloud is scoped by resource hierarchy (org/folder/project) and granted to principals like users, groups, or service accounts.

Using project naming conventions with IAM Conditions is fragile and hard to operate at scale. Conditions evaluate request attributes and can be complex to maintain, and naming conventions are not a security boundary (projects can be renamed or created incorrectly). This also doesn’t naturally support delegated administration or prevent cross-studio visibility; it’s an anti-pattern compared to folders and group-based IAM.

Cloud KMS is for managing cryptographic keys and performing encrypt/decrypt/sign operations. While it supports IAM, audit logs, and rotation of keys, it is not a full secret storage system for passwords and API tokens with secret-version retrieval semantics. You could build an envelope-encryption solution, but it adds operational complexity and doesn’t natively satisfy “centrally stored secrets with per-secret IAM controls” and straightforward audited reads like Secret Manager.

Compute Engine guest attributes can store small pieces of data retrievable by the VM, but they are not intended for sensitive secrets governance. They lack dedicated secret lifecycle features such as robust per-secret IAM, built-in versioning/rotation workflows, and standardized secret access audit patterns. The question explicitly prohibits storing secrets in guest attributes, making this option noncompliant regardless of technical feasibility.

Compute Engine custom metadata is commonly used for configuration and bootstrapping, but it is not a secrets manager. Metadata is accessible to processes on the VM and can be exfiltrated if the instance is compromised; it also lacks strong secret lifecycle controls like versioning and rotation management. The policy explicitly forbids storing secrets in instance metadata, so this option is disallowed.

Incorrect. TCP/25 is not universally blocked by implied VPC firewall rules. Any SMTP limitations are typically due to anti-abuse measures, organization policy constraints, or external provider controls, not the baseline implied firewall behavior. From a pure VPC firewall perspective, egress is allowed by default, so you cannot claim TCP/25 is implicitly blocked regardless of user rules.

Incorrect. This describes a default-deny egress posture, which is not how GCP VPC works out of the box. By default, egress is allowed via an implied rule. You can implement default-deny egress by creating higher-priority egress deny rules and then adding explicit egress allow rules for required destinations/ports, but that is not the implied baseline.

Incorrect. There is no implied allow for inbound HTTP (tcp/80). Inbound traffic is denied by default unless explicitly allowed. HTTP access would require an ingress firewall rule (e.g., allow tcp:80 from 0.0.0.0/0 or a restricted CIDR) and, in many architectures, would typically be fronted by an external HTTP(S) load balancer with appropriate firewall rules for health checks and proxy ranges.

Incorrect. Sole-tenant nodes address workload isolation and certain compliance requirements, not image drift or patch automation. Policy Controller (Anthos) is primarily for Kubernetes admission control and configuration policy; it is not the right mechanism to restrict Compute Engine VM image sources or enforce OS patching on VMs. This option doesn’t meet the 48-hour patch requirement or VM lifecycle enforcement.

Incorrect. A Cloud Build pipeline for baking hardened images is useful for standardization, but Artifact Registry is for container and language artifacts, not Compute Engine VM images (which live in Compute Engine image resources). More importantly, image baking alone doesn’t ensure existing VMs receive critical patches within 48 hours or that baseline controls remain enforced throughout the VM lifecycle without an additional enforcement tool like OS Config.

Incorrect. Security Command Center Enterprise improves visibility (asset discovery, posture findings, vulnerability insights) and can integrate with response tooling, but it is not the primary service to enforce OS patching or continuously apply configuration state on Compute Engine VMs. SCC is largely detect/monitor; you would still need OS Config (or equivalent) to meet the explicit 48-hour patch and ongoing enforcement requirements.