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

51 practiced

For a telehealth platform storing and transmitting protected health information (PHI), propose an architecture and set of technical/administrative controls to meet the HIPAA Security Rule (access controls, audit controls, integrity, transmission security). Explain how you would demonstrate compliance and readiness for an OCR investigation.

Sample Answer

**High-level architecture**- Segmented microservices on private VPCs (API gateway, auth, PHI store, audit/logging, analytics) with managed DB (encrypted at rest), HSM/KMS for keys, and EHR connectors via mTLS. Single-tenant or strong tenancy isolation for PHI.

**Technical controls (Security Rule mapping)**- Access Controls: Zero Trust IAM (OIDC + SCIM), RBAC + ABAC, MFA, short-lived tokens (OAuth2), privileged access workstations, just-in-time elevation, session limits, device posture checks.- Audit Controls: Centralized immutable logging (WORM S3 + SIEM), detailed access and activity events (who/what/when/resource), tamper-evident integrity via append-only logs and signatures, 90–365 day retention policy and fast search.- Integrity: Object signing (HMAC/ED25519), DB-level row/versioning, transactional hashes, change control and CI/CD signing, automated integrity checks.- Transmission Security: TLS1.3 with mTLS for service-to-service, opportunistic TLS for clients, perfect forward secrecy, application-layer message signing, VPN for admin access.

**Administrative controls**- Formal risk analysis, policies (access, encryption, retention), BAA with vendors, workforce HIPAA training with attestations, patch/CMDB, least-privilege onboarding/offboarding, incident response runbooks, quarterly tabletop exercises.

**Demonstrating compliance & OCR readiness**- Evidence package: latest risk assessment, security policies, BAA copies, role-based access lists, MFA logs, SIEM reports/samples, immutable audit exports, encryption key custody docs, training records, IR playbook and past incident reports with remediation timelines, penetration test and vuln-scan results, change logs for corrective actions.- Operational readiness: automated evidence export scripts, playbook for producing chain-of-custody of logs, quarterly internal audits and third-party SOC2/HIPAA attestation, root-cause documentation for any breaches and remedial actions.

**Trade-offs & rationale**- Favor managed cloud services for audited primitives (KMS, HSM, managed DB) to reduce operational risk but enforce BAAs and customer-key options for added control.

MediumSystem Design

61 practiced

Given a requirement to protect sensitive data at rest and in transit across microservices, describe a key management architecture: KMS selection (cloud vs on-prem), key hierarchy, HSM use cases, envelope encryption pattern, rotation strategy with zero-downtime, access controls, and multi-region key replication while meeting compliance needs.

Sample Answer

**Clarify requirements**- Protect data at rest and in transit across microservices, support multi-region, meet PCI/GDPR/SOC2 compliance, minimize operational burden and downtime.

**KMS selection (cloud vs on‑prem)**- Prefer cloud KMS (AWS KMS, Azure Key Vault, GCP KMS) when workloads are cloud-native for managed availability, integrated IAM, logging, and multi‑region replication.- Choose on‑prem or hybrid HSM-backed KMS (Thales, SafeNet, Luna) when policy/contract demands full key custody or FIPS 140‑2/3 Level 3+ hardware controls.- Use BYOK/CMK patterns to maintain control while leveraging cloud managed features.

**Key hierarchy**- Root/Root-of-Trust: offline, tightly controlled, rarely used.- Master Key (KEK): HSM-backed, used to encrypt DEKs; stored in KMS.- Data Encryption Keys (DEKs): short-lived, per‑object or per‑service, used for actual data encryption.- Service/key-scoped wrapping keys for microservices multi‑tenant isolation.

**HSM use cases**- Generate and store KEKs and root keys.- Perform cryptographic operations (signing, key wrapping) without exporting key material.- Support attestation and tamper-resistance required for compliance.

**Envelope encryption pattern**- DEK generated per object/session; plaintext DEK used to encrypt data; DEK wrapped with KEK from KMS/HSM.- Store wrapped DEK alongside ciphertext (or in metadata).- Microservices request unwrap from KMS only when needed; prefer caching unwrapped DEKs in secure memory with TTL.

