Designing for security and compliance
Designing for security and compliance
This domain tests designing least-privilege access, protecting data, securing networks, and meeting compliance requirements on GCP. Expect scenarios about IAM, encryption, service perimeters, and auditability.
Core rules
- IAM: grant predefined or custom roles to groups, not individuals; use service accounts with least privilege; prefer Workload Identity for GKE over keys; avoid service account keys (use short-lived credentials).
- Resource hierarchy: Org Policy enforces constraints (e.g., disable key creation, restrict external IPs, limit locations); IAM inherits down; use folders to delegate administration.
- Data protection: encryption at rest is default; CMEK via Cloud KMS; CSEK for Cloud Storage; DLP API to discover and redact sensitive data; VPC Service Controls to create service perimeters and prevent exfiltration.
- Network security: VPC firewall rules (ingress/egress); hierarchical firewall policies; Cloud Armor for DDoS/WAF; Private Google Access; Identity-Aware Proxy for zero-trust app access.
- Compliance: Assured Workloads for regulated data (HIPAA, FedRAMP, etc.); Cloud Audit Logs (Admin Activity, Data Access); Access Transparency; Security Command Center for posture management.
Worked example
A healthcare company must store PHI under HIPAA. Reason: create an Assured Workloads folder with HIPAA controls; use CMEK via Cloud KMS for BigQuery and Cloud Storage; place the project in a VPC Service Controls perimeter; restrict IAM to groups; enable Data Access audit logs; run DLP scans to de-identify. This provides defense in depth and compliance evidence.
Traps
Using primitive roles (Owner/Editor) broadly; creating service account keys; forgetting VPC Service Controls for sensitive data; assuming default encryption satisfies CMEK; not enabling Data Access logs; ignoring Org Policy inheritance; over-granting to service accounts.