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

43 practiced

Explain the role of cloud provider audit logs (AWS CloudTrail, Azure Activity Log, GCP Audit Logs) in security and penetration testing. Which events are essential to collect for detection and forensics (management plane, data plane, authentication), what retention would you recommend, and which logs should a penetration tester validate during an assessment?

HardTechnical

52 practiced

Perform threat modeling for a multi-region, active-active cloud application that uses cross-region replication for databases and object storage. Identify top threats introduced by replication and cross-region trust (for example: misconfigured replication permissions, key compromise, data-leak during transit), enumerate attack surfaces, and prioritize mitigations by impact and likelihood.

Sample Answer

**Scope & assumptions**Multi-region, active‑active cloud app with cross-region DB and object replication, IAM roles/service principals for replication, KMS or cloud‑managed keys, TLS for transit.

**Top threats (by category)**- Misconfigured replication permissions — overly broad IAM roles allow unauthorized write/overwrite (High impact / Medium likelihood) - Key compromise or improper key usage — cross‑region key replication or key material stored insecurely (High / Low‑Medium) - Data leakage in transit — weak TLS, protocol downgrade, or replication over untrusted networks (High / Low) - Replay or roll‑back attacks — attacker injects old/poisoned replication data (Medium / Medium) - Replication configuration tampering — attacker reconfigures target to exfiltrate data (High / Medium) - Inconsistent RBAC & trust boundaries — trust relationships abused between accounts/regions (High / High) - Insecure metadata or object ACLs carried across regions (Medium / High)

**Attack surfaces**- IAM roles, service accounts, and cross‑account trust policies used by replication agents - KMS/API keys, key rotation pipelines, HSM endpoints accessible cross‑region - Replication endpoints, ports, and management APIs (control plane) - Message queues or CDC streams used for DB replication - Object storage replication configuration, bucket policies, ACLs, signed URLs - CI/CD and automation that provisions replication (IaC templates, pipelines) - Logging/monitoring exposed to other regions or not centrally protected

**Prioritized mitigations (impact x likelihood)**1. High impact / High likelihood - Enforce least‑privilege IAM: scoped roles, conditional policies (region, source IP, VPC) and deny wildcards. Implement access reviews. - Harden cross‑account trust: require external ID, limited assume-role windows, MFA for sensitive actions.2. High impact / Medium - KMS best practices: use region‑specific keys, no cross‑region key material replication, HSM-backed keys, strict key usage policies, automated rotation and key access logging. - Signed, TLS 1.2+ with mutual TLS for replication channels; reject weak ciphers and enforce endpoint authentication.3. Medium impact / Medium‑High - Integrity checks and sequence/versioning: use cryptographic signatures, checksums, and anti‑rollback/version guards for replicated data. - Immutable backups and WORM for critical datasets to recover from poisoned replication.4. Medium / Low - Harden CI/CD and IaC: scan templates for overly permissive replication resources; require approvals for cross‑region replication changes. - Centralized, protected logging/alerting with cross‑region access controls and anomaly detection for replication config changes.

**Pentester validation checks**- IAM policy analysis: search for broad AssumeRole or s3:* allow across regions. - Attempt privilege escalation via cross‑region role chaining and external ID bypass tests. - Test KMS misuse: access key material, call Decrypt with cross‑region keys, check key policy exposures. - Intercept replication streams (where permitted), test TLS downgrade, replay replication payloads to detect integrity protections. - Review IaC and pipeline artifacts for secrets, hardcoded ARNs, or permissive replication flags. - Verify logging, alerting, and incident response by simulating config tamper and observing detection/rollback.

**Risk trade‑offs / notes**- Cross‑region replication increases availability but widens blast radius: prioritize strong auth, key separation, and integrity verification. - Short term tests: IAM and key exposure yield highest risk and are most fruitful for pentest findings.

HardTechnical

42 practiced

