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.

HardTechnical

47 practiced

Conduct a threat modeling exercise for a serverless event-driven application architecture (functions, managed queues, API gateway). Identify major attack vectors, privilege escalation paths, third-party risks, and propose architectural mitigations including runtime controls, observability and least-privilege configurations.

Sample Answer

**Threat model summary (context)** Serverless event-driven stack: API Gateway → Functions (FaaS) → Managed queues/topics (SQS/SNS/Kinesis) → downstream functions/services. Attack surface: external APIs, event queues, function execution environment, managed services, third-party libraries/CI.

**Major attack vectors**- Unauthorized API access (broken auth, JWT misuse, misconfigured CORS)- Event injection or replay into queues/topics- Compromised function code or supply-chain (npm/pypi) introducing backdoors- Secrets leakage via environment variables, logs, or build artifacts- Overly-broad IAM roles allowing lateral movement or data exfiltration- Misconfigured resource policies (public S3, open queue policies)- Runtime escapes / vulnerable native libs in the execution environment- Denial-of-service via high event volume or function throttling

**Privilege escalation paths**- Function role with iam:PassRole or sts:AssumeRole allowing escalation- Broad wildcard IAM policies (s3:*, kms:*, lambda:*)- Ability to write code/artifacts into CI/CD or deployment buckets (compromise CI → elevated deploy)- Event consumers that can invoke management APIs (create new functions/roles)

**Third-party risks**- Vulnerable or malicious dependencies- External SaaS/webhooks injecting crafted events- Managed-platform misconfigurations / provider control plane compromise

**Architectural mitigations**- Identity & least privilege - Per-function minimal IAM roles (narrow actions + resource ARNs), deny iam:PassRole unless explicit - Use resource-based policies with condition keys (aws:SourceArn, aws:SourceAccount) - Short-lived credentials and tokenized service-to-service auth (OIDC, mTLS)- Event integrity & anti-replay - Sign events (HMAC) and validate signature in consumer - Use FIFO queues with deduplication or sequence checks; enforce message TTLs and DLQs- Network & exposure controls - Keep sensitive functions in private VPCs with VPC endpoints to managed services - API Gateway WAF, rate limiting, and authorizers (Cognito / JWT introspection)- Secrets & encryption - Store secrets in KMS-backed secrets manager; do not put secrets in env vars or logs - Encrypt data at rest and in transit; use separate KMS keys per trust boundary- Supply-chain and deployment hardening - Signed artifacts and image provenance (SBOM), lockfile enforcement, dependency scanning in CI - Least-privilege deploy pipeline: separate deploy roles, approval gates for privileged changes- Runtime controls & isolation - Constrain function runtimes (CPU/memory/timeouts), enable platform sandboxing features - Use container-based FaaS for stricter syscall filtering or eBPF-based runtime enforcement - Implement process-level mutation detection, file-system write restrictions- Observability & detection - End-to-end tracing (X-Ray/OpenTelemetry) linking API → events → functions → downstream - Centralized audit logs (CloudTrail), ingestion to SIEM/EDR, alert on anomalous API calls, role usage spikes - Runtime telemetry: function invocation metrics, latency, error spikes, unusual outbound network calls - Threat detection: GuardDuty-like services, anomaly ML for queue volumes and auth failures- Governance & automation - Policy-as-code (Terraform + Sentinel / OPA / Cloud Custodian) enforcing least privilege and resource policies - Automated CI tests: static analysis, secret scanning, dependency checks, unit tests for event validation - Regular pentest and dependency vulnerability scans; rotate keys on compromise

**Example mappings (AWS)**- API: API Gateway + WAF + Cognito authorizer- Functions: Lambda with per-function IAM role (no iam:PassRole), VPC endpoints, Lambda layers from approved registries- Queues: SQS with policy restricting producers, message signing and DLQ- Secrets: Secrets Manager + KMS- Observability: CloudTrail, CloudWatch Logs + Insights, X-Ray, GuardDuty, Detective; SIEM ingestion and alerting

**Key trade-offs**- Strict least-privilege increases operational overhead (role explosion) — mitigate with role templates and automation- VPC-enabled functions may add cold-starts; weigh against network egress controls

This design reduces attack surface, prevents common privilege escalations, hardens the deployment pipeline and runtime, and provides observability to detect and respond quickly.

MediumSystem Design

49 practiced

You need to protect sensitive fields (e.g., SSNs, credit card numbers) used by an enterprise application. As a Cloud Architect, design options for field-level protection including client-side encryption, envelope encryption, tokenization, and database-level encryption. Compare trade-offs for security, performance, and compliance.

