Skip to content
Cloud Architect Interview Guide

Zero Trust & Compliance

Where This Fits

Section titled “Where This Fits”

Security spans every account in the enterprise architecture. The Security Tooling Account (AWS) or Security Project (GCP) aggregates findings from all workload accounts. SCPs and org policies are enforced at the Organization level. KMS keys may be centralized or per-account depending on data residency requirements.

AWS Organization — Security OU overview

Zero Trust Principles

Section titled “Zero Trust Principles”

Defense in Depth — Six Security Layers

Zero Trust is not a product you buy — it is an architecture philosophy. Every request is authenticated, authorized, and encrypted regardless of network location.

Core Tenets

Section titled “Core Tenets”
PrincipleWhat It MeansImplementation
Never trust, always verifyNo implicit trust based on network locationIdentity-aware proxies, mTLS, token-based auth
Least privilegeMinimum permissions for the task at handSCPs, IAM Conditions, short-lived credentials
Assume breachDesign as if an attacker is already insideMicrosegmentation, lateral movement prevention, DLQ monitoring
Verify explicitlyAuthenticate and authorize every requestOIDC/SAML federation, device posture checks, context-aware access
Encrypt everythingData protected at rest, in transit, and in useCMEK, TLS 1.2+, mTLS, Confidential Computing

BeyondCorp Model (Google’s Zero Trust Implementation)

Section titled “BeyondCorp Model (Google’s Zero Trust Implementation)”

Google published BeyondCorp in 2014 after realizing VPNs create a false perimeter. The model shifts access controls from the network perimeter to individual devices and users.

BeyondCorp vs Traditional VPN Model

Defense-in-Depth Layers

Section titled “Defense-in-Depth Layers”

Defense-in-Depth — Five Security Layers

Encryption Strategy

Section titled “Encryption Strategy”

Encryption at Rest — AWS KMS

Section titled “Encryption at Rest — AWS KMS”

AWS KMS Key Hierarchy:

AWS KMS Key Hierarchy

Envelope Encryption (How KMS Actually Works):

Envelope Encryption — How KMS Actually Works

Services That Must Use CMEK (AWS):

ServiceConfiguration
S3Bucket default encryption with CMK, deny PutObject without SSE-KMS
EBSDefault EBS encryption with CMK per region
RDS / Aurorastorage_encrypted = true with CMK
Secrets ManagerAutomatic, uses CMK for secret value encryption
EKS etcdencryption_config block with CMK ARN
SQSkms_master_key_id on queue
DynamoDBTable-level CMK encryption

Encryption at Rest — GCP Cloud KMS

Section titled “Encryption at Rest — GCP Cloud KMS”

Cloud KMS Key Hierarchy:

GCP Cloud KMS Key Hierarchy

Services That Must Use CMEK (GCP):

ServiceConfiguration
GCSDefault bucket encryption with Cloud KMS key
Persistent Diskdisk_encryption_key referencing KMS key
Cloud SQLencryption_key_name at instance creation (immutable)
BigQueryDataset-level or table-level CMEK
GKE etcddatabase_encryption block with KMS key
Secret ManagerAutomatic CMEK per secret with replication.user_managed
Pub/SubTopic-level CMEK
resource "aws_kms_key" "data_encryption" {
  description             = "CMEK for workload data encryption"
  deletion_window_in_days = 30
  enable_key_rotation     = true  # Automatic annual rotation


  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "KeyAdminAccess"
        Effect = "Allow"
        Principal = {
          AWS = "arn:aws:iam::${var.security_account_id}:root"
        }
        Action   = "kms:*"
        Resource = "*"
      },
      {
        Sid    = "WorkloadAccountEncryptDecrypt"
        Effect = "Allow"
        Principal = {
          AWS = [
            "arn:aws:iam::${var.workload_account_a}:root",
            "arn:aws:iam::${var.workload_account_b}:root"
          ]
        }
        Action = [
          "kms:Encrypt",
          "kms:Decrypt",
          "kms:ReEncrypt*",
          "kms:GenerateDataKey*",
          "kms:DescribeKey"
        ]
        Resource = "*"
      }
    ]
  })
}


