Cloud Security Architecture Questions

Designing security architecture for cloud platforms and services with an emphasis on defense in depth and secure system design. Candidates should be able to design network segmentation and isolation using virtual networks, subnets, security groups, and private endpoints, secure connectivity between on premises and cloud environments, and apply zero trust and microsegmentation principles. Coverage includes workload protection and runtime security for containers and serverless workloads, encryption and key management across data in transit and data at rest, infrastructure as code security and automated scanning, secure service configuration, integration of identity and access controls into architecture, logging and monitoring design for detection and response, threat modeling and secure design patterns, compliance and audit considerations, and trade offs when choosing managed services versus self managed deployments. Interview questions focus on architecture level decisions, justification of trade offs, threat modeling, and designing secure deployment pipelines and operational controls.

MediumTechnical

95 practiced

In Terraform HCL, describe (or write a short snippet) how you would ensure that an S3 bucket is created with Block Public Access enabled and an IAM policy denies public put/putBucketPolicy changes. Explain how you would enforce this check in CI (e.g., using pre-commit, tfsec, or policy-as-code).

Sample Answer

**Approach (brief)** Create the S3 resource with aws_s3_bucket_public_access_block set to block all public access, attach an IAM bucket policy denying PutObject and PutBucketPolicy when the principal is "*" (public). Enforce via pre-commit hooks and CI using tfsec / checkov or a policy-as-code rule (OPA/Rego or Sentinel) that fails the plan if public access or allow statements exist.

**HCL snippet**

hcl

resource "aws_s3_bucket" "example" {
  bucket = "my-secure-bucket"
  acl    = "private"
}

resource "aws_s3_bucket_public_access_block" "example" {
  bucket                  = aws_s3_bucket.example.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_policy" "deny_public_puts" {
  bucket = aws_s3_bucket.example.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid       = "DenyPublicPut"
        Effect    = "Deny"
        Principal = "*"
        Action    = [
          "s3:PutObject",
          "s3:PutObjectAcl",
          "s3:PutBucketPolicy"
        ]
        Resource = [
          "${aws_s3_bucket.example.arn}",
          "${aws_s3_bucket.example.arn}/*"
        ]
        Condition = {
          Bool = { "aws:PrincipalIsAWSAccount" = "false" }
        }
      }
    ]
  })
}

**Enforcement in CI / pre-commit**- Add pre-commit hooks: terraform fmt, terraform validate, tflint.- Run tfsec and checkov locally and in CI pipeline as blocking steps (exit non-zero on findings).- Policy-as-code: implement a Rego rule for OPA/Gatekeeper that checks plan JSON for any s3 bucket without public access block or contains public allow statements. Example CI step: - terraform init && terraform plan -out=tfplan - terraform show -json tfplan > plan.json - run opa eval --input plan.json --data s3_public_policy.rego deny_rulesFail pipeline if rule returns violations.

**Why this is robust** Public access block enforces S3 level protection; the deny policy prevents accidental public write/policy changes; running static checks + policy-as-code in CI prevents misconfigurations from merging or deploying.

MediumTechnical

89 practiced

Explain how Workload Identity (GKE) or IRSA (AWS) can be used to provide least-privilege temporary credentials to Kubernetes workloads. Compare that to using long-lived static credentials mounted as secrets and describe migration steps.

HardTechnical

121 practiced

Design an incident response plan and forensic collection procedure for a suspected compromise of cloud workloads spanning multiple accounts and regions. Include steps to isolate affected resources, preserve volatile evidence (memory, container images), collect audit logs and flow logs, and maintain chain of custody while minimizing service disruption.

Sample Answer

**Situation & goals**Design an incident response (IR) and forensic collection playbook for suspected compromise across multiple cloud accounts/regions that: (1) isolates affected resources, (2) preserves volatile evidence (memory, container images), (3) collects audit/flow logs, and (4) maintains chain-of-custody — while minimizing service disruption.

**High-level phases**1. Triage & scope2. Containment (isolate)3. Evidence preservation & collection4. Analysis (forensics)5. Remediation & recovery6. Reporting & lessons learned

**1. Triage & scope**- Activate IR runbook and stakeholders (security, cloud eng, legal).- Identify impacted accounts/regions via centralized telemetry (Cloud SIEM).- Create an incident timeline; capture suspected IOC list (IPs, instance IDs, container IDs, principals).

**2. Containment / isolate (minimize disruption)**- Apply least-impact isolation: use network ACLs or Security Group rules to block malicious egress/ingress for affected instances/subnets rather than stop VMs.- For orchestrated services, create a traffic mirror (AWS VPC Traffic Mirroring / Azure NSG Flow Logs + Tap) to capture live traffic while leaving services online.- For critical services, route traffic to a failover (blue/green) or scale down compromised nodes and replace with fresh instances built from clean images.- Quarantine compromised accounts via IAM/Organization SCP to block new credentials and disable programmatic access keys.