Sample Answer

**Clarify requirements & constraints**- Regulatory scope (PCI DSS, GLBA, HIPAA), retention/use cases (search, analytics), threat model (server compromise, insider, client compromise), performance/latency SLAs, key management responsibilities.

**Design options (summary)**- Client-side encryption: encrypt in client/browser/mobile; keys never touch server.- Envelope encryption: data encrypted with data key; data key encrypted with KMS master key.- Tokenization: replace sensitive value with token; original stored in a secure vault.- Database-level encryption (TDE/column-level): encryption at rest inside DB, transparent to app.

**Trade-offs**- Security: - Client-side: strongest for server breach, protects in-transit and at-rest; vulnerable if client compromised; complex key distribution. - Envelope + KMS: good balance; minimizes key exposure; supports rotation/audit. - Tokenization: reduces scope (PCI SAQ); vault compromise critical; supports format-preserving tokens. - DB-level: protects against disk compromise, not against DB admin or app-layer breaches.- Performance: - Client-side: CPU on client; increases payload size; may affect UX. - Envelope: low overhead per-request; KMS calls add latency (use caching for DEKs). - Tokenization: fast once tokenized; vault lookups add latency for detokenization. - DB-level: minimal app latency; DB CPU/storage overhead.- Compliance & Operations: - Client-side + tokenization reduce PCI scope; require strong key/vault ops. - Envelope with KMS provides audit/logging and easier key rotation. - DB-level eases app changes but may not satisfy regulator requirements for scope reduction.

**Recommendations**- Use client-side or envelope encryption for highest assurance; combine envelope encryption with cloud KMS (multi-region CMKs, HSM-backed) for manageability.- Use tokenization for card PANs to reduce PCI scope; implement vault with strict access controls, HSM storage, and replica isolation.- Use DB encryption (TDE) as defense-in-depth, not sole control.- Always: enforce least privilege, rotate/expire keys, audit logs, implement hardware-backed KMS/HSM, and define incident/runbook.

EasyTechnical

49 practiced

As a Cloud Architect, explain what a data classification scheme is and how you would design a classification taxonomy for an enterprise cloud environment. Describe categories, handling rules, ownership, automated enforcement (tagging, labels) and how classification maps to technical controls and monitoring.

EasyTechnical

49 practiced

As a Cloud Architect tasked with preparing documentation for a compliance reviewer, what diagrams, artifacts, and control mappings would you include? Provide an outline and explain why each piece is necessary for auditability and evidence gathering.

MediumSystem Design

60 practiced

Architect a scalable RBAC model for an enterprise cloud with thousands of users across multiple business units. Discuss role design, group hierarchies, attribute-based policies, delegation, automation for onboarding/offboarding, and how you would measure and reduce permission sprawl.

Sample Answer

**Clarify goals & constraints**- Support thousands of users, multiple BUs, least privilege, auditability, cross-cloud consistency, minimal operational friction.

**Role design**- Use hybrid RBAC + ABAC. Define coarse-grained functional roles (e.g., CloudAdmin, NetworkOperator, AppReader) and fine-grained permission sets (ability to attach policies scoped to resources).- Roles are immutable templates; permission sets versioned and reviewed.

**Group hierarchies & scoping**- Map organizational units to groups: Global > BU > Project. Assign roles to groups, not individuals. Use inheritance where a BU group inherits baseline roles from Global but can add project-specific roles.

**Attribute-based policies**- Enforce resource tags (env, owner, project, criticality) and principal attributes (role, business_unit, manager). Write policies that combine role + attributes to grant time-bound or scoped access (e.g., allow S3 access if tag.project == principal.project).

**Delegation**- Use delegated admin roles per BU with constrained capabilities and approval workflows. Implement Just-In-Time elevation for sensitive actions via approval and session-limited credentials.

**Automation: onboarding/offboarding**- Integrate IAM with HR/IdP (SCIM), provision groups/roles automatically from employee attributes, create default tickets for additional access, and remove access on termination via automated workflows and orphaned account detection.

**Measure & reduce permission sprawl**- Metrics: number of active roles per user, unused permissions, cross-BU role assignments, % of access granted via broad roles. Run quarterly access reviews and automated entitlement analytics to detect over-privilege. Remediate by breaking large roles into least-privilege permission sets, introducing just-in-time, enforcing tag-based scoping, and retiring stale roles.

**Trade-offs**- More ABAC reduces role explosion but needs disciplined tagging and tooling. Prioritize automation and observability to keep operational costs low while enforcing security.

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.