resource "aws_kms_alias" "data_encryption" {
  name          = "alias/enterprise-data-key"
  target_key_id = aws_kms_key.data_encryption.id
}

Encryption in Transit

Section titled “Encryption in Transit”

Every connection in the enterprise architecture must be encrypted with TLS 1.2+ minimum.

Encryption in Transit — Where TLS Applies

Enforcing TLS — SCP to Deny Unencrypted Transport (AWS):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnencryptedS3Transport",
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": "*",
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}

Encryption in Use — Confidential Computing

Section titled “Encryption in Use — Confidential Computing”

For the most sensitive data (PII processing, financial calculations), encrypt data even while it is being processed in memory.

AWS Nitro Enclaves:

  • Isolated compute environment within an EC2 instance
  • No persistent storage, no network access, no interactive access
  • Data decrypted only inside the enclave
  • Use case: processing credit card numbers, PII tokenization

GCP Confidential VMs:

  • AMD SEV-SNP or Intel TDX hardware-based memory encryption
  • Memory encrypted with per-VM key that even Google cannot access
  • Works with GKE (Confidential GKE Nodes) and Dataproc
  • Use case: regulated data processing, multi-tenant isolation
resource "google_compute_instance" "confidential" {
  name         = "confidential-processing"
  machine_type = "n2d-standard-4"  # AMD SEV required


  confidential_instance_config {
    enable_confidential_compute = true
  }


  boot_disk {
    initialize_params {
      image = "ubuntu-os-cloud/ubuntu-2204-lts"
    }
  }
}

Security Services — Centralized Detection and Response

Section titled “Security Services — Centralized Detection and Response”

AWS Security Hub

Section titled “AWS Security Hub”

Central pane of glass for security findings across all accounts.

AWS Security Hub — centralized security findings

GuardDuty — Threat Detection

Section titled “GuardDuty — Threat Detection”

Monitors VPC Flow Logs, CloudTrail, DNS logs, EKS audit logs, S3 data events, and Lambda network activity for threats.

Inspector — Vulnerability Scanning

Section titled “Inspector — Vulnerability Scanning”

Scans EC2 instances, ECR container images, and Lambda functions for software vulnerabilities (CVEs) and network exposure.

Inspector Scanning Flow:
ECR image pushed → Inspector auto-scans → finding in Security Hub
EC2 instance launched → SSM agent reports packages → Inspector scores CVEs
Lambda deployed → Inspector scans dependencies → alerts on critical CVEs

Security Command Center (SCC) Premium

Section titled “Security Command Center (SCC) Premium”

Central security dashboard for all GCP projects in the organization.

GCP Security Command Center Premium

VPC Service Controls

Section titled “VPC Service Controls”

Creates a security perimeter around GCP resources. Even if IAM is compromised, data cannot leave the perimeter.

VPC Service Controls — Data Exfiltration Prevention

BeyondCorp Enterprise

Section titled “BeyondCorp Enterprise”

Google’s managed Zero Trust platform. Provides context-aware access to applications without a VPN.

BeyondCorp Enterprise Components

# In Security Tooling Account (delegated admin)
resource "aws_securityhub_organization_admin_account" "main" {
  admin_account_id = var.security_tooling_account_id
}


resource "aws_securityhub_organization_configuration" "main" {
  auto_enable           = true
  auto_enable_standards = "DEFAULT"
}


resource "aws_securityhub_standards_subscription" "cis" {
  standards_arn = "arn:aws:securityhub:::ruleset/cis-aws-foundations-benchmark/v/1.4.0"
}


resource "aws_securityhub_standards_subscription" "pci" {
  standards_arn = "arn:aws:securityhub:::standards/pci-dss/v/3.2.1"
}
# Org-wide GuardDuty (Security Tooling Account)
resource "aws_guardduty_organization_admin_account" "main" {
  admin_account_id = var.security_tooling_account_id
}


