Skip to content

Compliance

← Back to all decks

27 cards — 🟢 4 easy | 🟡 10 medium | 🔴 6 hard

🟢 Easy (4)

1. What is the difference between CIS Benchmarks Level 1 and Level 2?

Show answer Level 1 provides basic security hardening with minimal performance impact — should be applied everywhere. Level 2 adds defense-in-depth controls for high-security environments but may impact performance or usability (e.g., SELinux enforcing, auditing all privileged commands).

Remember: CIS Benchmarks = security configuration guidelines for OS, cloud, containers. Use tools like Prowler (AWS) or Scout Suite to automate CIS checks.

2. What are the levels of the compliance maturity model, from manual to codified?

Show answer Level 0: Manual (spreadsheets, screenshots). Level 1: Scripted (one-off scan scripts). Level 2: Scheduled (cron scans, emailed reports). Level 3: Pipeline (compliance checks in CI/CD). Level 4: Continuous (real-time monitoring + auto-remediation). Level 5: Codified (compliance profiles versioned in git).

Remember: compliance frameworks share common controls: access management, encryption, logging, change management, and incident response. Master these once and map to any framework.

3. What are the three STIG severity categories (CAT I, II, III), and which requires immediate action?

Show answer CAT I (High) — direct data loss or system compromise, must fix with no exceptions without formal waiver. CAT II (Medium) — potential degraded security, should fix with possible waivers. CAT III (Low) — minor security concerns, fix when practical.

Remember: compliance frameworks share common controls: access management, encryption, logging, change management, and incident response. Master these once and map to any framework.

4. What is the difference between SOC 2 Type I and Type II?

Show answer SOC 2 Type I evaluates the design of controls at a single point in time — are the right controls defined? Type II evaluates both design and operating effectiveness over a period (typically 6-12 months) — are the controls actually working consistently? Type II is far more valuable to customers because it proves sustained compliance, not just a snapshot. Most enterprise customers require Type II.

Remember: SOC 2 = Service Organization Control. Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, Privacy. Mnemonic: 'SAPCP.'

🟡 Medium (10)

1. What is OpenSCAP, and how can it generate an Ansible remediation playbook from scan results?

Show answer OpenSCAP is an open-source SCAP scanner that evaluates systems against XCCDF profiles (CIS, STIG). After scanning with "oscap xccdf eval" to produce results.xml, run "oscap xccdf generate fix --fix-type ansible --output remediate.yml results.xml" to generate an Ansible playbook that remediates the failures found.

Remember: compliance frameworks share common controls: access management, encryption, logging, change management, and incident response. Master these once and map to any framework.

2. How does Chef InSpec define compliance controls, and how is it run against a remote host?

Show answer InSpec defines controls as human-readable Ruby code with impact scores, titles, and describe blocks that test system state (e.g., sshd_config settings). Run against a remote host with: inspec exec /path/to/profile -t ssh://admin@host -i ~/.ssh/key.

Remember: compliance frameworks share common controls: access management, encryption, logging, change management, and incident response. Master these once and map to any framework.

3. How does a compliance gate work in a CI/CD pipeline?

Show answer The pipeline builds the artifact, runs a compliance scan (e.g., InSpec against a container), checks results for critical failures (impact >= 0.7 with status "failed"), blocks deployment if critical failures exist, and archives evidence artifacts with the git SHA for audit traceability.

Remember: compliance frameworks share common controls: access management, encryption, logging, change management, and incident response. Master these once and map to any framework.

4. What must automated evidence collection include to be useful to auditors?

Show answer Every evidence artifact must have a timestamp, hostname, and scan profile version. Evidence should include system configuration files (sshd_config, auditd.conf), listening ports, privileged user lists, scan results (XML and HTML), package inventories, and checksums of the evidence bundle for integrity verification.

Remember: compliance audits need evidence: logs, policies, access reviews, change records. Automate evidence collection — manual gathering is error-prone and slow.

5. How does PCI DSS scope reduction work and why is it important?

Show answer PCI DSS applies to all systems that store, process, or transmit cardholder data. Scope reduction minimizes the number of systems subject to PCI controls by: using tokenization (replace card numbers with tokens), network segmentation (isolate the cardholder data environment), and outsourcing payment processing (e.g., Stripe handles cards, you never see them). Fewer in-scope systems means less audit surface, lower cost, and reduced risk.

Remember: PCI DSS = Payment Card Industry Data Security Standard. 12 requirements for handling cardholder data. Applies if you store, process, or transmit card data.

6. What are the key HIPAA technical safeguards for protected health information (PHI)?

Show answer Access control: unique user IDs, role-based access, automatic logoff, encryption at rest.
Audit controls: log all access to PHI with who, what, when.
Integrity controls: verify PHI is not altered or destroyed improperly.
Transmission security: encrypt PHI in transit (TLS for networks, encrypted email).
HIPAA does not mandate specific technologies but requires documenting why your chosen controls are reasonable and appropriate for your risk level.

