GCP Professional Cloud Security Engineer Practice Test

Keeping GCDS maintains the existing, automated provisioning and de-provisioning of users and groups. Adding a SAML-based single sign-on configuration with AD FS (or another IdP backed by Active Directory) delegates authentication to the on-premises IdP. Because Google no longer validates passwords, it no longer stores them, and any password change in Active Directory is immediately honored the next time a user authenticates. The other options either break group synchronization (Workforce Identity Federation), fail to remove Google-stored passwords (Secure LDAP or CSV import), or add significant operational overhead.

Granting IAM roles to purpose-specific Google Groups (for example, "[email protected]") centralizes policy bindings, so an auditor can review access by looking at the single group instead of hundreds of users. Delegating group-membership management to team leads with the Groups Admin role lets them add or remove members without changing IAM policies, satisfying the operational requirement. Enforcing auto-sync of group membership with the company's authoritative HR data source (via the Cloud Identity Groups API or Google Cloud Directory Sync) guarantees that when an employee leaves or changes roles, their account is promptly removed from the group and their inherited permissions automatically disappear. Simply granting organization-level roles to all users or requiring project owners to manage IAM directly would either violate least privilege or fail to reduce administrative overhead. Relying only on VPC Service Controls secures data exfiltration paths but does not address user-level permission management.

SDP already provides a built-in infoType, US_SOCIAL_SECURITY_NUMBER, that reliably detects the standard SSN pattern, so no additional configuration is needed for that element. The proprietary customer identifier has a unique format that is not covered by any built-in infoType, so the recommended approach is to define a custom regex detector (optionally combined with a hotword rule such as the literal text "CUST-") to target exactly the required pattern and reduce false positives. Creating custom detectors for SSNs would be unnecessary work, and choosing unrelated built-in infoTypes (e.g., CREDIT_CARD_NUMBER, PERSON_NAME, PHONE_NUMBER) would fail to detect the required data.

Google recommends having no more than two active user-managed keys per service account at any time. To rotate a key without downtime, you first create a second key, securely deploy the new key to the workload, verify successful authentication, and then delete the older key. This preserves continuous access because the application can switch to the new credential before the old one is removed. Simply deleting the existing key before deploying a replacement, or disabling the service account, would cause an outage. Re-encrypting or extending the key does not meet rotation requirements, because the underlying key material remains unchanged.

Cloud Storage object-listing operations are logged as Data Access entries with protoPayload.methodName="storage.objects.list" and protoPayload.serviceName="storage.googleapis.com". Restricting resource.type to gcs_bucket scopes the query to bucket-level operations, and specifying logName="projects/finance-prod/logs/cloudaudit.googleapis.com%2Fdata_access" guarantees that only the Data Access audit log is searched. The other options are incorrect because they either query the Admin Activity log, target the wrong resource type or method, or omit the logName filter and therefore risk returning entries from other log categories.

Using Cloud Storage in the "europe-west3" (Frankfurt) region guarantees that stored objects never leave the EU, whereas a multi-region such as "EU" still meets data-residency needs but would scatter replicas across several EU countries and provide no single-region locality for tightly coupled GPU workloads. Enabling CMEK with a Cloud KMS key ring that is also in "europe-west3" keeps the cryptographic keys inside the same jurisdiction and under the customer's control. Compute Engine VMs with attached NVIDIA GPUs launched in the same region ensure that temporary processing stays inside the EU and avoids cross-region egress. Filestore in the US or any configuration in a non-EU region would violate data-sovereignty rules, and relying on Google-managed encryption keys does not allow the customer to guarantee where keys are stored or who can access them.

Enabling organization-level Sensitive Data Protection discovery automatically profiles Cloud Storage buckets across all projects. To cover BigQuery data, each project that contains BigQuery resources needs a single data profile scan configuration, which automatically profiles every existing and newly created dataset in that project. Together, these settings provide continuous discovery, built-in risk scoring, and centralized visibility in the Sensitive Data Protection dashboard without requiring per-bucket or per-table jobs. Relying solely on manual inspection jobs, Cloud Asset Inventory, or Data Catalog policy tags would either miss continuous discovery, lack risk scoring, or require granular job scheduling.