resource "aws_guardduty_organization_configuration" "main" {
  detector_id = aws_guardduty_detector.main.id
  auto_enable_organization_members = "ALL"


  datasources {
    s3_logs {
      auto_enable = true
    }
    kubernetes {
      audit_logs {
        enable = true
      }
    }
    malware_protection {
      scan_ec2_instance_with_findings {
        ebs_volumes {
          auto_enable = true
        }
      }
    }
  }
}

UAE Compliance Frameworks

Section titled “UAE Compliance Frameworks”

Framework Comparison

Section titled “Framework Comparison”
FrameworkScopeKey RequirementsCloud Relevance
NESA (National Electronic Security Authority)UAE critical infrastructure — banking, energy, telecom, governmentRisk assessment, incident response, access control, encryption, business continuityData residency in UAE, encryption at rest/transit, logging and monitoring, incident notification
PDPL (Personal Data Protection Law — Federal Decree-Law No. 45/2021)All organizations processing personal data of UAE residentsConsent, data minimization, right to access/delete, cross-border transfer restrictions, DPO appointmentData classification, PII encryption, access controls, audit logging, cross-border transfer mechanisms
PCI-DSS v4.0Any organization handling payment card dataNetwork segmentation, encryption, access control, vulnerability management, monitoring, testingCardholder data environment (CDE) isolation, tokenization, WAF, quarterly scans, penetration testing
SOC2 Type IIService organizations (SaaS, cloud providers)Security, availability, processing integrity, confidentiality, privacy (Trust Services Criteria)Continuous monitoring, incident response, change management, access reviews

Mapping Controls to Cloud Services

Section titled “Mapping Controls to Cloud Services”

Compliance Controls — AWS and GCP Implementation Map

Enforcing Data Residency (UAE Region)

Section titled “Enforcing Data Residency (UAE Region)”
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonUAERegions",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "me-south-1",
            "me-central-1"
          ]
        },
        "ArnNotLike": {
          "aws:PrincipalARN": "arn:aws:iam::*:role/OrganizationAdmin"
        }
      }
    }
  ]
}

Compliance Automation Architecture

Section titled “Compliance Automation Architecture”

Compliance Automation Pipeline

Terraform — AWS Config Conformance Pack (PCI-DSS):

resource "aws_config_conformance_pack" "pci_dss" {
  name = "pci-dss-conformance-pack"


  template_body = <<-EOT
    Resources:
      S3BucketEncryption:
        Type: AWS::Config::ConfigRule
        Properties:
          ConfigRuleName: s3-bucket-server-side-encryption-enabled
          Source:
            Owner: AWS
            SourceIdentifier: S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED
      RDSEncryption:
        Type: AWS::Config::ConfigRule
        Properties:
          ConfigRuleName: rds-storage-encrypted
          Source:
            Owner: AWS
            SourceIdentifier: RDS_STORAGE_ENCRYPTED
      VPCFlowLogsEnabled:
        Type: AWS::Config::ConfigRule
        Properties:
          ConfigRuleName: vpc-flow-logs-enabled
          Source:
            Owner: AWS
            SourceIdentifier: VPC_FLOW_LOGS_ENABLED
      CloudTrailEncryption:
        Type: AWS::Config::ConfigRule
        Properties:
          ConfigRuleName: cloud-trail-encryption-enabled
          Source:
            Owner: AWS
            SourceIdentifier: CLOUD_TRAIL_ENCRYPTION_ENABLED
  EOT
}

Compliance Frameworks — Architecture Implications

Section titled “Compliance Frameworks — Architecture Implications”

Architects do not need to memorize every compliance control number — auditors and compliance teams handle that. What architects must know is how compliance requirements translate into architecture decisions. When a compliance officer says “we need PCI-DSS for payment processing,” the architect must immediately think: network segmentation, encryption boundaries, logging retention, and vulnerability management pipelines. This section maps the major frameworks to concrete architecture patterns.

