Cloud Security and Compliance Questions

Focuses on designing, implementing, testing, and validating secure cloud environments across providers such as Amazon Web Services, Google Cloud Platform, and Microsoft Azure. Topics include Identity and Access Management, network security and segmentation, encryption strategies for data at rest and data in transit, secrets management, secure multi tenant design patterns, compliance frameworks and controls, common cloud misconfigurations, cloud native attack vectors, and approaches to penetration testing and security validation for cloud infrastructure and managed services. Candidates should be able to reason about secure architecture decisions, threat models, detection and response strategies, and how compliance requirements affect cloud design.

EasyTechnical

39 practiced

Describe a minimal but effective logging and monitoring strategy for cloud environments (AWS/GCP/Azure) that supports incident detection and compliance. Specify which logs to collect (control plane and data plane), retention and access controls, centralization approach (accounts/projects), and how you would protect logs from tampering.

Sample Answer

**Brief strategy summary**Collect control-plane and data-plane logs into a dedicated, locked-down logging account/project/subscription; centralize into a SIEM/Log-DB; enforce retention and RBAC; protect integrity with immutability, encryption, and validation.

**What to collect**- Control plane: AWS CloudTrail (management events + Read/Write), GCP Cloud Audit Logs (admin + data access), Azure Activity Logs & Resource Logs.- Data plane / network: VPC Flow Logs, ALB/ELB access logs, Azure NSG flow, GCP VPC flow.- Storage & app access: S3 access/object-level, GCS object access, Azure Storage logs, WAF and Firewall logs, authentication logs (CloudIdentity/Azure AD), host/syslog and container runtime logs.- Alerts/Threat intel: GuardDuty/Inspector, Security Center, Cloud IDS events piped into SIEM.

**Centralization & account/project model**- One immutable Logging Account/Project/Subscription owned by Security (not by apps); ingest via organization-level sinks and multi-account CloudTrail trails.- Forward raw logs to SIEM (Splunk/Elastic/Chronicle) and to long-term object store for audit.

**Retention & access control**- Hot index in SIEM: 90–365 days for incident response; cold archive: 7 years (or per compliance) in object storage.- Encrypt at rest with KMS/CMEK; enforce least-privilege IAM, require MFA for log access and key usage.- Access via ephemeral, audited roles; require approvals and just-in-time access where possible.

**Tamper protection**- Use write-once/immutability: S3 Object Lock (WORM)/GCS Bucket Lock/Azure immutable storage.- Enable CloudTrail log file validation; store digest hashes in separate ledger (or KMS-signed manifests) and optionally mirror logs cross-region.- Restrict log ingestion and deletion to security platform via IAM policies; alert on config changes (trail disabled, bucket policy changes) with automated guard rails.- Keep billing and log ownership separate; retain audit trail of any access to the logging account.

**Why this works**- Separation prevents lateral deletion; immutability + validation ensures integrity; SIEM + hot/cold retention balances investigations vs compliance; RBAC + encryption prevents unauthorized access.

HardTechnical

55 practiced

You are building detection rules to surface compromised identities and data exfiltration across cloud accounts. Propose a set of high-fidelity detection rules (lateral movement, privilege escalation, abnormal data transfers), list required telemetry and enrichment sources, and explain how you'd validate and iterate on these rules to reduce false positives while remaining effective against novel attack techniques.

Sample Answer

**Approach summary**I’d build a layered rule set covering lateral movement, privilege escalation, and abnormal data transfers that prioritize high-fidelity signals, context enrichment, and progressive tuning to minimize false positives while keeping novel-attack coverage.

**High-fidelity detection rules**- Lateral movement - Rule: Unusual API/service-to-service authentication from a compute instance to identity-protected management endpoints within short time window (e.g., instance A uses InstanceRole tokens to call IAM/Admin APIs). - Signal fusion: successful auth + new credential source + cross-region access.- Privilege escalation - Rule: Creation/attachment of high-privilege roles or policy changes originating from ephemeral credentials or uncommon principal (new key, service account, console session from rare IP). - Blocklist/allowlist: exclude scheduled infra automation accounts.- Abnormal data transfer / exfil - Rule: Bulk read of high-sensitivity storage (S3, Blob) followed by outbound transfer to uncommon external endpoints or to newly created storage buckets/containers in different account/region. - Thresholds adaptive to baseline per-asset/day.