**3. Preserve volatile evidence**- Memory: - For VMs: take live memory capture where possible. Use cloud provider-approved methods (e.g., AWS SSM Run Command to invoke a lightweight memory dumper or, if available, provider memory-snapshot APIs). If hypervisor-level memory capture is unavailable, prioritize process dumps and kernel artifacts ( /proc, lsof, netstat ). - For containers: use CRIU or docker checkpoint to dump container memory/state; run `docker inspect`, `docker ps`, `docker top` and `docker save` to preserve images. If running on managed K8s (EKS/AKS/GKE), cordon node and run ephemeral pod with host access to export container filesystem and images.- Disk/FS: - Create read-only snapshots (EBS/Azure Managed Disk/GCP Persistent Disk) and attach copies to a forensic analysis account/instance.- Images & artifacts: - Export container images (docker save / podman save) and push copies to an isolated, write-once registry/storage.- Live process & ephemeral artifacts: - Run SSM/Run Command or agent to collect `ps`, `netstat -anp`, `ss`, `iptables -L`, open file handles, loaded modules, and process hashes.- Logging & flow data: - Immediately enable/ensure CloudTrail/Activity Logs are aggregated to central immutable storage (S3/GCS/Azure Blob with object lock). - Collect VPC Flow Logs, ALB/NLB logs, WAF logs, and container runtime logs (CRI, Docker). - Export Kubernetes audit logs and control-plane logs.

**4. Forensic collection procedure (detailed)**- Move artifacts to a dedicated forensics account and region to prevent accidental tampering.- For each artifact: - Generate a manifest with metadata: source, timestamp (UTC), collector identity, method, region, account, instance/container ID. - Compute cryptographic hashes (sha256) immediately and record. - Store artifacts in immutable storage (S3 with Object Lock & encryption, or Azure immutable blobs).- Memory capture example workflow (VM): - Run SSM to execute memory dumper -> save /tmp/memdump.bin -> compute sha256 -> copy to forensic S3 with encryption and object lock -> delete local temp.- Container capture example: - `docker commit` or `docker save` to a tar -> hash -> upload to isolated storage. - Export container filesystem via `tar` of mounted overlayfs or use `kubectl cp` for pods.- Logs: - Pull all relevant logs (CloudTrail, Flow Logs, CloudWatch Logs/Log Analytics, Stackdriver) for impacted time windows and forward to forensic store.

**5. Chain of custody**- Record chain-of-custody entries for every action: - Who collected, tool/command, timestamp, target artifact ID, hash before/after transfer, storage location.- Use signed manifests (PGP or provider KMS-signed metadata) and append-only audit trail (SIEM), stored in separate legal retention bucket.- Limit access: RBAC to forensics account, short-lived credentials via STS, and MFA enforced.- Preserve original artifacts as read-only; all analysis occurs on copies.

**6. Analysis & validation**- Perform offline analysis in isolated forensic environment: memory analysis with Volatility, yara signatures, timeline creation.- Validate suspicious binaries via sandboxing in isolated lab.- Correlate logs (CloudTrail -> flow logs -> host logs) to map lateral movement and root cause.

**7. Remediation & recovery**- Rotate credentials and revoke compromised keys using automated scripts.- Rebuild workloads from trusted images; patch vulnerabilities discovered.- Apply preventive controls: enable least privilege, IAM guardrails, detect anomalous API calls, and EDR agents.

**8. Documentation & legal**- Produce incident report with timeline, evidence manifest, hashes, analysis results, impact metrics.- Coordinate preservation orders with legal if required.

**Tools & cloud-specific examples**- AWS: CloudTrail, VPC Flow Logs, S3 Object Lock, EBS snapshots, Systems Manager Run Command, Traffic Mirroring, KMS + CloudWatch, Organizations SCP.- Azure: Activity Logs, NSG flow logs, Azure Blob immutability, Azure Bastion + Run Command, Traffic Analytics.- GCP: Cloud Audit Logs, VPC Flow Logs, Snapshot exports, Cloud Functions for automation.

**Trade-offs & reasoning**- Live memory capture may disrupt performance; prefer targeted SSM-run capture and traffic mirroring to avoid downtime.- Blocking network traffic is quick but may impact availability; prefer isolation via SG rules and traffic mirroring initially.- Moving artifacts to separate account preserves integrity and reduces chance of attacker tampering.

This playbook balances evidence integrity, forensic completeness, and service continuity by prioritizing non-destructive captures, using provider-native tooling, strict chain-of-custody, and automated, auditable steps for repeatability.

HardTechnical

89 practiced

A third-party vendor needs limited access to a specific S3 prefix and a narrow set of API actions for integration. Design a secure cross-account access pattern that enforces least privilege, provides auditability, and allows immediate revocation. Include how you would provide short-lived credentials and log vendor activity.

Sample Answer