PCI-DSS (Payment Card Industry Data Security Standard)

Section titled “PCI-DSS (Payment Card Industry Data Security Standard)”

PCI-DSS governs any system that stores, processes, or transmits payment card data. The critical architecture concept is the Cardholder Data Environment (CDE) — the set of systems in scope for PCI compliance. The smaller your CDE, the less you need to secure and audit.

Network Segmentation — CDE Isolation:

The CDE must be isolated from all non-CDE systems. This is not just a security group — it is a completely separate network boundary with controlled access points.

PCI-DSS CDE Network Isolation

Key architecture decisions for PCI-DSS:

  • Dedicated VPC for CDE: The CDE gets its own VPC with no internet egress (no NAT Gateway, no IGW). All outbound calls go through PrivateLink to specific AWS services or through an inspection VPC with Network Firewall.
  • PrivateLink for API access: Non-CDE systems call the payment API via PrivateLink — not VPC peering. VPC peering exposes the entire network; PrivateLink exposes a single service endpoint. This minimizes the blast radius.
  • NACLs + Security Groups + Network Firewall: Defense in depth at the network layer. NACLs provide stateless subnet-level filtering, Security Groups provide stateful instance-level filtering, and Network Firewall provides deep packet inspection between CDE and non-CDE.
  • Tokenization: The non-CDE frontend never sees raw card numbers. The payment processing service tokenizes card data immediately and returns a token. This keeps the frontend out of PCI scope entirely.

Encryption requirements:

  • In transit: TLS 1.2+ minimum for all connections. mTLS between microservices within the CDE via Istio STRICT mode.
  • At rest: AES-256 encryption using CMEK (KMS). For key generation and storage of the most sensitive keys, use CloudHSM (FIPS 140-2 Level 3 certified hardware). CloudHSM ensures that key material never exists in plaintext outside the HSM.
  • Key management: Keys for CDE data must be separate from non-CDE keys. Dedicate a KMS key ring/alias specifically for CDE workloads with restricted key policy.

Logging requirements:

  • Retention: PCI-DSS requires audit logs retained for at least 1 year, with 3 months immediately available for analysis.
  • Implementation: CloudTrail logs → S3 in the Log Archive account with S3 Object Lock (WORM — Write Once Read Many) to make logs tamper-proof. Glacier transition after 90 days for cost optimization while maintaining the 1-year retention.
  • Scope: ALL access to cardholder data must be logged — database queries, API calls, administrative access. CloudTrail covers API calls; database audit logs (RDS audit log, pgaudit) cover data access.

Vulnerability management:

  • Container scanning: Trivy or Inspector scanning in the CI pipeline. Images with CRITICAL or HIGH CVEs are blocked from deployment via OPA/Gatekeeper admission control.
  • Patch cadence: PCI-DSS requires critical patches within 30 days. Automate with Systems Manager Patch Manager or GKE node auto-upgrade.
  • Penetration testing: Required annually (internal and external). Use AWS’s pre-approved pentest policy or coordinate with GCP support.

AWS compliance automation:

  • Security Hub PCI-DSS standard: Automated checks against PCI-DSS controls across all accounts. Provides a compliance score and identifies failing resources.
  • Config Rules: Continuous compliance evaluation. Rules like s3-bucket-server-side-encryption-enabled, rds-storage-encrypted, vpc-flow-logs-enabled map directly to PCI-DSS requirements.
  • Config Conformance Packs: Deploy a full PCI-DSS conformance pack that bundles 30+ Config Rules. See the Compliance Automation Architecture section above for Terraform examples.

GCP compliance automation:

  • SCC Premium with PCI compliance module: Security Command Center Premium includes a PCI-DSS compliance report that maps findings to specific PCI requirements.
  • Assured Workloads: For data residency and sovereignty requirements (common in UAE PCI implementations), Assured Workloads restricts resource creation to approved regions and applies additional compliance controls.

ISO 27001 / SOC 2 Type II