**Required telemetry & enrichment**- Telemetry: Cloud audit logs (API calls), CloudTrail/Activity logs, VPC flow logs, object storage access logs, identity/session logs, KMS usage logs, host/process telemetry (EDR), DNS/Proxy logs.- Enrichment: Asset inventory, identity mapping (roles to owners), IAM policy graph, data classification tags, known-good automation schedules, geolocation/IP reputation, threat intel (C2, malicious buckets).

**Validation & iteration**- Baseline and simulated attacks: establish normal baselines per workload; run red-team/attack‑emulation (Purple Team) and use synthetic benign noise.- Metrics: precision/recall, time-to-detect, analyst triage time, false-positive rate per rule.- Tuning loop: start strict (high precision) with alerts to SOC + enrichment context; collect labeled outcomes, use feedback to adjust thresholds, add allowlists, or convert to scored detections (risk score).- Novelty resilience: implement behavioral scoring (anomaly models on identity behavior and data access patterns) and ML-assisted clustering to surface unseen tactics; keep signature rules for high-confidence IOC-based events.- Automation: automated rollback of noisy rules in sandbox, continuous deployment pipeline with canarying and alert volume gating.

This combination balances precision and coverage, leverages multi-source fusion, and provides measurable iteration to keep rules effective against evolving attack techniques.

MediumTechnical

50 practiced

Propose an automated pipeline that scans Terraform and CloudFormation changes during pull requests for security misconfigurations and blocks merges on high-risk findings. Include recommended tools, policy authorship/testing strategy, developer feedback loop, metrics to measure impact, and ways to reduce developer friction while enforcing security.

Sample Answer

**Approach (one-sentence)** Build a CI-integrated policy-as-code pipeline that scans Terraform/CloudFormation diffs on PRs, fails the merge on high-risk findings, and provides fast, actionable developer feedback.

**Recommended tools**- Terraform: terraform validate + tflint + tfsec + Checkov- CloudFormation: cfn-lint + cfn_nag + Checkov- Policy engine: Open Policy Agent (conftest) for custom policies; Sentinel where Terraform Cloud is required- CI: GitHub Actions / GitLab CI / Jenkins to run checks on PR diff- Developer UX: pre-commit hooks, VS Code extensions, and a PR bot (e.g., Danger or GitHub Actions bot) to post results

**Policy authorship & testing**- Author policies in Rego (OPA)/YAML for Checkov rules; keep modular, versioned in a security-policy repo- Unit tests with policy fixtures (conftest test harness, opa test) and canonical bad/good templates- Continuous policy CI: run tests on policy PRs, promote through environments (dev → staging → prod)- Regression suite: real infra examples + mutation testing to catch evasions

**Developer feedback loop**- Fail fast in PR with granular annotations: line-level findings, severity, remediation snippets or suggested fixes- Provide pre-commit and IDE linters so issues are visible locally- Allow a documented, auditable "temporary bypass" workflow (PR label + JIRA ticket + TTL) for true exceptions- Host office-hours and short runbooks with example fixes and policy rationales

**Metrics to measure impact**- Number of blocked PRs by severity; time-to-fix per finding- False-positive rate (developer-reported overrides)- Mean time to remediate (MTTR) for high-risk findings- Percentage of infra PRs scanned; policy coverage growth over time- Developer satisfaction (periodic survey)

**Reducing developer friction**- Start with soft enforcement: report-only for low/medium; fail-only for high-risk- Provide automated remediation suggestions (terraform fmt, sample HCL snippets)- Offer incremental rollout by team and allowlist trusted modules while policies mature- Keep policies targeted (avoid overly broad rules) and maintain a fast CI runner (parallelize, cache)- Maintain clear docs, examples, and a lightweight exception process to keep velocity while enforcing security.

EasyTechnical

47 practiced

When threat modeling a new cloud deployment, what are the top cloud-native attack vectors you would consider (for example, metadata API access, SSRF leading to credentials, misconfigured IAM roles, public storage, insecure serverless event sources)? For each vector, give a brief exploit example and one or two high-impact mitigations.

EasyTechnical

47 practiced

