Designing, implementing, and operating security and compliance controls for infrastructure and delivery pipelines at scale. Topics include identity and access management, authentication and authorization patterns, role based access control and least privilege, secrets management and rotation, encryption for data at rest and in transit, network segmentation and microsegmentation, zero trust architecture, audit logging and retention, vulnerability scanning and patch and remediation workflows, endpoint protection, threat detection and monitoring, threat modeling and risk assessment, incident detection and response planning and runbooks, software supply chain security including artifact signing and dependency scanning and provenance, policy as code and automated security gates in continuous integration and continuous delivery pipelines, automated testing and validation of controls, and the trade offs between security controls and developer velocity. Also covers embedding and operationalizing compliance requirements from common regulatory frameworks and standards such as the General Data Protection Regulation, the Health Insurance Portability and Accountability Act, Service Organization Controls two, the Payment Card Industry Data Security Standard, and International Organization for Standardization two seven zero zero one, and how those requirements influence architecture, controls, automation, monitoring, and auditability as systems scale globally.
HardSystem Design
66 practiced
Design compliance and security controls for a SaaS application that stores protected health information (PHI) under HIPAA. Address encryption, access controls, audit logging, breach notification workflows, business associate agreements (BAAs), region selection and data residency, and automation for evidence collection during audits.
Sample Answer
**Clarify scope & constraints**- PHI SaaS on cloud (assume AWS/GCP), multi-tenant, production & DR, HIPAA compliance required. DevOps focus: automation, infra, deployment, monitoring.**Encryption**- In transit: TLS 1.2+; mutual TLS for service-to-service where appropriate.- At rest: provider-managed encryption + customer-managed keys (KMS/HSM) for sensitive datasets. Rotate keys regularly; enforce envelope encryption for object stores and DBs.- Example: AWS KMS CMKs (multi-Region replicas) with CloudHSM for highest assurance.**Access controls**- Principle of least privilege, role-based access (IAM + RBAC in Kubernetes).- Break out roles: Platform Admin, Dev, SRE, Auditor; use temporary credentials (STS), IAM conditions (IP, time).- Enforce MFA for console access; service accounts scoped by minimal permissions; Secrets in Vault/KMS with automatic rotation.**Audit logging & integrity**- Centralized immutable logs: CloudTrail/Cloud Audit + VPC Flow + application logs forwarded to SIEM (Splunk/Elastic/Sumo/Stackdriver) with WORM storage (S3 Object Lock).- Log tamper-evidence: cryptographic signing, retention policies aligned to HIPAA.- Correlate logs with trace IDs; retain access logs for configured retention (e.g., 6+ years per policy).**Breach detection & notification**- Detection: IDS/IPS, anomaly detection in SIEM, alerting (PagerDuty).- Playbook: triage, containment, scope assessment, forensics, legal/data-owner notification.- Timelines: internal notification within 24 hours; HIPAA-compliant patient notifications and OCR reporting per statute and counsel.- Maintain runbooks and automate evidence collection (snapshot of logs, snapshots of EBS, metadata).**BAAs & vendor management**- Execute BAAs with cloud providers and third-party vendors touching PHI.- Maintain inventory of all sub-processors; review SOC2/HIPAA reports periodically.**Region selection & data residency**- Choose regions to meet patient residency laws and minimize cross-border transfer; enable region-replication only to approved Regions; use VPC endpoints and private connectivity (AWS PrivateLink, Interconnect).- Encrypt inter-region replication and enforce key policies that restrict decryption to approved accounts/regions.**Automation for audits & evidence**- Compliance-as-Code: Terraform + Sentinel/OPA policies to enforce encryption, logging, network rules at PR time.- CI/CD checks: pre-deploy scans, container image signing, infrastructure drift detection.- Automated evidence collection: scheduled scripts/playbooks that pull validated snapshots (config, IAM, KMS policies, logs), generate audit reports, and store in immutable artifact repo with access controls.- Example pipeline: PR -> OPA policy -> Terraform apply -> Runbook triggers automated attestations (JSON report) stored in S3 Glacier Vault with hashes.**Trade-offs & monitoring**- Balance performance vs. encryption/key management overhead. Prefer automation to reduce human error.- Continuous testing: periodic penetration tests, tabletop breach exercises, and audit drills.This design enforces technical controls, legal contracts (BAA), and automated evidence generation to meet HIPAA while enabling DevOps velocity.
MediumTechnical
74 practiced
Design a workflow for rotating database credentials automatically using HashiCorp Vault dynamic secrets for applications deployed via CI/CD and Kubernetes. Describe the auth method (e.g., Kubernetes auth), lease management, secret caching, renewal, key steps for rollout without downtime, and how to detect and recover from rotation failures.
Sample Answer
**Approach summary**Design Vault dynamic DB creds with Kubernetes auth, per-app roles, short leases, client-side caching/renewal, and safe rollout via phased refresh with observability and automatic recovery.**Auth & roles**- Use Kubernetes auth: bind Vault Role to K8s ServiceAccount and namespace, with RBAC least privilege.- Vault DB secrets engine configured with rotation SQL templates and role per-app (e.g., app_readonly_role).**Lease management & renewal**- Set short default lease (e.g., 1h) and max TTL.- Apps obtain creds from Vault and treat lease_id as authoritative.- Implement automatic renewal: either long-lived agent (Vault Agent with auto-auth and cache) or sidecar that renews before 2/3 of TTL.**Secret caching & retrieval**- Use Vault Agent + file sink or CSI provider to expose creds to pods; agent caches and renews locally to minimize Vault calls.- For CI/CD jobs, use Vault CLI/auth plugin to request creds at job start and tear down after job.**Zero-downtime rollout**- Rotate by issuing new credentials while old remain valid until lease expiry.- Stagger restarts: new pods fetch new creds on startup; existing pods keep renewing until they hit expiration, then failover to retrievable new creds.- Use health-checks and readiness probes to ensure only pods with valid DB connections serve traffic.**Detection & recovery**- Instrument: Vault lease metrics, DB auth failures, application DB error rates, alert on renewal failures and auth errors.- Automated recovery: on repeated renewal failures, attempt re-auth (K8s SA token refresh), fallback to cached static credential stored in sealed vault path for emergency, or trigger rolling restart of affected pods.- Manual playbook: revoke Vault role, re-create DB role binding, rotate secrets engine config, redeploy Vault Agent if corrupted.This design minimizes blast radius, enforces least privilege, and provides automated renewal plus safe rollback paths.
HardTechnical
70 practiced
Create a comprehensive policy and enforcement model for third-party dependencies that includes SBOM generation, artifact signing, vulnerability thresholds, whitelisting/blacklisting procedures, vendor risk assessment criteria, and automated enforcement points in CI/CD and runtime. Discuss escalation and exception handling.
Sample Answer
**Policy summary (goal)** Prevent insecure or unvetted third‑party components from reaching build or production while enabling developer velocity through automated checks, clear exception paths, and vendor risk metrics.**Core requirements**- SBOM: Generate CycloneDX SBOM for every build (containers, artifacts, libs). Store in artifact registry and attach to release.- Artifact signing: All build artifacts signed with CI short‑lived key (KMS/HSM). Vendors must provide signed releases where available.- Vulnerability thresholds: Block builds if any dependency has a CVSS >= 9.0. Warn for 7.0–8.9 and require tracked remediation within SLA (30 days).- Whitelist/Blacklist: Global blacklist for known-malicious packages; per-team whitelist for approved exceptions with expiry and owner.**Vendor risk assessment**- Criteria: maintainership activity, SLA for fixes, CVE history, license risk, provenance (signed releases), geographic/contractual considerations.- Scoring: quantitative 0–100; >70 = low risk, 40–70 = moderate (requires approval), <40 = high (blocked).**Automation / enforcement points**- CI/CD (pre-merge & release): run SBOM generation, SCA (e.g., Trivy/Snyk), signature verification, vendor-score check. Fail pipeline on policy violations; produce actionable report and auto-create ticket if remediation needed.- Artifact registry: reject unsigned artifacts; store SBOM alongside; tag artifacts with risk metadata.- Runtime: Kubernetes admission controller (OPA/Gatekeeper) rejects images without SBOM or with blocked risk; runtime agent monitors for new vulns and auto‑quarantines pods if high severity exploited.**Escalation & exceptions**- Exception workflow: developer files exception ticket with justification, compensating controls, and owner. Temporary allowlist with TTL (max 14 days) and mandatory remediation plan.- Escalation matrix: automated alerts to owner → security SME → engineering manager → security director based on severity/time elapsed.- Auditing: weekly reports, quarterly vendor reassessments, audit logs for all exceptions.**Operational notes**- Use KMS/HSM for signing; rotate CI keys, enforce least privilege. Integrate with Jira/ServiceNow for tickets. Provide dashboards (Grafana) for policy compliance metrics.
EasyTechnical
54 practiced
Explain the principle of least privilege and how it applies to cloud infrastructure and CI/CD pipelines. Provide concrete examples of implementing least privilege in IAM roles, service accounts, Kubernetes service accounts, and object store policies. Describe how you would audit and measure privilege creep over time and detect over-privileged identities.
Sample Answer
**Principle (brief)** Least privilege means granting identities only the permissions strictly necessary for their job and nothing more. In cloud/CI/CD this reduces blast radius from compromised keys, misconfigurations, or malicious code in pipelines.**Concrete implementations** - IAM roles (AWS/GCP/Azure): create narrow roles per function (e.g., "ecs-deploy-role" only has ecs:UpdateService, iam:PassRole for a single role ARN). Use resource-level restrictions and condition keys (source IP, VPC, time). - Service accounts (CI/CD): give the CI runner a short-lived token with minimal scopes (e.g., only storage:write to a specific bucket and iam.roles.bind denied). Use OIDC federation so no long-lived secrets. - Kubernetes service accounts: map k8s SA to an external identity (IRSA on EKS or Workload Identity on GKE). Bind to ClusterRole/Role with the fewest verbs and namespace restriction (Role instead of ClusterRole when possible). - Object store policies: bucket policies allowing PutObject/GetObject only from specific principals, paths, and via HTTPS, and require encryption headers.**Auditing & measuring privilege creep** - Automated reports: run IAM Access Analyzer / Cloud IAM Recommender weekly; export actual API calls from CloudTrail / Cloud Audit Logs and generate "last-used" metrics. - Metrics: percent identities with unused permissions, number of roles exceeding allowed permission count, time-since-last-use distribution. - Detection: flag roles with permissions used only once or never; look for sudden spikes in permission usage; integrate with SIEM for anomalous grant events. - Process: enforce policy-as-code (terraform/opa/policy checks) in PRs, periodic entitlement attestation (quarterly), and automated remediation (remove unused perms or rotate to scoped roles). This approach minimizes risk while keeping CI/CD automation functional and auditable.
HardSystem Design
111 practiced
Architect an end-to-end incident detection and response pipeline that integrates endpoint detection (EDR), cloud telemetry, a SIEM for correlation, and a SOAR for automated playbooks. Explain data normalization, enrichment (threat intelligence), playbook triggers, human-in-the-loop steps, and how to measure and reduce mean time to detect and respond.
Sample Answer
**Overview / Requirements**Design an automated pipeline that collects EDR and cloud telemetry, normalizes and enriches events, correlates in SIEM, and triggers SOAR playbooks with configurable human-in-the-loop (HITL) checkpoints to minimize MTTD/MTTR.**High-level architecture**- EDR agents (host process, file, network) + cloud telemetry (CloudTrail, VPC Flow, GuardDuty, Kubernetes audit) → log collectors (Fluentd/Vector) → message bus (Kafka/SQS).- Normalization service (schema: timestamp, source, host_id, user, event_type, severity, raw) → SIEM (correlation rules).- Enrichment engine (threat intel, asset DB, IAM context) augment events before correlation.- SIEM triggers → SOAR; SOAR executes playbooks, performs automated containment, escalates to on-call via PagerDuty for HITL review.**Data normalization & enrichment**- Normalize to a common event model (CEF/OpenTelemetry) at ingestion; drop/route duplicates, add canonical fields.- Enrichment steps: reverse DNS, GeoIP, threat intel (OTX, MISP, commercial feeds), asset criticality from CMDB, recent deploy/CI pipeline context.- Store enrichment provenance and confidence score so playbooks can make risk-based decisions.**Playbook triggers & HITL**- Trigger tiers: low-confidence → automated remediation (isolate container, block IP), medium → automated evidence collection + notify analyst for approval, high → immediate isolation + notify.- Human steps: approve destructive actions, validate false positives, add IOC feedback into intel feed.**Measuring & reducing MTTD/MTTR**- Metrics: MTTD, MTTR, false positive rate, playbook success rate, % automated resolution.- Reduce MTTD: improve telemetry coverage, faster enrichment, tuned SIEM rules, anomaly ML models.- Reduce MTTR: increase safe automation, standardize HITL approval workflows, runbooks versioned in CI, periodic tabletop and chaos exercises.**Operational notes**- Audit all actions, role-based access, kill-switch for automation, simulate via staging environment, CI for playbook tests, incremental rollout.
Unlock Full Question Bank
Get access to hundreds of Infrastructure Security and Compliance interview questions and detailed answers.