Section titled “ISO 27001 / SOC 2 Type II”

ISO 27001 and SOC 2 Type II are broader frameworks covering organizational security controls. Unlike PCI-DSS (which is prescriptive), these frameworks are risk-based — the architect designs controls appropriate to the risk level.

Change management — Infrastructure as Code:

  • ALL infrastructure changes must go through IaC (Terraform). No ClickOps. This provides an audit trail in Git — every change has a PR, a reviewer, a timestamp, and a reason.
  • CI/CD pipelines enforce terraform plan review before terraform apply. The plan output is posted as a PR comment for human review.
  • Drift detection: AWS Config or Terraform Cloud detects configuration drift and alerts. Manual changes are flagged and must be reconciled with IaC.

Access control — Identity and MFA:

  • SSO: All human access via IAM Identity Center (AWS) or Cloud Identity (GCP). No local IAM users in any account.
  • MFA: Enforced on all accounts — no exceptions. Hardware security keys (FIDO2) for privileged users.
  • Break-glass: Time-limited elevated access for emergencies. The break-glass role auto-revokes after a configurable period (e.g., 4 hours). All break-glass usage triggers immediate alerts and requires a post-incident justification.
  • Quarterly access reviews: Export IAM Access Analyzer findings, review unused permissions, right-size roles.

Asset inventory:

  • AWS Config: Continuous recording of all resources across all accounts. Provides a timeline of resource changes — auditors can query “what was the state of this S3 bucket on March 15?”
  • GCP Cloud Asset Inventory: Organization-wide inventory with history. Exportable to BigQuery for analysis and reporting.
  • Regular inventory reports: Automated weekly reports of all resources, tagged by business unit, environment, and data classification.

Incident response:

  • Documented runbooks for each incident type (data breach, unauthorized access, service outage)
  • Severity levels: SEV-1 (critical, immediate response) through SEV-4 (low, next business day)
  • Blameless postmortem process for SEV-1 and SEV-2 incidents
  • Evidence collection automation: Lambda/Cloud Function triggers on GuardDuty/SCC findings to snapshot instances, capture memory, and preserve logs

Business continuity:

  • DR plan with tested RTO (Recovery Time Objective) and RPO (Recovery Point Objective) for each tier of service
  • Regular DR drills: at least annually, simulate regional failure and verify failover
  • Multi-AZ deployments by default for all production workloads
  • Cross-region backups for critical data (Aurora Global DB, GCS dual-region buckets)

AWS CIS Benchmarks (Center for Internet Security)

Section titled “AWS CIS Benchmarks (Center for Internet Security)”

CIS Benchmarks are prescriptive hardening standards. Level 1 controls are essential (every account should have them). Level 2 controls are advanced (apply to sensitive workloads). Here are the key controls that architects should implement from day one:

Key controls (every account, no exceptions):

ControlWhy It MattersImplementation
No root account access keysRoot has unlimited permissions, keys cannot be restrictedDelete root access keys, use IAM roles instead
MFA on root accountRoot account compromise = total account takeoverHardware MFA token stored in a safe
CloudTrail in ALL regionsAttackers create resources in unused regions to avoid detectionEnable CloudTrail organization trail, all regions
VPC Flow Logs on all VPCsNetwork traffic visibility for forensics and anomaly detectionFlow logs → CloudWatch Logs or S3
S3 Block Public Access at account levelPrevents accidental public bucket exposureAccount-level setting, enforced by SCP
Default EBS encryptionEnsures new volumes are encrypted without developer actionAccount-level setting per region
No 0.0.0.0/0 on SSH (port 22)Open SSH is the most common attack vectorSecurity Hub auto-detects, Config rule alerts