Analyze side-channel risks in multi-tenant cloud environments such as CPU cache timing or speculative-execution attacks (e.g., Spectre/Meltdown style vectors) and noisy-neighbor leakage. How would you test for observable side-channel leakage in a cloud tenant, and what architectural and provider-level mitigations (e.g., dedicated hosts, confidential computing) would you recommend for high-security workloads?

Sample Answer

**Situation & scope** As a penetration tester I treat multi-tenant cloud side-channels as an information-leakage class: CPU cache timing, branch-speculative (Spectre-class), microarchitectural buffers, and noisy‑neighbor resource telemetry that allows inference of tenant activity.

**How I'd test for observable leakage** - Recon: enumerate instance type, vCPU placement, hypervisor (cloud metadata leaks). - Co-residency checks: use known probes (network latency, cache-occupancy tests) to confirm tenancy. - Microarchitectural probes: implement Flush+Reload, Prime+Probe, Evict+Time experiments from a guest VM to measure timing differences; collect statistical traces and apply correlation/classification to target victim activity. - Speculative-exec tests: run proof-of-concept Spectre/Meltdown variants adapted to cloud constraints; measure success via side-channel exfiltration (cache or timing). - Noisy-neighbor: generate load patterns and try to infer workload via shared resource metrics (disk I/O, CPU-steal, performance counters if exposed). - Validation: repeat across instance types and AZs, use controlled victim processes to quantify bit rate, ROC curves, and false-positive rates.

**Mitigations — architectural & provider-level** - Tenant-level: avoid co-residency for high-security workloads (use dedicated hosts or bare-metal instances), enable strict CPU pinning and cgroup isolation, disable SMT/Hyper-Threading for sensitive VMs, use constant-time crypto libraries, reduce shared kernel attack surface (harden guest OS). - Provider-level: microcode/firmware + hypervisor patches (retpoline, IBRS, L1TF fixes), strong scheduler isolation, page-table isolation (KPTI), and disabling user-accessible PMCs to guests. - Confidential computing: use TEEs (AMD SEV, Intel TDX, or SGX where available) with remote attestation to protect in-memory secrets against host/hypervisor. Prefer providers that offer attestation chains and measured boot. - Networking/storage: encrypt data-in-motion and at-rest; minimize shared caches for cryptographic ops by allocating dedicated caches or memory-affinity. - Operational: continuous monitoring for anomalous timing patterns, strict telemetry access controls, regular penetration testing and threat modeling.

**Trade-offs & recommendations** - For highest assurance use dedicated hosts + confidential computing with attestation; accept cost/perf trade-offs. For moderate risk, use tenant isolation, SMT off, patched stacks, and aggressive monitoring. Document residual risk and measurable leakage rates for stakeholders.

EasyTechnical

52 practiced

List and explain three common multi-tenant isolation patterns used in cloud environments (for example: account-per-tenant, VPC-per-tenant, namespace-per-tenant). For each pattern describe the security trade-offs, operational overhead, and scenarios (including compliance) where you would choose one pattern over another.

Sample Answer

**Account-per-tenant (cloud account / subscription per customer)**

- What it is: Each tenant gets a separate cloud account (AWS Account, Azure Subscription, GCP Project) with dedicated IAM, billing and boundaries.- Security trade-offs: Strongest isolation and smallest blast radius; reduces risk of cross-tenant resource leakage and control-plane misconfigurations. Still requires secure org-level controls (SCPs, org policies) to avoid risky admin mistakes.- Operational overhead: High — provisioning, separate billing, duplicated infra templates, cross-account observability and patching complexity.- When to choose: Regulated or high-risk tenants (PCI, HIPAA, FedRAMP), customers demanding legal separation, or high-value targets. From a pentester view: fewer lateral pivot paths; focus is testing account-specific IAM misconfig and perimeter controls.

**VPC-per-tenant (network-segmented per customer within same account)**