Limiting exposure means removing standing Super Administrator privileges from day-to-day identities and granting them only the narrow administrative roles required for routine tasks. Google recommends maintaining at least one (preferably two) emergency or "break-glass" Super Administrator accounts that are not subject to SSO or MFA enforcement, use strong randomly generated passwords stored offline, and are monitored for any sign-in activity. This arrangement ensures recovery even if the primary IdP or MFA infrastructure is unavailable, satisfies least-privilege by removing broad rights from everyday accounts, and keeps audit logs for the seldom-used break-glass logins. The other options either keep routine Super Administrator use, depend on the availability of MFA/IdP for recovery, or rely on features (like automatic unlocking) that do not provide controlled, auditable emergency access.

Using Cloud Build triggers backed by Cloud Source Repositories and Cloud Scheduler meets the automation requirement. The pipeline invokes Packer to create a new image from the latest debian-11 base, applies the hardening scripts, updates packages, and runs a vulnerability-scanner container that exits non-zero if any high or critical CVEs are detected, stopping the build. On success, the build publishes the image to a custom family and a final step deletes older images so that only the three most recent remain. Approaches that rely on VM-side patch jobs, manual procedures, or simply referencing a public hardened family fail to satisfy one or more stated constraints (such as creating a gated golden image or enforcing retention).

The firm requires (1) at least 18 Gbps of throughput, (2) a private path that stays off the public internet, and (3) minimal latency without additional encryption overhead. Two physically diverse 10-Gbps Dedicated Interconnect circuits deliver an aggregate 20 Gbps, meet the 99.9 % availability SLA, and avoid the extra equipment and operational overhead of VPN or MACsec. HA VPN alone traverses the internet, violating the requirement. A 100-Gbps Dedicated Interconnect with MACsec far exceeds bandwidth needs and adds cost and configuration effort. Partner Interconnect adds a service-provider middle-mile that can introduce additional latency and operational dependency, and layering HA VPN adds complexity not needed for already-encrypted data. Therefore, redundant 10-Gbps Dedicated Interconnect circuits are the most appropriate and cost-effective choice.

Workforce Identity Federation lets administrators create a workforce identity pool that trusts an external IdP such as Azure AD (via OIDC or SAML). Researchers sign in to Azure AD, then exchange the resulting security token for short-lived Google Cloud credentials that map to carefully scoped IAM roles on the target project. Because no Google accounts or user-managed service-account keys are created, the solution aligns with the mandate to avoid provisioning accounts and long-lived secrets. Google Cloud Directory Sync and Google Workspace accounts would still create identities in Cloud Identity, while handing out service-account keys would violate the ban on persistent credentials.

Granting Dataflow Worker on the project lets the service account start and manage Dataflow jobs. Granting Storage Object Viewer on only the input bucket is sufficient for reading objects without allowing writes or bucket administration. Granting BigQuery Data Editor on the specific dataset lets the pipeline create and append tables but not administer the entire project. Granting Logging Log Writer on the project allows log export without additional privileges. The other options continue to use broad Owner, Editor, Admin, or Dataflow Admin roles, all of which provide permissions far beyond what the pipeline requires.

Google Cloud IAM Conditions let you attach an attribute-based Boolean expression to an individual role binding. The condition language supports both request.ip and request.time attributes, so you can restrict the BigQuery Data Viewer role to apply only when the caller's source IP is within 203.0.113.0/24 and the access time falls between 09:00 and 17:00 on weekdays. This enforces the required constraints while granting the minimal BigQuery Data Viewer permissions to the vendor group and does not require any additional infrastructure.

VPC Service Controls service perimeters restrict data egress but cannot enforce time-of-day constraints. Identity-Aware Proxy governs web access to applications, not direct BigQuery API calls, and a custom role without conditions would lack the necessary contextual controls. Access Context Manager service perimeters also cannot grant BigQuery IAM roles; they only define network and device restrictions for requests that are already authorized by IAM, so they would still need an IAM binding with the proper condition. Therefore, an IAM conditional role binding is the correct and most straightforward solution.

