Designing for Security and Compliance practice questions

Cloud Identity with SAML SSO

Cloud Identity with SAML SSO federates the existing Active Directory identity provider, letting users authenticate to the GCP Console with current credentials. This satisfies the constraint of reusing Active Directory without provisioning separate Google accounts.

Use a Cloud Armor security policy rule with a condition on the IP address and a time condition

Cloud Armor supports rule conditions that can check the request time, allowing time-based blocking.

Container Analysis API

Container Analysis API provides vulnerability scanning and metadata storage for container images, satisfying the requirement to scan images before deployment. It integrates with Artifact Registry and Binary Authorization, supplying the attestations that enforcement relies on. Scanning alone does not enforce approved images, so it must pair with a policy-enforcement service.

Binary Authorization

Binary Authorization enforces deploy-time admission control, permitting only images signed by trusted attestors to reach GKE. Combined with vulnerability scanning in Artifact Registry, it blocks unapproved or unscanned images, satisfying both the allowlist and pre-deployment scanning constraints.

Cloud Functions

Cloud Functions provides the serverless compute layer that consumes the rotated secrets at runtime, satisfying the integration requirement. It retrieves secret values from Secret Manager via the API or mounted volumes, so functions execute without embedding credentials in code or configuration.

Secret Manager

Secret Manager stores the secrets centrally and supports automatic rotation schedules, meeting the 30-day rotation constraint. Its native integration lets Cloud Functions retrieve secret values at runtime through the API or client libraries, so no credentials are hard-coded.

Rate limiting

Can mitigate DDoS attacks by limiting request rates.

WAF rules

WAF rules provide preconfigured signatures that inspect request payloads for SQL injection and XSS patterns, satisfying the application-layer attack constraint. Cloud Armor's OWASP ModSecurity rules detect these injection attempts before they reach the backend. Geographic blocking, however, requires separate security policies, so WAF rules alone address only the payload-inspection requirement.

Geographic restrictions

Geographic restrictions satisfy the requirement to block traffic from specific regions. Cloud Armor's geo-based rules match source IP addresses against Google's geolocation database, applying allow or deny actions at the edge before traffic reaches the backend. This directly addresses the stated regional blocking constraint, independent of the WAF rules handling SQL injection and XSS.

Create a key ring and a key in Cloud KMS

Cloud KMS key rings and keys provide the customer-managed encryption keys that Cloud Storage's CMEK setting references, satisfying the requirement for keys the company controls rather than Google-managed ones. Creating the key ring and key is the prerequisite step; rotation every 90 days is then configured on that key's rotation schedule.

Set the default encryption key on the Cloud Storage bucket to the Cloud KMS key

Setting the bucket's default encryption key to the Cloud KMS key ensures every object written is encrypted with that customer-managed key, satisfying the CMEK requirement. Key rotation every 90 days is then configured on the KMS key itself, not the bucket.

Configure the bucket with VPC Service Controls and enable Private Google Access

VPC Service Controls create a service perimeter, and Private Google Access allows access from VMs and on-premises via VPN.

IAM conditions

IAM conditions let you attach attribute-based predicates to role bindings, so permissions apply only when the resource carries the specified label. This satisfies the requirement to restrict VM creation and management to labelled VMs within one project, rather than granting unconditional project-wide compute access.

Add an annotation to the KSA referencing the GSA, and grant the KSA the iam.workloadIdentityUser role on the GSA

Workload Identity Federation for GKE binds the KSA to the GSA through the iam.gke.io/gcp-service-account annotation, while granting the KSA the iam.workloadIdentityUser role on the GSA authorises impersonation. This lets the pod obtain short-lived tokens, eliminating long-lived service account keys.

Use DLP de-identification templates to transform data and write to a target bucket

De-identification transforms the data, and the output can be written to another bucket.

Create a DLP inspection job to scan the source bucket

Inspection identifies PII in the source data.

Viewer

Viewer grants read-only access to all GCP project resources, including IAM policies and logs, satisfying the auditor's need to inspect sensitive configuration without modification rights. Unlike broader roles such as Editor, it excludes write permissions, and unlike narrower roles it covers every resource type across the project.

Add a firewall rule with source service account 'sa-prod@project.iam.gserviceaccount.com' and target service account 'cloud-sql-sa@project.iam.gserviceaccount.com'

Firewall rules can match traffic by source service account, so permitting only sa-prod@project.iam.gserviceaccount.com satisfies the stem's requirement to grant access without opening the subnet broadly. The target service account identifies the Cloud SQL instance, ensuring the rule applies solely to that instance rather than all resources in the VPC.

resource.name.startsWith('projects/_/locations/us-central1') && request.auth.principalSet == 'serviceAccount:bq-<project-number>@bigquery-encryption.iam.gserviceaccount.com'

The condition combines a resource.name prefix restricting key use to the us-central1 location with a principalSet matching the BigQuery encryption service account, satisfying the stem's requirement that only that account in that region may use the CMEK.

Create a firewall egress rule with destination IP range of the on-premises database and source service account of the application instances

Scoping the egress rule to the application's service account restricts initiation to those Compute Engine instances alone, rather than any workload sharing the VPC's IP range. Combined with the destination IP of the legacy database, this satisfies the requirement that only the migrated application can reach it.

Cloud KMS with a key backed by Cloud HSM, and set the bucket's default encryption to use that key (CMEK)

Cloud KMS with a Cloud HSM protection level keeps key material inside FIPS 140-2 Level 3 hardware, and configuring the bucket's default encryption with that CMEK ensures every object is wrapped by the customer-managed, quarterly-rotated key.

Create a rule with priority 100 to deny the IP range, and a rule with priority 1000 to allow all traffic

Cloud Armor evaluates rules by ascending priority, so the deny rule at 100 matches the specified IP range first and blocks it, while the allow rule at 1000 permits all remaining traffic. This satisfies the stem's requirement to block one range yet allow everything else, since lower numbers take precedence.

Grant the service account the 'roles/storage.objectViewer' role on the bucket

Granting roles/storage.objectViewer to the service account on the bucket satisfies the least-privilege requirement: only that identity can read objects. Compute Engine instances attached to the service account inherit its IAM permissions, so no broader project-level access is needed.

Configure VPC Service Controls to allow access only from the VPC where the instances reside

VPC Service Controls creates a service perimeter around the buckets, blocking access from outside the specified VPC even if IAM permits it. This satisfies the constraint that only instances within that VPC can reach the objects, adding network-context enforcement beyond IAM.

Enable Cloud Audit Logs for the Cloud KMS API

Enabling Cloud Audit Logs for the Cloud KMS API records every cryptographic operation, including key use, rotation and access attempts, satisfying the audit requirement. Admin Activity logs capture key configuration changes, while Data Access logs capture encrypt, decrypt and sign calls, giving the per-key traceability the scenario demands.

Create a key ring for each application

Separate key rings per application enforce isolation, since IAM policies and permissions can be scoped at the key ring level, so each application reaches only its own keys. This directly satisfies the requirement that different applications have access solely to their own keys, rather than sharing one ring across all applications.

Set a rotation period of 90 days on each key

Setting a 90-day rotation period on each key directly satisfies requirement 1, since Cloud KMS rotation schedules are configured per key and trigger automatic generation of new key versions without re-encrypting existing data. Rotation is a key-level property, so each application's key can carry its own schedule independently.