Implementation approach:

  • AWS Security Hub CIS AWS Foundations Benchmark: Enable this standard in Security Hub. It automatically evaluates all accounts against CIS controls and provides a compliance score with specific remediation guidance for each failing control.
  • Config Conformance Packs: Deploy CIS benchmark controls as a conformance pack across all accounts via AWS Organizations. This provides continuous evaluation — not just a point-in-time check.
  • SCP enforcement: For critical controls (like Block Public Access), do not rely on detection alone. Use SCPs to prevent non-compliant actions at the API level. An SCP that denies s3:PutBucketPublicAccessBlock with BlockPublicAccess=false prevents anyone from disabling the protection.

GCP equivalent:

  • CIS Google Cloud Platform Foundation Benchmark: Applied via SCC compliance reports. Covers IAM, logging, networking, storage, and database hardening.
  • Organization Policies: The GCP equivalent of SCPs. Policies like constraints/compute.requireShieldedVm, constraints/iam.disableServiceAccountKeyCreation, and constraints/storage.uniformBucketLevelAccess enforce CIS controls at the organization level. See the terraform-patterns cheatsheet for org policy Terraform examples.

Interview Scenarios for Compliance

Section titled “Interview Scenarios for Compliance”

Interview: “How do you prove PCI-DSS compliance for a payment processing workload on AWS?”

Strong Answer:

“PCI-DSS compliance on AWS is a combination of preventive controls, detective controls, and evidence collection.

Preventive: The CDE runs in an isolated VPC with no internet access. SCPs deny creation of unencrypted resources. Network Firewall inspects all traffic entering and leaving the CDE VPC. OPA/Gatekeeper policies deny pods without security contexts or with excessive privileges.

Detective: Security Hub PCI-DSS standard continuously evaluates all CDE resources against PCI controls. Config Rules flag any configuration drift — unencrypted volumes, missing flow logs, overly permissive security groups. Inspector scans container images and EC2 instances for vulnerabilities.

Evidence: CloudTrail logs with Object Lock provide tamper-proof audit trails. Config snapshots provide point-in-time resource state. Security Hub findings are exported to S3 as compliance evidence packages. All evidence is retained for 1 year per PCI requirements.

Ongoing: This is not a one-time audit. Config Rules run continuously. Security Hub scores update in real-time. EventBridge triggers auto-remediation Lambda functions for critical findings. The compliance team gets a weekly automated report.”

Interview: “Walk through your approach to achieving SOC 2 Type II certification on AWS/GCP”

Strong Answer:

“SOC 2 Type II requires demonstrating that controls are effective over a period of time (typically 6-12 months), not just at a point in time. My approach covers the five Trust Services Criteria:

Security: All access via SSO with MFA. SCPs and org policies enforce guardrails. GuardDuty/SCC detects threats. Network segmentation via VPC architecture.

Availability: Multi-AZ deployments for all production services. Tested DR plan with defined RTO/RPO. Auto-scaling for variable load. Uptime SLAs defined and monitored.

Processing Integrity: IaC for all changes (Git audit trail). CI/CD pipelines with automated testing. Change approval workflows. Drift detection and remediation.

Confidentiality: CMEK encryption at rest. mTLS in transit. VPC Service Controls / PrivateLink for data boundaries. Macie/DLP scanning for sensitive data exposure.

Privacy: Data classification tags on all resources. Access controls based on data sensitivity. Audit logging of all data access. Data retention policies enforced via lifecycle rules.

The key is automation — auditors want to see that controls run continuously, not manually. AWS Config, Security Hub, and CloudTrail provide the evidence. The audit period is just a window into your always-on compliance posture.”

Interview Scenarios

Section titled “Interview Scenarios”

Scenario 1: “Design the Encryption Strategy for a Regulated Enterprise”

Section titled “Scenario 1: “Design the Encryption Strategy for a Regulated Enterprise””

Context: You are building the cloud foundation for a bank. All data must be encrypted at rest and in transit. How do you design the encryption strategy?

Strong Answer:

“I would implement encryption at three layers — at rest, in transit, and selectively in use.

