Security and Compliance Architecture Questions

Architecting systems to meet security requirements and regulatory and compliance obligations. Candidates should understand how to embed data classification, data governance, encryption, least privilege access, audit trails and logging, secure design patterns, and threat modeling into architectures. Expect discussion of how architectural choices affect obligations under common regulations such as the General Data Protection Regulation, the Health Insurance Portability and Accountability Act, the Payment Card Industry Data Security Standard, and System and Organization Controls frameworks. Topics include documenting architecture for compliance reviewers, retention and data residency considerations, denial of service mitigation and web application firewall strategies, and balancing security controls with usability and operational cost. Candidates should be able to describe when to engage legal and compliance teams and how to design for auditability and evidence capture.

HardSystem Design

52 practiced

A new regulation requires stronger control over privileged sessions for administrators. Design a privileged-access management solution that provides session recording, just-in-time access approval, and tamper-proof audit logs while integrating with existing SSO. Describe the architecture, components, and how to validate control effectiveness.

Sample Answer

**Clarify requirements & constraints**- Must record privileged admin sessions, enforce just‑in‑time (JIT) access with approvals, produce tamper‑proof audit logs, and integrate with existing SSO (SAML/OIDC). Assume cloud + on‑prem resources, scale to hundreds of admins, retention 1–7 years.

**High‑level architecture**- SSO (IdP) → PAM Gateway (session broker) → Target Systems- Components: SSO/IdP, PAM Broker (SSH/RDP/jump host), Approval Workflow Service, Session Recorder, Immutable Audit Store, SIEM/Analytics, Secrets Vault, Admin Portal/API.

**Core components & responsibilities**- PAM Broker (agentless or agent): enforces access, proxies sessions, injects banners, enforces MFA from IdP, records keystrokes/stream video and metadata.- Approval Workflow: creates JIT requests (timebound), ties to ticket/CI, sends approvals to managers; integrates with SSO for identity and groups.- Secrets Vault: dynamic credentials or ephemeral keys injected per session (no static creds).- Session Recorder: captures full session stream + metadata, signs chunks with HSM key.- Immutable Audit Store: WORM storage (object lock), hash‑chain signatures, store copies to remote SIEM and cold archive. Use HSM/Cloud KMS for signing.- SIEM & Replay UI: searchable events, playback with redaction, alerting on anomalous behavior.

**Control flows**1. Admin authenticates via SSO (OIDC/SAML) → obtains short‑lived token.2. Admin requests privileged access in Portal → Approval workflow enforces policy (time, scope).3. On approval, PAM issues ephemeral credential from Vault; Broker proxies session and records.4. Recorder signs/chunks logs → writes to Immutable Store and forwards to SIEM.

**Tamper‑proofing**- Sign each log chunk with HSM/KMS; store hash chain.- Write‑once storage with object lock + cross‑region replication.- Maintain separate audit-only accounts and encryption keys.

**Validation & effectiveness**- Functional tests: approve/deny flows, session playback, credential rotation, role-based policy enforcement.- Integrity tests: verify signatures, recompute hashes, attempt controlled tamper to ensure detection.- Performance: concurrency/load testing on Broker and Recorder.- Compliance checks: retention, access reviews, separation of duties.- Security testing: automated unit tests, penetration tests, purple/red team scenarios simulating insider threats.- Metrics/KPIs: mean time to grant, percent sessions recorded, detection latency, audit log integrity errors.

**Trade‑offs**- Agentless easier rollout but limited context; agents give richer telemetry.- Centralized broker single‑point requires HA and scaling (use autoscaling, regional brokers).

This design provides JIT, complete session capture, and cryptographically verifiable, immutable logs while leveraging existing SSO for identity and MFA.

MediumSystem Design

50 practiced

Design a secure server provisioning pipeline for a cloud environment that enforces least privilege, encrypts secrets, and creates immutable hosts. Include technologies you would use (e.g., IaC, secret stores, image pipelines), the steps from commit to production, and how you would provide auditors with evidence of conformity.

Sample Answer

**Overview (one line)** I’d implement an automated, auditable pipeline that builds signed immutable images from IaC, injects secrets at runtime via a secret store, enforces least privilege with fine-grained IAM and policy-as-code, and produces tamper-proof evidence for auditors.

**Technologies** - IaC: Terraform + Terragrunt (state in remote backend) - Image pipeline: Packer → registry (signed with Cosign/Sigstore) - CI/CD: GitHub Actions or GitLab CI - Secrets: HashiCorp Vault (with Transit KMS), AWS/GCP KMS for envelope encryption - Policy-as-code: OPA + Conftest, Sentinel or Gatekeeper for Kubernetes - Runtime: Immutable hosts via AMIs/GKE node images or container images orchestrated by EKS/GKE/VM Scale Sets - Identity: Short-lived roles (AWS STS / GCP Workload Identity), IAM least-privilege roles