**Approach (brief)** Create a dedicated cross-account IAM Role in our account with a narrow S3 policy (prefix + actions) and a tight trust policy requiring the vendor account + an external ID. Issue short‑lived credentials via STS AssumeRole. Audit with CloudTrail Data Events + S3 server access logs. Revoke instantly by disabling or removing the role’s trust policy (or applying an explicit Deny SCP/permission boundary).

**Design details**- Create Role in our account (Account A) named VendorIntegrationRole.- Trust policy: allow sts:AssumeRole from vendor account (Account V) and require an external-id the vendor supplies.- Inline permission policy: only s3:GetObject, s3:PutObject, s3:ListBucket limited to arn:aws:s3:::my-bucket and arn:aws:s3:::my-bucket/vendors/vendor-id/*; add condition restricting aws:RequestedRegion or source IP if known.

Example permission policy:

json

{
  "Version":"2012-10-17",
  "Statement":[
    {
      "Effect":"Allow",
      "Action":["s3:GetObject","s3:PutObject","s3:ListBucket"],
      "Resource":[
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/vendors/vendor-id/*"
      ],
      "Condition": {
        "StringEquals": {"s3:prefix": "vendors/vendor-id/"},
        "Bool": {"aws:SecureTransport": "true"}
      }
    }
  ]
}

**Short‑lived credentials**- Vendor calls sts:AssumeRole with RoleArn and ExternalId; specify DurationSeconds (e.g., 3600s). We avoid long‑lived keys entirely.- Example AWS CLI for vendor:

bash

aws sts assume-role --role-arn arn:aws:iam::A:role/VendorIntegrationRole --role-session-name vendor-session --external-id "unique-id" --duration-seconds 3600

**Auditability**- Enable CloudTrail data events for the S3 bucket (object-level) — logs every GetObject/PutObject to CloudTrail.- Enable S3 server access logging and deliver logs to a secured analytics bucket.- Route CloudTrail to CloudWatch Logs and create alerts/metric filters for unusual patterns (high error rate, high obj count).- Tag assumed-role sessions (aws:RequestTag or session tags) so logs show vendor identity and session id.

**Immediate revocation**- Remove the Role's trust policy entry for the vendor (prevents new AssumeRole calls) OR attach an explicit Deny policy to that role or apply a Service Control Policy if using Organizations.- For immediate termination of active sessions, rotate the role’s permissions or change the role name; active STS tokens remain valid until expiry, so keep session TTL short (<= 1 hour) to limit window.

**Monitoring & best practices**- Use external-id to prevent confused deputy attacks.- Least privilege policy and prefix conditions; require HTTPS.- Regularly review CloudTrail logs and rotate external-id monthly.- Optionally front S3 access via an API Gateway + Lambda that enforces additional business logic and gives full revocation control by invalidating API keys.

HardBehavioral

85 practiced

Behavioral: Tell me about a time when you had to make a difficult trade-off between security and product delivery in a cloud migration. Describe the context, the options you evaluated, the decision you made, how you communicated it to stakeholders, and the outcome (use the STAR method).

Sample Answer

**Situation**I led the AWS migration for a SaaS product used by financial customers. Deadline: 3-month contract milestone. Security requirements (encryption-in-transit+at-rest, strict IAM, VPC isolation, audit logging) plus limited engineering capacity created a conflict: meet delivery date or complete every security control before cutover.

**Task**Decide which security controls could be deferred or mitigated so we could deliver the migration on schedule without exposing unacceptable risk.

**Actions**- Listed options and risks in a matrix for stakeholders: - Full-security-first: delay by 4–6 weeks (strong controls, higher risk to contract). - Phased-security: migrate core services with baseline security and add advanced controls post-cutover. - Minimal-security: quick cutover, defer many controls (high risk).- Evaluated controls by threat impact: data-in-transit, credentials, auditability ranked highest.- Chosen approach: Phased-security. - Implemented non-negotiables before cutover: VPC with private subnets, TLS everywhere, KMS-managed keys for DBs, least-privilege IAM roles with short-lived STS tokens, CloudTrail + GuardDuty enabled. - Deferred lower-risk items: WAF tuning, granular permission boundaries, full CSPM remediation workflow. - Added compensating controls: automated alerting, tight security groups, SCPs to prevent open S3, and daily security sprint post-cutover.- Communication: Presented the risk matrix and mitigation plan to CTO, product manager, and compliance; secured written sign-off with clear rollback/runbook and acceptance criteria. Provided weekly dashboard and incident playbook.

**Result**We met the contractual milestone and migrated with zero security incidents. Post-cutover sprints completed remaining controls within 3 weeks. Stakeholders were satisfied—product launch proceeded—and compliance signed off after evidence from logs and a follow-up internal audit. Lesson: bake critical security into migration plan, use a transparent risk matrix, and apply compensating controls when trade-offs are necessary.

Unlock Full Question Bank

Get access to hundreds of Cloud Security Architecture interview questions and detailed answers.

Join thousands of developers preparing for their dream job.