**Rotation strategy with zero‑downtime**- Rotate KEK: create new KEK, keep old KEK active for unwrap operations, re-wrap existing DEKs with new KEK asynchronously.- Rotate DEKs: generate new DEKs for new data; background re-encryption pipeline (worker jobs) re-encrypt existing objects gradually; use version metadata so services can read old and write new keys transparently.- Ensure dual-read support: services attempt decrypt with latest KEK, fall back to older KEKs during transition.- CI/CD and feature flags to coordinate rollout; maintain backward compatibility for key versions.

**Access controls & governance**- Principle of least privilege via IAM roles + RBAC/ABAC; separate duties for key admins vs operations.- Grant KMS decrypt/wrap permissions to service roles only for required key IDs and operations; use context conditions (source IP, VPC, time).- Enforce MFA and approval workflows for sensitive ops (create/rotate/destroy).- Audit: enable immutable audit logs (CloudTrail/ELK), key usage monitoring, alerting on anomalies.- Use periodic key access reviews and cryptographic policy enforcement.

**Multi‑region replication & compliance**- Use KMS native multi‑region keys (AWS multi‑region keys) or replicate wrapped DEKs and ciphertext to target regions.- For compliance, keep keys in-region when required; use import to HSM/bring-your-own-key per region.- Ensure cross‑region key replication uses secure transport (mutual TLS), encrypted backups, and replication audit trails.- Document data residency and key custody in compliance artifacts; use attestation evidence from HSM vendors.

**Trade-offs & operational notes**- Cloud KMS reduces ops but requires trust/contract controls; on‑prem HSM increases control and cost.- Envelope encryption minimizes KMS load and attack surface.- Plan for key compromise: maintain revocation, re‑encryption playbooks, and incident response with timelines.

This architecture balances security, availability, and compliance while enabling microservices-scale encryption with minimal downtime.

EasyTechnical

61 practiced

Explain symmetric versus asymmetric encryption and describe where each should be used within an enterprise security architecture. Include examples (database at-rest encryption, TLS, signing), key distribution considerations, performance impacts, and when to use hardware security modules (HSMs).

EasyTechnical

48 practiced

Describe the primary functions of a Web Application Firewall (WAF) and walk through how a security architect decides between a managed WAF service, CDN-integrated WAF, or an in-house WAF appliance. Include considerations for false positives, latency, rule tuning, API protection, and operational overhead.

MediumTechnical

45 practiced

Describe how to architect systems for auditability: identify what evidence to capture (user actions, approvals, configuration changes), how to correlate events across services (unique trace IDs), ways to prove action completion to auditors, and how to store and present evidence while protecting sensitive content within audit artifacts.

Sample Answer

**Approach summary (as a Security Architect)** I would design auditability as a cross-cutting service: what to capture, how to correlate, how to prove completion, and how to store/present evidence while protecting sensitive data.

**What evidence to capture** - User actions: authn/authz events, command/API calls, UI actions (who, when, from where, request/response). - Approvals/workflows: approver ID, decision, timestamp, rationale, related artifacts. - Configuration changes: before/after state, diff, operator, change ticket/PR id. - System events: job runs, cron triggers, exceptions, alerts.

**Correlation across services** - Emit a globally-unique trace ID per business transaction (propagated via headers/logs). - Enrich logs with context: tenant ID, request ID, actor, correlation ID. - Centralize into a SIEM/observability platform (Elastic/ Splunk/Chronicle) and instrument K/V for rapid joins.

**Proving action completion** - Generate signed, timestamped receipts for significant actions (HMAC or asymmetric signature), include trace ID and hashes of artifacts. - Use append-only storage (WORM or immutable object store) and record chain-of-custody metadata. - For high-assurance, anchor hashes into external ledger or timestamping service.

**Storage & presentation with data protection** - Store raw audit records in an immutable, access-controlled lake; index and redact PII before analyst views. - Protect secrets: encrypt at-rest (per-tenant keys) and in-flight; store sensitive fields encrypted with field-level keys. - Use hashing/format-preserving masking for sensitive values in audit artifacts; keep re-identification keys in a sealed keystore with strict KMS policies and audit logging. - Present via role-based dashboards and exportable signed reports; include drill-down to raw signed receipts when auditors have approved access.

**Operational controls & compliance** - Define retention and legal hold policies, regular integrity checks, alert on log gaps, and periodic forensic exercises. - Document SLAs, threat model, and mapping to controls (e.g., SOC/ISO/GDPR) for auditor review.

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.