Free CLOUD-SECURITY-ENGINEER Practice Test

To enforce organization-wide use of a specific OS image, you need two components: access permissions and policy enforcement. Option B grants users the compute.imageUser role in the security team's project, allowing them to use the hardened image. Option D implements the compute.trustedImageProjects organization policy constraint, which restricts VM creation to only use images from allowed projects. Together, these ensure all VMs can only use the approved hardened image while maintaining centralized management.

A. Granting compute.imageUser in users' own projects doesn't provide access to the security team's image.

C. Storing the image in every project creates unnecessary duplication and operational overhead.

E. Removing VM creation permissions from users is overly restrictive and creates operational bottlenecks.

1. Google Cloud Documentation - "Organization Policy Service" - Trusted Image Projects constraint (https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints)

2. Google Cloud Documentation - "Compute Engine IAM roles" - compute.imageUser role definition (https://cloud.google.com/compute/docs/access/iam)

3. Google Cloud Security Best Practices - "Image management and access control" (https://cloud.google.com/architecture/framework/security/data-governance)

The goal is to enable developer velocity while maintaining security, which is a core principle of DevSecOps. Mandating Infrastructure as Code (IaC) and integrating static analysis into the CI/CD pipeline "shifts security left." This approach automates the security review by programmatically checking infrastructure configurations against predefined policies before deployment. This prevents non-compliant resources from being created, provides immediate feedback to developers, and removes the bottleneck of manual reviews. The other options describe detective controls (A, C) which are reactive, or a strategy that avoids the problem rather than solving it (D).

A. Using Forseti is a detective control that identifies misconfigurations in production, which is reactive, not preventive as required by the scenario.
C. Routing traffic through managed routers is a network-level detective control for traffic analysis, not a preventive control for deployment configurations.
D. This option avoids deploying to production in GCP, failing to solve the core problem of enabling safe and rapid production deployments.

1. Google Cloud Architecture Framework, "Security, privacy, and compliance design principles", section "Automate security". This document advocates for codifying security policies and integrating them into the CI/CD process to provide fast feedback and prevent insecure configurations.

2. Google Cloud Documentation, "Policy validation with gcloud terraform vet". This tool is a prime example of static analysis for IaC. The documentation states it lets you "test your Terraform plan against organization policies... before you apply the plan," which directly aligns with the described solution.

3. Google Cloud Blog, "Shifting left on security: A new and improved way to secure your GCP environment". This article details the philosophy and benefits of integrating security checks early in the development lifecycle (CI/CD) using IaC.

This scenario requires a scalable and delegated access management model integrated with an on-premises directory. Using Google Cloud Directory Sync (GCDS) (E) synchronizes users and, crucially, group memberships from the on-premises directory to Cloud Identity. Organizing projects into folders by business unit and assigning IAM permissions to the synchronized Google groups at the folder level (B) provides a scalable and isolated delegation model. When a user's group membership changes on-premises, GCDS syncs the change, and their access to Google Cloud resources is automatically updated, fulfilling all requirements.

A. VPC Service Controls create data exfiltration perimeters around projects; they do not manage IAM permissions for user access control.
C. Organization Units (OUs) in Cloud Identity are for applying policies to users (e.g., 2FA requirements), not for grouping resources or granting IAM permissions.
D. Using IAM Conditions based on project names is less scalable and more error-prone than using the resource hierarchy with folders for managing permissions.

1. Google Cloud Documentation, "Resource hierarchy". Section "Using the resource hierarchy for access control". This section explains that folders can be used to group resources that share common IAM policies, ideal for mapping to organizational structures like business units.

2. Google Cloud Documentation, "About Google Cloud Directory Sync". This document explains that GCDS synchronizes data, including users and groups, from an external directory service to Google Cloud, enabling centralized identity management.

3. Google Cloud Documentation, "IAM overview". This document describes how permissions are granted to principals (users, groups) on resources and how the resource hierarchy (folders) allows for policy inheritance.

Shared VPC is the recommended Google Cloud design for centralizing network administration. It allows an organization to connect resources from multiple projects to a common Virtual Private Cloud (VPC) network. A central "host project" owns the shared network resources (VPC, subnets, firewalls, VPNs), and "service projects" use those resources. This model enables the network security team to manage the network centrally in the host project while delegating project administration to other teams in their respective service projects. This directly meets the requirements for centralized control and connectivity to on-premises environments.

B. This approach is decentralized, granting broad permissions in each project, which is the opposite of the requirement for centralized control.
C. VPC peering connects networks but does not centralize the management of firewall rules or subnets; each project would still manage its own network resources.
D. A Cloud VPN Gateway is a component for connectivity, not a design pattern for centralizing administrative control over all networking resources.

1. Google Cloud Documentation, "Shared VPC overview". "Shared VPC allows an organization to connect resources from multiple projects to a common Virtual Private Cloud (VPC) network so that they can communicate with each other securely and efficiently using internal IPs from that network... You designate a project as a host project and attach one or more other service projects to it."

2. Google Cloud Documentation, "Shared VPC". "With Shared VPC, a host project owns the networks and subnets. A central network administrator for the host project controls the network. Other projects, called service projects, can be granted permission to use the host project's networks."

3. Google Cloud Architecture Framework, "Network design and security". Section: "Centralized vs. distributed network functions". This section discusses the benefits of centralized models like Shared VPC for consistent policy enforcement.

The company's concern is specifically about access to their data by internal Google employees. Access Transparency and Access Approval are the services designed to address this. Access Transparency provides near real-time logs of actions taken by Google staff when they access customer content. Access Approval allows you to require explicit approval from your organization before Google employees can access your data for support purposes. This combination provides both visibility and direct control over access by Google personnel, directly mitigating the stated risk.

A. Customer-managed encryption keys (CMEK) provide control over encryption keys but do not prevent justified access by Google support staff, as services can still use the key on your behalf.
B. IAM is used to manage access for your own organization's users and service accounts, not for Google employees performing administrative or support duties.
C. Admin Activity logs record actions taken by members of your organization within your Google Cloud projects, not actions taken by Google staff.

- Google Cloud Documentation, "Access Approval overview." It states, "Access Approval allows you to approve eligible access requests from Google employees before they can access your Google Cloud project's data and configurations."

- Google Cloud Documentation, "Access Transparency overview." It states, "Access Transparency provides you with logs of actions taken by Google staff when accessing your Google Cloud content."

- Google Cloud Whitepaper, "Trusting your cloud provider," section "Operational transparency and control." This section details how Access Transparency and Access Approval provide customers with control and visibility.

Storing plain text secrets in source code is a major security risk. The best practice is to store secrets externally and retrieve them at runtime. Encrypting the secrets with a Customer-Managed Encryption Key (CMEK) via Cloud KMS and storing the resulting ciphertext in a controlled-access location like Cloud Storage is a secure pattern. The application's service account would be granted IAM permissions to decrypt the secret using the key, but the secret itself is never stored in plaintext in the code repository. This separates the secret from the code and enforces access control.

A. Storing secrets in Cloud SQL without encryption is just moving the plain text secret to a different location; it doesn't solve the core problem.
C. Cloud Data Loss Prevention (DLP) is used for discovering and classifying sensitive data, not for securely storing and managing application secrets.
D. The choice of VM type (preemptible) and storage (local SSD) is irrelevant to the secure management of application secrets within a code repository.

1. Google Cloud Documentation

"Secret management"

Section: "Best practices". This guide recommends storing secrets in a dedicated system like Secret Manager or

for a manual approach

using Cloud KMS for encryption and Cloud Storage for the encrypted blob.

2. Google Cloud Documentation

"Customer-managed encryption keys (CMEK)"

Section: "When to use CMEK". This document explains how CMEK gives customers control over the keys used to encrypt data at rest in services like Cloud Storage.

3. Google Cloud Documentation

"Using Cloud KMS with other services". This page details the integration pattern of using Cloud KMS to encrypt data before storing it in another service like Cloud Storage.

The "domain restricted sharing" organization policy is the correct tool to control which domains can be added to IAM policies. To allow a specific external partner, you should not disable the policy. Instead, you modify the policy constraint, set its value to "Custom," and add the external partner's unique Google Workspace or Cloud Identity customer ID to the list of allowed domains. This maintains the security posture for all other projects while creating a specific exception for the partner.

A. Setting the policy to "Allow All" completely negates the security benefit of restricting domains and goes against the principle of least privilege.
B. Turning off the policy removes a critical, organization-wide security control, which is not a recommended best practice for making a single exception.
C. The domain restriction policy uses Google Workspace or Cloud Identity customer IDs for exceptions, not Google Groups. This option describes an incorrect mechanism.

1. Google Cloud Documentation, Organization Policy Constraints, "Restricting identities by domain". This page details the iam.allowedPolicyMemberDomains constraint and explicitly states: "To set exceptions, get the Cloud Identity or Google Workspace customer ID for the organization that you want to add."

2. Google Cloud Documentation, "Allowing specific external domains". This section within the "Restricting identities by domain" guide provides a step-by-step tutorial, showing the process of finding a customer ID and adding it to a custom organization policy.

The requirement is to analyze compensation data for outliers while ensuring the data is not exposed but remains reversible. Format-Preserving Encryption (FPE), implemented via CryptoReplaceFfxFpeConfig, meets these needs. FPE replaces sensitive data with a surrogate token that maintains the original data format (e.g., a number remains a number). This process is deterministic, meaning the same input always produces the same token, which allows for tracking and analysis. Crucially, it is a cryptographic method that is reversible with the appropriate key, allowing authorized users to identify the original data for the outlier.

A. Generalization reduces data granularity (e.g., bucketing ages) and is not reversible, preventing the identification of specific individuals.
B. Redaction completely removes the data, making any form of analysis or reversal impossible.
C. CryptoHashConfig uses a one-way hashing function. While it provides a token, it is not reversible, which is a key requirement.

1. Google Cloud Documentation

"De-identification of sensitive data". In the "Tokenization" section

it states: "Unlike with hashing

tokenization is reversible... Format-preserving encryption (FPE)... is one way to produce tokens."

2. Google Cloud Documentation

"Transformations reference"

CryptoReplaceFfxFpeConfig. The documentation describes this as a method for format-preserving encryption

which "encrypts the input data and returns a base64-encoded encryption of the data." This encryption is reversible.

3. Google Cloud Documentation

"Balancing utility and privacy in data de-identification". This document discusses various techniques. For FPE

it notes its ability to "maintain referential integrity" (critical for analysis) and that it is "reversible through re-identification with the original cryptographic key."

The requirements are to anonymize data in a non-reversible way and to not preserve the character set and length. Cloud Data Loss Prevention (DLP) with cryptographic hashing is the ideal solution. Hashing is a one-way cryptographic function; the original data cannot be recovered from the hash value, satisfying the "not reversible" requirement. A cryptographic hash (e.g., SHA-256) produces a fixed-length hexadecimal string, which does not preserve the character set or length of the original PHI data. This method effectively de-identifies the data while meeting all specified constraints.

A. Deterministic encryption is reversible with the key, which violates the requirement for a non-reversible transformation.
B. Format-preserving encryption is reversible and is explicitly designed to preserve the length and character set, violating two requirements.
D. Cloud KMS wrapped keys are used to manage encryption keys. The underlying transformation is still encryption, which is reversible.

1. Google Cloud Documentation

"De-identification of sensitive data in text". "De-identification is the process of removing identifying information from data. Cloud Data Loss Prevention supports several de-identification methods... including... cryptographic hashing."

2. Google Cloud Documentation

"Pseudonymization"

"Cryptographic hashing". "Cloud DLP can replace a value with its hash by using a secure

one-way cryptographic hash (SHA-256). The hashed value can't be reversed

and the original value can't be re-identified."

3. Google Cloud Documentation

"Transformations reference"

CryptoHashConfig. This section details how Cloud DLP uses cryptographic hashing for de-identification

confirming it is a one-way process.

Customer-managed encryption keys (CMEK) allow the customer to control and manage the keys used to protect their data in Google Cloud services, including Compute Engine persistent disks. By using Cloud KMS, the customer can create, rotate, and destroy the keys, fulfilling the management requirement. CMEK is fully integrated with Managed Instance Groups (MIGs), supporting the use of auto-scaling for bursty workloads without the operational complexity or limitations of other methods. This solution provides the required key management capabilities while leveraging the native, high-performance features of Google Cloud.

A. Customer-supplied encryption keys (CSEK) are not supported for Managed Instance Groups (MIGs), making this option technically infeasible for the described architecture.
C. Encryption by default uses Google-managed keys. This does not meet the customer's requirement to be able to manage and rotate the encryption keys themselves.
D. Pre-encrypting files is a form of client-side encryption. It does not address the requirement to encrypt the entire boot disk, which is a block-level encryption task.

1. Google Cloud Documentation, "Customer-managed encryption keys (CMEK)". "With CMEK, you can use keys that you manage in Cloud Key Management Service to protect data at rest in Google Cloud services." and "CMEK is available for... Compute Engine".

2. Google Cloud Documentation, "Customer-supplied encryption keys (CSEK)". Under the "Restrictions" section, it explicitly states: "You can't use customer-supplied encryption keys with... Managed instance groups."

3. Google Cloud Documentation, "About Google Cloud encryption at rest". "By default, Google Cloud encrypts all data at rest... without any action required from you." This highlights that the customer does not manage these keys.