Compliance Automation and Tooling Questions
Using technology to scale and continuously enforce compliance and privacy. Covers GRC platforms, compliance-as-code, continuous control monitoring, automated evidence collection, and integrating compliance and privacy checks into engineering pipelines. Focuses on how tooling reduces manual effort and enables continuous rather than point-in-time assurance.
MediumTechnical
39 practiced
How would you implement least privilege for Kubernetes service accounts using RBAC and OPA Gatekeeper? Describe how to design roles, bind them safely, write admission control policies to prevent privilege escalation, and a rollout plan to retrofit an existing cluster with minimal disruption.
Sample Answer
Approach (brief): apply least privilege by designing narrow Roles (namespaced) / ClusterRoles only when needed, avoid wildcard verbs/resources, bind to specific ServiceAccounts, and enforce via OPA Gatekeeper admission policies that (a) block privilege escalation patterns and (b) audit existing bindings before enforcing. Rollout incrementally with discovery, audit, remediation, and gradual enforcement.Example Role and safe binding:Key design principles:- Principle of least privilege: only required verbs/resources and minimal scope (namespace vs cluster).- Prefer Roles over ClusterRoles unless cross-namespace or cluster-wide required.- Use dedicated ServiceAccounts per component, avoid reusing default SA.- Set automountServiceAccountToken: false for pods that don’t need it.- Use namespacing and naming conventions (svc-<app>-sa) to track ownership.Gatekeeper / OPA policies (examples):- Deny Role/ClusterRole rules with "*" verbs/resources.- Deny RoleBinding/ClusterRoleBinding that bind ClusterRole "cluster-admin" or wildcard subjects.- Prevent creation of RoleBindings that elevate namespace SAs to cluster-wide roles.- Ensure automountServiceAccountToken is false for pods without RBAC needs.Sample Rego constraint (deny wildcard permissions & cluster-admin bindings):Gatekeeper setup: create ConstraintTemplate wrapping above Rego and a Constraint that targets Role/ClusterRoleBinding. Start with enforcementAction: dryrun (audit) then deny.Prevent privilege escalation patterns to catch:- RoleBindings that reference ClusterRoles (binding namespace SA to cluster role).- ClusterRoleBindings to service accounts in namespaces (unless approved).- Roles with escalation verbs (bind, impersonate, create clusterroles).- Use policy to deny verbs: "bind", "escalate", "impersonate" on sensitive resources.Rollout plan (minimal disruption):1. Discovery (1–2 weeks) - Audit current RBAC: list Roles/ClusterRoles, RoleBindings/ClusterRoleBindings, and ServiceAccounts. Map which SAs are used by pods. - Run risk scoring: identify high-risk bindings (cluster-admin, wildcards, impersonate/bind verbs). - Use kube-rbac-proxy or custom scripts to produce dependency maps.2. Audit phase with Gatekeeper dry-run (2 weeks) - Deploy Gatekeeper with constraints in dryrun to collect violations. - Notify owners (via labels/annotations recorded in audit) and create tickets for remediation.3. Remediation & least-privilege design (2–4 weeks, iterative) - For each app, define required actions and create narrow Roles. - Replace broad bindings: create new Roles/RoleBindings, update pod specs to use dedicated SAs. - Use feature flags / rollout windows for teams; allow exceptions with timeboxed approval via an exception CRD.4. Enforcement (gradual) - Flip constraints from dryrun to deny for low-risk/green areas (non-prod namespaces first). - Monitor audit logs, kube-apiserver denies, and app behavior. - Progress to production namespaces after verification.5. Harden defaults & automation - Enforce automountServiceAccountToken: false via PodSecurityPolicy/PodSecurity admission (or Gatekeeper). - Add CI checks: prevent merging manifests that create wildcard RBAC or cluster-admin bindings. - Periodic audits and alerting for new violations.Rollback & safety:- Start in dry-run; use short windows for converting to deny and have runbooks to revert constraints.- Keep emergency 'rbac-exception' process: a short-lived ClusterRoleBinding allowed by Ops with strict TTL and audit.- Use feature flags and health probes: if denials cause failures, temporarily allow the binding and create remediation ticket.Monitoring & SLOs:- Track number of denied admissions, number of wildcard/broad bindings, time-to-remediate violations.- Alert if a new cluster-admin binding is created.- Incorporate in incident runbooks to check RBAC denials when pods fail to start or API calls fail.Why this works:- Narrow roles and scoped bindings reduce blast radius.- Gatekeeper provides centralized, auditable policy enforcement and a safe dry-run path.- Incremental rollout with discovery and owner involvement minimizes disruption while raising cluster security posture.
yaml
# namespaced role granting only read access to ConfigMaps
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: configmap-reader
namespace: payments
rules:
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["get","list","watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: payments-cm-reader-binding
namespace: payments
subjects:
- kind: ServiceAccount
name: payments-sa
roleRef:
kind: Role
name: configmap-reader
apiGroup: rbac.authorization.k8s.iorego
package rbac.restrictions
deny[msg] {
input.review.kind.kind == "Role"
some i
r := input.review.object.rules[i]
any_wildcard(r)
msg := sprintf("Role %v contains wildcard verbs/resources", [input.review.object.metadata.name])
}
any_wildcard(r) {
r.verbs[_] == "*"
}
any_wildcard(r) {
r.resources[_] == "*"
}
deny[msg] {
input.review.kind.kind == "ClusterRoleBinding"
input.review.object.roleRef.name == "cluster-admin"
msg := "Binding to cluster-admin is forbidden"
}MediumSystem Design
39 practiced
Design an audit logging and retention architecture that provides tamper evidence, supports long term retention for compliance, and enables forensic search across multiple clouds. Describe storage tiers, indexing strategy, access controls, cost management, and how you would prove logs were not altered.
Sample Answer
Requirements & constraints:- Immutable, tamper-evident logs; retention 7–10+ years for compliance; searchable across AWS/GCP/Azure; cost-aware; auditable proof of integrity.High-level architecture:- Agents (Fluentd/Vector) ship logs to regional ingestion queuing (Kafka/Kinesis). Streams fan-out to (1) hot indexing, (2) cold archive, (3) integrity service.Storage tiers:- Hot: Elastic/OpenSearch cluster (or managed: OpenSearch Service) for 30–90 days — low latency search for ops/forensics.- Warm: Columnar store / query warehouse (BigQuery, Athena over parquet on S3/GCS) for 90–365 days — cheaper, analytical queries.- Cold/Archive: WORM object storage with legal hold (S3 Object Lock/GCS Vault/Azure Immutable Blob) in compressed, partitioned Parquet, lifecycle to colder classes and deep archive for years.Indexing strategy:- Ingest -> minimal enrichment (timestamp normalization, source, tenant, event_type, unique id, retention tag).- Hot index stores full text + structured fields. Periodic rollup/parquet export with partition keys (date, tenant, product) and Bloom filters to speed scans.- Maintain a lightweight global metadata catalog (Elasticsearch or Cloud Data Catalog) with pointers to archived partitions for federated search.Access controls & audit:- Principle of least privilege via IAM, RBAC for clusters and object stores.- Use signed URLs for retrieval, ephemeral access (short-lived tokens).- Multi-party approval for forensic export (two-person authorization) logged to immutable audit trail.- KMS-managed keys per region; rotate keys per policy. HSM-backed signing for integrity proofs.Tamper-evidence & proving non-alteration:- On ingestion, compute SHA-256 of each event. Store signature = Sign_HSM(previous_signature || current_hash || timestamp) forming a hash-chain (Merkle/linked list) per stream.- Periodically (hourly/daily) compute a Merkle root of that window and publish the root to: - timestamping service (RFC 3161) or - public append-only ledger (e.g., anchoring root to a blockchain or public S3 with public checksum) for external notarization.- Store signatures and roots in immutable store (WORM) and mirror to separate cloud provider to prevent single-cloud compromise.- For verification: re-hash retrieved data, recompute chain/Merkle proofs, verify HSM signatures and compare anchor published externally.Cost management:- Short retention in hot index, aggressive rollover to parquet + cold storage.- Use compression, columnar formats, partition pruning, lifecycle policies to deep archive.- Use spot instances for batch backfills, autoscale search clusters with index sharding tuned to query patterns.- Retention-tier quotas per team/tenant; alert when approaching quotas.Operational considerations & SLAs:- Monitor integrity pipeline (missing signatures, chain breaks) with high-severity alerts.- Regular audit drills: verify random partitions end-to-end and provide proof to auditors.- Trade-offs: immediate full-text searchable retention is costly; balanced by hot/warm/cold split and federated search pointers.This design provides immutable storage, cryptographic tamper-evidence with external anchoring, cost-effective long-term retention, and a searchable multi-cloud forensics capability.
EasyTechnical
54 practiced
Explain how service level objectives and error budgets interact with security and compliance work. Provide examples where strict security controls could consume error budget or slow releases and describe how SREs should make trade off decisions between safety and velocity.
Sample Answer
SLOs define the target level of user-facing reliability (e.g., 99.95% availability) and the error budget is the tolerated fraction of failure (e.g., 0.05%). Security and compliance work—patching, vulnerability scans, access changes, encryption rollouts—can both consume error budget (by causing outages or increased latency) and reduce release velocity (through mandatory reviews, freeze windows, or risky mitigations).Examples:- A mandatory emergency kernel patch requires restarts across clusters. If restarts cause 0.2% downtime, that directly burns error budget and could push the service past its SLO.- Enforcing strict RBAC and deployment approvals adds lead time; teams may batch changes, increasing blast radius and longer deployment windows, slowing feature delivery.- Enabling strict WAF rules may cause false positives that increase error rates.How SREs should make trade-offs:- Quantify impact: estimate downtime/latency and map to error-budget burn rate. Use historical data to predict risk.- Prioritize by risk and SLO posture: if error budget is healthy, accept higher short-term burn to close critical vulnerabilities. If budget is nearly exhausted, prefer mitigations with lower user-impact (e.g., staged rollouts, feature flags, compensating controls).- Reduce blast radius: use canary deployments, circuit breakers, and automated rollback to limit user impact of security changes.- Schedule with context: align non-urgent security work to periods where error budget is ample or during maintenance windows agreed with stakeholders.- Use policy automation: encode deployment gates that adapt to current burn rate (e.g., stricter approvals when burn rate is high).- Communicate and document trade-offs: pair with product and compliance owners to accept residual risk explicitly, and record decisions in runbooks.Principle: security is non-negotiable long-term, but tactically choose low-impact paths (automation, staged rollout) when reliability is constrained; when threat severity warrants, prioritize safety even at cost of velocity, documenting rationale and remediation plans.
HardTechnical
45 practiced
Given a stream of thousands of vulnerability findings daily from multiple scanners, design an automated prioritization algorithm for SRE teams. Explain inputs such as CVSS, exploit maturity, asset criticality, public exposure, compensating controls, and how automation should triage, schedule patch windows, and escalate critical findings.
Sample Answer
Requirements & constraints:- Ingest thousands of scanner findings/day from different tools; deduplicate and normalize.- Prioritize to minimize operational risk while respecting SRE availability/SLOs.- Automate triage, scheduling, and escalation.High-level approach:1. Normalize & dedupe: Map findings to canonical vulnerability IDs (CVE), canonical asset identifiers, and dedupe using fingerprinting (CVE + package + version + asset).2. Enrich: Add CVSS v3 score/vector, exploit maturity (0:none,1:PoC,2:weaponized), public exposure (0:internal,1:VPC reachable,2:internet-facing), asset criticality (0:low,1:medium,2:high based on SLO/owner), compensating controls (0:none, -0.5 if WAF/segmentation/IAM mitigates), business context tags, patch availability and risk.3. Risk scoring formula (weighted additive, normalized 0–100): Risk = w1*CVSS_norm + w2*ExploitMaturity + w3*Exposure + w4*AssetCriticality + w5*CompControlAdjustment + w6*Age/Window Example weights: w1=0.35, w2=0.20, w3=0.20, w4=0.15, w5=0.10. CompControlAdjustment subtracts up to 20 points.Automation workflow:- Real-time Tiering: Map score -> tier (P0:90-100, P1:70-89, P2:40-69, P3:<40).- Automated ticketing: Create/annotate tickets in issue tracker with remediation playbook, rollback steps, estimated blast radius.- Patch window scheduling: For P0/P1, auto-propose earliest maintenance window from asset owner calendars and SRE on-call availability; P0 requires immediate page + 2-hour SLA; P1 scheduled within 48-72 hours with risk-approved window; P2 batched into weekly maintenance; P3 monthly sweep.- Safe deploy practices: Attach canary & rollback steps, automated smoke tests, and automated pre/post-checks; use feature flags or traffic steering if needed.- Escalation: If exploit observed in wild and patch not applied by SLA, auto-page escalation chain, open incident bridge, freeze deployments to affected services.- Feedback loop: Post-remediation verification via rescans, update confidence; continuous learning adjusts weights (ML or rules) based on false positives and incident outcomes.Example: Internet-facing service (exposure=2), CVSS 9.1 (norm≈0.91), exploit weaponized (2), asset criticality high (2), no compensating controls (0) -> Risk ~ 0.35*91 + 0.2*100 + 0.2*100 +0.15*100 = ~91 -> P0, immediate page and emergency patch window.Operational considerations:- Human-in-loop for irreversible actions.- Audit trail, RBAC, and change approvals.- Allow overrides by owners with justification.- Monitor metric: time-to-remediate by tier, escapes, and patch success rate.
EasyTechnical
41 practiced
Provide a practical summary of how GDPR, HIPAA, PCI DSS, SOC2, and ISO 27001 differ in their expectations for infrastructure controls. For each framework give one example control SREs must implement and explain briefly how it influences architecture or operations.
Sample Answer
GDPR — Focus: data privacy and protection of personal data. Example control: Data-at-rest encryption and strict key management for databases holding personal data. Influence: Requires architecture to use encrypted storage (KMS-integrated), limit who/what can decrypt (IAM, service accounts), and include key rotation—adds operational tasks for key lifecycle, backups, and access audits.HIPAA — Focus: protecting electronic protected health information (ePHI). Example control: Network segmentation and least-privilege access for systems processing ePHI. Influence: Drives separating PHI-processing services into isolated VPCs/subnets, stricter firewall rules, and dedicated audit logging; SREs implement controlled bastion hosts, MFA, and tighter deployment pipelines for those zones.PCI DSS — Focus: cardholder data security. Example control: Strong access controls + multi-factor authentication for any admin access to cardholder-data environments. Influence: Forces hardened jump hosts, MFA on all consoles, session recording, and reduced attack surface (no shared accounts), affecting CI/CD and on-call procedures.SOC 2 — Focus: trust services (security, availability, confidentiality, processing integrity, privacy) with emphasis on controls and evidence. Example control: Centralized logging and monitoring with retention and alerting for security/availability events. Influence: Requires deploying aggregated log pipelines (SIEM), defined SLOs, automated alerts, and runbooks—SREs must instrument services and produce evidence for audits.ISO 27001 — Focus: an ISMS (management process) with risk-driven controls. Example control: Configuration management and change control for infrastructure (documented baselines). Influence: Requires infrastructure-as-code, versioned configs, change approvals, and rollback plans—operational discipline that shapes deployment workflows and auditability.Across all: SREs implement automation, strong IAM, observability, and documented processes—but each framework prioritizes different controls (privacy, health data, payment, trust evidence, or risk management), which changes segmentation, logging, access, and operational cadence.
Unlock Full Question Bank
Get access to hundreds of Compliance Automation and Tooling interview questions and detailed answers.
Sign in to ContinueJoin thousands of developers preparing for their dream job.