Remember: HIPAA = Health Insurance Portability and Accountability Act. Protects PHI (Protected Health Information). Fines up to $1.9M per violation category per year.

7. How often should access reviews be conducted and what should they cover?

Show answer Quarterly for privileged access (admin, root, database), semi-annually for standard access. Review: who has access, whether they still need it (role changes, departures), whether access level matches job function (principle of least privilege). Automated tools (Okta, SailPoint) flag dormant accounts and excessive privileges. Document review completion and any access revoked — auditors check these records specifically.

Remember: compliance frameworks share common controls: access management, encryption, logging, change management, and incident response. Master these once and map to any framework.

8. How do you automate evidence collection for compliance audits?

Show answer Use InSpec or OpenSCAP to generate machine-readable scan reports on schedule. Archive scan results, system configs, and access logs to immutable storage (S3 with object lock, or WORM-compliant storage). Tag each artifact with timestamp, hostname, profile version, and git SHA. Build a CI pipeline that runs compliance scans after each deployment and stores evidence automatically. This turns audit preparation from a weeks-long scramble into a query against stored evidence.

Remember: compliance audits need evidence: logs, policies, access reviews, change records. Automate evidence collection — manual gathering is error-prone and slow.

9. What is the difference between a compliance audit and a security audit?

Show answer A compliance audit checks adherence to specific regulatory requirements (SOC2, PCI-DSS, HIPAA). A security audit evaluates the overall security posture and may go beyond regulatory requirements.

Remember: compliance audits need evidence: logs, policies, access reviews, change records. Automate evidence collection — manual gathering is error-prone and slow.

10. Why is immutable audit logging a compliance requirement in most frameworks?

Show answer Immutable logs ensure that evidence of who did what and when cannot be tampered with, which is required for investigation, non-repudiation, and regulatory evidence.

Remember: compliance audits need evidence: logs, policies, access reviews, change records. Automate evidence collection — manual gathering is error-prone and slow.

🔴 Hard (6)

1. Why is scanning only at build time insufficient for compliance, and what should you do instead?

Show answer Build-time scanning validates the golden image, but production systems drift from that image over time (manual changes, config management failures, package updates). You must run compliance scans continuously in production, not just in CI, to detect drift and either alert or auto-remediate.

Remember: compliance frameworks share common controls: access management, encryption, logging, change management, and incident response. Master these once and map to any framework.

2. Why can blindly auto-remediating all STIG findings be dangerous?

Show answer Some STIG controls may conflict with application requirements — for example, enforcing strict password policies on service accounts or disabling network features that the application depends on. Auto-remediation should be tested in staging first. Some controls require understanding the application context before applying.

Remember: compliance frameworks share common controls: access management, encryption, logging, change management, and incident response. Master these once and map to any framework.

3. Why should CAT III STIG findings not be ignored even though they are individually minor?

Show answer Individually, CAT III findings are low-severity. But 50 unfixed CAT III findings signal systemic neglect to an auditor, suggesting the organization does not take compliance seriously. Best practice is to fix the easy ones and formally document exceptions for the rest with justification.

Remember: compliance frameworks share common controls: access management, encryption, logging, change management, and incident response. Master these once and map to any framework.

4. What must an audit log capture to satisfy compliance frameworks like SOC 2 and PCI DSS?

Show answer Every log entry must include: who (authenticated user identity), what (action performed — read, write, delete, login, privilege change), when (timestamp with timezone, preferably UTC), where (source IP, system hostname), and outcome (success or failure). Logs must be tamper-evident (write-once storage or signed), retained for the required period (PCI: 1 year, 3 months immediately accessible; SOC 2: varies), and centralized for analysis.

Remember: audit log = 'who did what, when, and from where.' The four W's: Who, What, When, Where.

Example: '2026-03-21T14:30:00Z user=admin action=delete resource=pod/nginx namespace=production source_ip=10.0.0.5'

5. What are typical vulnerability scanning SLAs and how do they map to severity?

Show answer Critical (CVSS 9.0-10.0): remediate within 24-48 hours, exploit likely in the wild.
High (CVSS 7.0-8.9): remediate within 7-14 days.
Medium (CVSS 4.0-6.9): remediate within 30-90 days.
Low (CVSS 0.1-3.9): remediate within 180 days or accept risk.
Scan frequency: weekly for external-facing systems, monthly for internal. PCI DSS requires quarterly external scans by an ASV (Approved Scanning Vendor). Track scan-to-remediation metrics to prove compliance posture is improving.

Remember: compliance frameworks share common controls: access management, encryption, logging, change management, and incident response. Master these once and map to any framework.

6. How does infrastructure-as-code support compliance objectives?

Show answer IaC provides auditable, version-controlled infrastructure definitions. Changes are reviewed via PR, drift is detectable, and the desired state is reproducible — all supporting compliance evidence requirements.

Remember: compliance frameworks share common controls: access management, encryption, logging, change management, and incident response. Master these once and map to any framework.