At rest: Every service uses CMEK via AWS KMS or Cloud KMS. We create key rings in the Security account/project, with cross-account grants to workload accounts. Key rotation is enabled — annual for AWS, 90-day for GCP. We enforce this with SCPs that deny PutObject without aws:kms encryption, and org policies that require CMEK on GCP. Services covered: S3/GCS, EBS/PD, RDS/Cloud SQL, EKS/GKE etcd, Secrets Manager, SQS/Pub/Sub, DynamoDB/BigQuery.

In transit: TLS 1.2+ everywhere. ALB terminates external TLS, re-encrypts to backend pods. Between microservices, Istio enforces mTLS in STRICT mode — no plaintext traffic is possible within the mesh. Database connections require ssl_mode=verify-full. S3 bucket policies deny aws:SecureTransport=false. For hybrid connectivity, Direct Connect uses MACsec encryption.

In use: For the most sensitive workloads like PII processing or tokenization, we use Confidential Computing — Nitro Enclaves on AWS or Confidential VMs on GCP. Data is encrypted even in memory.

Key management governance: Security team owns key policies, workload teams get encrypt/decrypt only, all key usage is logged to CloudTrail/Cloud Audit Logs, and key deletion requires a 30-day waiting period with alerts.”

Scenario 2: “How Do You Prevent Data Exfiltration from Cloud?”

Section titled “Scenario 2: “How Do You Prevent Data Exfiltration from Cloud?””

Strong Answer:

“Data exfiltration prevention is a layered defense:

Network layer: All egress traffic routes through the Network Hub Account’s inspection VPC. AWS Network Firewall with IPS rules inspects outbound traffic. No workload VPC has a direct internet gateway. On GCP, VPC Service Controls create a perimeter — even with valid IAM credentials, data cannot be copied to a project outside the perimeter.

Identity layer: SCPs deny s3:PutObject to any bucket outside our Organization. No IAM user has long-lived access keys — everything uses short-lived credentials via SSO or IRSA/Workload Identity.

Data layer: S3 bucket policies restrict cross-account access. Macie scans for sensitive data in unexpected locations. DLP scanning on GCP identifies PII in BigQuery and GCS. All buckets have BlockPublicAccess enabled at the account level, enforced by SCP.

Application layer: ECR/Artifact Registry with vulnerability scanning. No latest tags allowed — immutable digests only. Container images can only be pulled from approved registries (enforced via OPA/Gatekeeper).

Monitoring: GuardDuty detects anomalous data access patterns. CloudTrail logs every API call. Security Hub aggregates findings. Automated alerts on any S3 GetObject exceeding baseline volume.”

Scenario 3: “Design Zero Trust for a Company Moving Away from VPN”

Section titled “Scenario 3: “Design Zero Trust for a Company Moving Away from VPN””

Strong Answer:

“The migration from VPN to Zero Trust is a phased approach:

Phase 1 — Identity Foundation: Deploy IAM Identity Center (AWS) or BeyondCorp Enterprise (GCP). Enforce MFA for all users. Integrate with corporate IdP (Okta, Azure AD) via SAML/OIDC. Define access levels based on user role, device posture, and network context.

Phase 2 — Application-Level Access: Deploy Identity-Aware Proxy (GCP IAP) or AWS Verified Access in front of internal applications. Each application gets context-aware access policies — users must be on a managed device with disk encryption enabled, running a supported OS version, from an approved IP range. No network-level VPN needed.

Phase 3 — Network Microsegmentation: Even if someone gets in, limit lateral movement. Service mesh (Istio) enforces mTLS and AuthorizationPolicy between microservices. Network policies in Kubernetes deny all traffic by default, allow only declared dependencies. VPC security groups follow least privilege.

Phase 4 — Continuous Verification: Session re-evaluation every 15 minutes. Device posture changes (disk encryption disabled, OS unpatched) trigger access revocation. All access logged and auditable.”

Scenario 4: “Walk Through IAM Governance for 100+ AWS Accounts”

Section titled “Scenario 4: “Walk Through IAM Governance for 100+ AWS Accounts””

Strong Answer:

“IAM governance at scale requires a structured hierarchy:

Identity: AWS IAM Identity Center (formerly SSO) connected to our corporate IdP (Okta). No IAM users in any account — all access is federated. Permission sets map to job functions: ReadOnly, Developer, AdminAccess, BreakGlass.

Authorization: SCPs at each OU level form guardrails. Root OU SCP denies region usage outside approved regions, denies leaving the Organization, denies disabling CloudTrail/GuardDuty/Config. Production OU SCP denies IAM user creation, denies * actions. Dev OU SCP is relaxed but still prevents critical actions.

Access Reviews: IAM Access Analyzer runs continuously across all accounts, flagging any external access (cross-account roles, public S3). Quarterly access reviews: pull CloudTrail data to identify unused permissions, right-size permission sets.

Break-Glass: A dedicated BreakGlass role in every account with full admin permissions. Requires MFA + approval workflow. Usage triggers immediate PagerDuty alert. CloudTrail events for this role are monitored in real-time.

Service-to-service: No long-lived credentials. Lambda uses execution roles, EKS uses IRSA, CI/CD uses OIDC federation with short-lived tokens.”

Scenario 5: “Design Compliance Automation for PCI-DSS”

Section titled “Scenario 5: “Design Compliance Automation for PCI-DSS””

Strong Answer:

“PCI-DSS compliance on AWS/GCP requires mapping each control to a detective and preventive mechanism:

Preventive controls (block non-compliance):

  • SCPs deny creation of unencrypted resources
  • OPA/Gatekeeper deny pods without security contexts
  • Network Firewall blocks traffic to unapproved external endpoints
  • IAM policies enforce least privilege with permission boundaries

Detective controls (alert on non-compliance):

  • AWS Config rules mapped to PCI-DSS requirements (the conformance pack has 30+ rules covering network segmentation, encryption, access control, logging)
  • Security Hub PCI-DSS standard provides a compliance score
  • Inspector scans for CVEs on EC2, ECR, and Lambda
  • Macie scans for unencrypted cardholder data

Evidence collection (prove compliance to auditors):

  • AWS Config snapshots stored in S3 in the Log Archive account
  • CloudTrail logs with integrity validation
  • Security Hub findings exported to S3 for quarterly evidence packages
  • Automated compliance report generation via Lambda

Continuous monitoring:

  • Security Hub dashboard shows real-time compliance score
  • EventBridge triggers Lambda auto-remediation for critical findings
  • PagerDuty alerts for any PCI-DSS control failure
  • Quarterly penetration testing with third-party firm”

Scenario 6: “How Do You Ensure ALL Traffic Between Microservices Is Encrypted?”

Section titled “Scenario 6: “How Do You Ensure ALL Traffic Between Microservices Is Encrypted?””

Strong Answer:

“Three complementary layers:

Service Mesh (primary): Deploy Istio in STRICT mTLS mode across all EKS/GKE clusters. PeerAuthentication set to STRICT at the mesh level — no plaintext traffic is possible between pods in the mesh. Istio automatically provisions, rotates, and distributes X.509 certificates via istiod. Certificate rotation happens every 24 hours by default.

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT

Ingress TLS (external): cert-manager provisions TLS certificates for ingress. For AWS, we use ACM certificates on ALB. For GCP, Google-managed certificates on the Global Load Balancer. All external traffic terminates TLS at the load balancer and re-encrypts to the backend.

Database connections: All database connections require TLS. RDS parameter groups set rds.force_ssl=1. Cloud SQL instances set requireSsl=true. Application connection strings include sslmode=verify-full to validate the server certificate.

Verification: Network policies deny all traffic by default — only declared connections are allowed. We periodically run istioctl analyze and check Kiali for any non-mTLS connections. Security Hub alerts on any security group allowing plaintext protocols (HTTP on port 80 without redirect).”

References

Section titled “References”

AWS

Section titled “AWS”

GCP

Section titled “GCP”

Tools & Frameworks

Section titled “Tools & Frameworks”