**Commit → Production steps** 1. Developer opens PR with Terraform + app changes. CI runs static checks (tfsec, tflint), unit tests. 2. Merge triggers pipeline: Packer builds AMI/container image; image hardening (CIS), vulnerability scan, SBOM generation. 3. Image is signed with Cosign; signature and SBOM published to artifact registry. 4. Terraform plan generated and policy-evaluated by OPA/Conftest; plan stored and signed. 5. Approval gate (automated for non-prod; manual for prod). On approval, apply uses ephemeral CI identity to provision resources. Secrets not baked: runtime services fetch secrets from Vault using short-lived tokens. Vault uses KMS for encryption-at-rest and mTLS for auth. 6. Deploy uses immutable images (replace-not-patch). Rollback uses prior signed image.

**Least-Privilege & Secrets** - IAM roles scoped to specific actions/resources, no long-lived keys. - Workload Identity / Vault auth methods map service identity to limited Vault policies. - Secrets encrypted with KMS; Transit used for dynamic encryption when needed. - No plaintext secrets in state: Terraform state encrypted and access-restricted; sensitive outputs suppressed.

**Auditor Evidence** - Signed image artifacts and SBOMs in registry (hash + signature). - Git history + PR pipeline logs showing policy checks and approvals. - Terraform plans and apply logs stored in immutable object storage (versioned, access-logged). - Vault audit logs and KMS access logs (exportable). - OPA/Conftest policy evaluation logs and policy versions. - Cloud provider audit logs (IAM activity, STS token usage). - A reproducible script to rebuild artifact from commit to show conformity; provide signed attestations (Sigstore) and a short report summarizing controls, timestamps, and hashes.

**Why this works** Immutable, signed artifacts + short-lived identities eliminate credential sprawl and drift; policy-as-code enforces least privilege before apply; centralized secret encryption and audit logs give auditors verifiable, cryptographically-backed evidence.

EasyTechnical

43 practiced

Explain the difference between security architecture and security controls in an enterprise systems context. In your answer, describe how architecture shapes control selection, give three concrete examples of architecture-level decisions and three example controls that implement those decisions, and explain why both are required when designing cloud infrastructure for a company of about 5,000 employees.

EasyTechnical

75 practiced

List and explain five secure design patterns a systems engineer should use when architecting multi-tenant cloud services. For each pattern, provide a short example of how it reduces risk or meets a compliance requirement.

MediumTechnical

53 practiced

Outline a compliance-aware incident response runbook for a breach that may impact PII. Include detection, containment, forensic evidence preservation steps, internal and external notifications (including timelines), and how to prepare artifacts for regulatory reporting.

Sample Answer

**Situation & scope clarification**- Confirm suspected breach affects PII systems (which systems, data classes, user count, cloud regions). Identify applicable regulations (GDPR, CCPA, HIPAA) to set timelines and required fields.

**Detection**- Triage alerts from SIEM/EDR, WAF, IDS/IPS, cloud guardrails, unusual API activity, data exfil heuristics.- Capture initial indicators: timestamps, source IPs, user IDs, affected resources.

**Containment**- Short-term: isolate compromised hosts (remove from network, apply host quarantine via EDR), revoke compromised keys/tokens, rotate service credentials, block attacker IPs at WAF and security groups.- Long-term: apply patches, restore from known-good AMIs/snapshots, enforce MFA and least privilege.

**Forensic evidence preservation**- Take immutable snapshots of affected VMs/EBS, export cloud provider activity logs (CloudTrail/Azure Activity), collect memory images where possible, preserve container images and orchestration logs.- Preserve network captures (pcap) or VPC flow logs; copy logs to write-once storage.- Maintain chain-of-custody: who accessed artifacts, timestamps, hashes (SHA-256), storage location.- Work with legal/forensics vendor before making destructive changes.

**Internal & external notifications (timelines)**- Immediate (within 1 hour): notify Incident Response lead, CISO, legal, privacy officer, infra owners, and SOC.- 24 hours: escalation update to execs and begin regulatory assessment.- Regulatory: GDPR — assess within 72 hours for notification to Data Protection Authority with required fields (nature, categories of PII, estimated records affected, mitigation). CCPA/HIPAA — follow relevant timelines/requirements; consult legal.- Affected data subjects: as required by law/regulation—provide clear scope, mitigation steps, contact for inquiries.

**Preparing artifacts for regulatory reporting**- Produce a timeline of events with evidence-backed facts.- Include: affected systems list, PII types/estimated records, attack vector, indicators of compromise, containment/remediation actions, root cause analysis plan, mitigation steps, contact info.- Attach hashes, snapshots metadata, redacted logs, and chain-of-custody records.- Ensure sensitive artifacts released to authorities are redacted appropriately and shared via secure channels.

**Post-incident**- Conduct full RCA, implement preventative changes (IAM, network segmentation, monitoring), update runbook, and run tabletop exercises.

This runbook balances rapid technical containment with forensic rigor and compliance timelines expected of a systems engineer managing cloud infrastructure.

Unlock Full Question Bank

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

Join thousands of developers preparing for their dream job.