Workload Identity Federation lets external workloads (including GitHub Actions) exchange an external OIDC token for a short-lived Google Cloud access token, eliminating the need to store a service-account key. When you create a workload identity pool and a GitHub provider, GitHub issues an OIDC token at build time that Google's Security Token Service exchanges for an access token valid for up to one hour. Granting the pool permission to impersonate a narrowly scoped service account maintains least privilege. Using a gcloud-generated refresh token would leave a long-lived credential in the repository, violating policy. VPC Service Controls protect against data exfiltration but do not provide authentication. Storing and rotating the JSON key in Secret Manager still relies on a long-lived key and does not meet the short-lived-credential requirement.

2-Step Verification enforcement can be scoped to any child organizational unit or Google Group. By turning on enforcement only on the Finance OU, its users are forced to enroll after the grace period you define, while OUs higher in the hierarchy-including the one that contains the break-glass super-administrator-remain unaffected because child OU settings override inherited settings. Advanced Protection, context-aware access, or relying on backup codes do not themselves impose mandatory 2SV enrollment for a specific OU.

Activating Security Command Center at the organization level provides a single control plane and automatically onboards every current and future project, eliminating the need to manage per-project activations. Granting the security operations team the Security Center Admin role at the organization level allows them to configure services, create mute rules, and view all organization-wide findings. Giving each application team the Security Center Findings Viewer role only on its own projects limits access to read-only visibility for just those resources. The alternative options either activate SCC separately in every project, which introduces unnecessary operational overhead, use the Standard tier that lacks advanced detectors, or assign overly broad or incorrect IAM roles that fail to enforce least privilege.

OAuth 2.0's three-legged (authorization-code) flow lets the user authenticate with Google, approve a specific set of scopes-for example, devstorage.read_write-and returns a short-lived (≈1-hour) access token plus an optional refresh token. No static credentials are shipped in the binary, and the user can later revoke the app's consent from their Google Account, instantly invalidating the refresh token. Service account keys or API keys are long-lived and hard to revoke per user, while Workload Identity Federation addresses non-human workloads, not per-user delegation in a consumer mobile app.

Cloud Storage lifecycle management supports two actions that are relevant here: SetStorageClass (to transition objects to a different storage class) and Delete (to remove objects). To cut costs after 30 days, you configure a SetStorageClass action that transitions objects from Standard to Nearline when their Age condition reaches 30 days. To meet the 12-month retention that starts at that point, you add a Delete action with an Age condition of 395 days (30 + 365). This ensures objects live 30 days in Standard, 365 additional days in Nearline, and are then deleted. Using Delete first, using SetStorageClass to delete data, or using only one type of action would fail to meet either the cost-optimization or retention requirement.

Create an organization-wide access policy in Access Context Manager and define a custom access level that allows requests originating either from the trusted on-premises CIDR ranges or from devices that satisfy the required endpoint-verification attributes. Then create a VPC Service Controls service perimeter that protects Cloud Storage, add the finance folder to the perimeter so all present and future projects are included, and attach the access level to the perimeter's ingress rules. Any request coming from outside the perimeter must now meet the specified network or device attributes before it is allowed.

VPC firewall rules apply to traffic to or from VM instances and cannot validate device posture or protect Google-managed service APIs. Cloud Armor secures HTTP(S) traffic through external load balancers and cannot filter direct Cloud Storage JSON or XML API calls, nor can it evaluate device compliance. IAM conditional bindings do inherit to child projects, but IAM Conditions cannot reference device compliance attributes and would require role-specific bindings that do not universally cover all Cloud Storage access paths, making them insufficient for this requirement.

Because the keys must remain in an on-premises HSM and administrators need the ability to make data inaccessible by disabling that external key, Cloud External Key Manager (EKM) is the correct choice. EKM allows Cloud Storage objects to be protected by a key that resides and is operated entirely outside Google's infrastructure; turning off or destroying the external key immediately renders the data unreadable (crypto-shredding).

Using CMEK with Cloud KMS software keys would store keys in Google-managed software, violating the "never leave" requirement. CMEK with Cloud HSM keeps keys inside Google-hosted HSMs, still outside the organization's premises. Relying on Google default encryption gives Google full control of the keys and provides no immediate crypto-shred capability to the customer.