- What it is: Each tenant gets an isolated virtual network (VPC/VNet) with separate subnets, route tables, security groups and optionally dedicated NAT/edge devices.- Security trade-offs: Good network isolation; shared control plane/management services remain potential escalation vectors. Misconfigured peering, transit gateways, or shared IAM roles can enable cross-tenant pivoting.- Operational overhead: Medium — networking setup, centralized services (logging, shared DBs) must be securely brokered; more scalable than accounts but needs disciplined network automation.- When to choose: Multi-tenant SaaS needing network segregation without full account sprawl; useful when tenants require private networking (PCI segments) but not full legal separation. Pentest focus: try to abuse peering, misconfigured route tables, shared gateways, or roles.

**Namespace-per-tenant (Kubernetes/tenant namespaces, single cluster, shared control plane)**

- What it is: Tenants isolated by namespaces with RBAC, network policies, resource quotas within the same cluster and control plane.- Security trade-offs: Lowest isolation — shared control plane, container runtime, kernel and underlying nodes are common attack surface. Risk of container escape, misconfigured cluster roles, admission controls bypass.- Operational overhead: Low — very scalable and cost efficient; easier centralized monitoring and CI/CD. Requires strong controls: PodSecurityPolicies/PSA, network policies, node isolation, image scanning.- When to choose: Large number of low-risk tenants, dev/test environments, or cost-sensitive SaaS where speed trumps maximal isolation. For pentesters: focus on privilege escalation from namespace to cluster-admin, API server misconfigs, admission webhook bypass, and node/container escapes.

Summary guidance for a penetration tester: map expected attack paths and blast radius for each pattern, prioritize control-plane and shared-service controls (accounts → minimal; VPC → network services; namespaces → kernel/cluster). Recommend tests: IAM/role chaining, network pivoting, cross-namespace access, container escape proofs, and misconfigured shared services in all patterns.

EasyTechnical

73 practiced

You are reviewing an S3 bucket policy and must find security issues. Identify the problems in this policy and propose remediation steps (policy changes, bucket settings, monitoring):

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::example-bucket/*"
    }
  ]
}

Explain what an attacker can do and list at least three concrete fixes and detection mechanisms.

Sample Answer

**Summary of problems (what I see)**- Policy allows Principal = "*" with Effect = "Allow" and Action = "s3:*" on arn:aws:s3:::example-bucket/* — full public access to all bucket objects. - No resource restriction for bucket-level actions (create/delete bucket ACLs, etc.) or conditions (encryption, source IP, VPC). - No deny statements to protect against ACLs or cross-account escalation.

**What an attacker can do**- List and download all objects (data exfiltration). - Upload malicious content or ransomware, overwrite or delete objects (data integrity/destruction). - Change ACLs or object metadata to expose further data, host malware or phishing sites via static website hosting. - Pivot using leaked credentials or stored secrets to access other resources.

**Concrete fixes (policy + bucket settings)**1. Principle of least privilege: replace "*" with specific IAM principals/roles and restrict Actions to only needed (e.g., "s3:GetObject" for read-only). 2. Block public access: enable S3 Block Public Access at account and bucket level; remove public ACLs and policies. 3. Add safe Deny conditions: explicit Deny for s3:PutObject unless server-side encryption present and deny if request not from allowed VPC endpoints/IPs. Example condition: require "aws:SourceIp" or "aws:VpcSourceIp" and "s3:x-amz-server-side-encryption". 4. Enable versioning + MFA Delete to prevent silent destructive deletes and allow recovery.

**Detection & monitoring**- Enable CloudTrail data events for S3 and create CloudWatch Alarms on high-volume GetObject/PutObject/Delete patterns. - Enable S3 server access logs and send to a centralized logging bucket. - Use AWS Config rules (s3-bucket-public-read-prohibited, s3-bucket-public-write-prohibited) and trigger automated remediation (Lambda). - Enable GuardDuty and Amazon Macie to detect unusual data access, exfiltration patterns, or sensitive data exposure. - Alert on policy changes to the bucket (CloudTrail EventName = PutBucketPolicy / PutBucketAcl).

As a penetration tester I'd demonstrate impact by enumerating objects (read), attempting write/delete, and verifying detection (trigger events) — then provide PoC logs and recommended policy JSON snippets implementing least privilege and denies.

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.