Compare encryption-at-rest options across AWS (EBS, S3, RDS), GCP (Persistent Disk, Cloud Storage, Cloud SQL), and Azure (Managed Disks, Blob Storage, SQL Database). Explain default behavior, the difference between provider-managed keys and customer-managed keys (CMKs), BYOK considerations, and how you would enforce encryption-by-default across an organization.

Sample Answer

**Answer (Cybersecurity Engineer perspective)**

**High-level comparison**- AWS - EBS: Can be account-default encrypted (or per-volume). Snapshots inherit encryption. Uses AWS KMS (AWS‑managed by default) or customer‑managed CMKs. - S3: Objects are stored encrypted at rest; default encryption must be enabled per-bucket (SSE‑S3 by AWS-managed keys, SSE‑KMS uses KMS, SSE‑C uses customer-provided keys). - RDS: Storage encryption is optional at creation (uses KMS). Snapshots and replicas inherit encryption.- GCP - Persistent Disk: Always encrypted at rest by Google-managed keys by default. CMEK (Cloud KMS) supported for many disk types. - Cloud Storage: Default encryption by Google-managed key; you can enforce bucket-level default keys or use CMEK/CSEK. - Cloud SQL: Default Google-managed encryption; CMEK supported for instances.- Azure - Managed Disks & Blob Storage: Encrypted at rest by platform-managed keys (PMK) by default (platform uses Azure Storage Service Encryption). Customer‑managed keys (CMK) via Azure Key Vault / Managed HSM are supported. - SQL Database: Transparent Data Encryption (TDE) enabled by default using platform keys; can use CMK in Key Vault.

**Provider-managed keys vs Customer-managed keys (CMKs)**- Provider-managed (PMK): Cloud provider fully controls key lifecycle and storage. Low operational overhead; suitable for most workloads but reduces customer control, auditability, and separation of duties.- Customer-managed keys (CMK/CMEK/CSEK): You control the key material, policies, rotation schedule, and can revoke access. Provides stronger compliance and insider‑threat controls, export restrictions, and audit trail. Requires IAM/roles and KMS configuration, and careful handling of key lifecycle and recovery.

**BYOK considerations**- Options: import raw key material into cloud KMS, generate keys in customer HSM and upload, or use external HSM with key-wrapping. Managed HSM (Cloud HSM / AWS CloudHSM / Azure Dedicated HSM) gives FIPS/HSM-backed keys.- Trade-offs: increased operational burden (rotation, backup, availability), need for secure import process, potential service limitations (some services may not support external HSM keys), and latency/DR considerations.- Compliance: proof of key origin, key destruction policies, separation of duties, and logging/attestation are required for standards (PCI, HIPAA, FedRAMP).

**How to enforce encryption-by-default across an org**- Preventative controls - AWS: Enable account-level EBS default encryption; enforce KMS key policies; use Service Control Policies (SCPs) to deny creation of unencrypted resources; S3 bucket policies & Block Public Access + require SSE. - GCP: Apply Organization Policy to require CMEK or disallow non-encrypted buckets/disks; set bucket default encryption; disable legacy APIs. - Azure: Use Azure Policy definitions to require CMK/TDE and deny unencrypted storage creation.- Detection & remediation - Automated scanning: AWS Config rules, GuardDuty/Inspector alerts; GCP Forseti / Security Command Center; Azure Security Center + policies. - Automated remediation: Lambda/Cloud Functions/Runbooks to remediate or quarantine non-compliant resources.- Processes & governance - Enforce KMS key lifecycle: rotate keys, disable old keys, key access reviews. - IAM & separation of duties: restrict who can manage keys (use least privilege). - CI/CD & IaC controls: require encryption parameters in Terraform/CloudFormation/ARM templates and scan IaC (policy-as-code). - Logging & monitoring: audit KMS usage, integrate with SIEM, periodic audits and attestations.- Metrics - Percent of volumes/buckets/databases encrypted, number of non‑compliant resources, time-to-remediate.

This approach balances security (CMK + HSM where needed), operational realities (use PMK where acceptable), and automated governance to enforce encryption by default across the organization.

Unlock Full Question Bank

Get access to hundreds of Cloud Security and Compliance interview questions and detailed answers.

Join thousands of developers preparing for their dream job.