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
53 practiced
Explain the shared responsibility model for cloud security. For AWS, Azure, or GCP outline which security controls are typically the cloud provider's responsibility versus the customer's responsibility across compute, networking, storage, data, and operational security. Provide examples of common misaligned expectations that lead to security gaps during migrations.
Sample Answer
**Brief definition**The shared responsibility model splits cloud security: the provider secures the cloud infrastructure and foundational services; the customer secures what they run in the cloud (OS, apps, data, configs, identity).**Responsibility by domain (AWS/Azure/GCP examples)**- Compute - Provider: physical hosts, hypervisor, underlying virtualization, managed service control plane (e.g., AWS EC2 hypervisor, Azure App Service control plane). - Customer: guest OS patching, runtime configuration, application vulnerabilities, container image security (e.g., patch EC2 AMIs, secure containers on GKE).- Networking - Provider: physical network, isolation primitives, managed networking services (VPC, Virtual Network backbone). - Customer: network ACLs, security groups, route tables, VPN/peering config, subnet segmentation, WAF rules (configure VPC Security Groups, NSGs in Azure).- Storage - Provider: durable storage systems, availability, encryption-at-rest options. - Customer: access controls, object ACLs, lifecycle rules, client-side encryption keys, correct bucket/container policies (e.g., S3 bucket policy, Azure Blob access tiers).- Data - Provider: storage durability, optional managed DB control plane. - Customer: data classification, encryption keys (KMS usage vs customer-managed keys), backups, data masking, query-level access controls.- Operational/security tooling - Provider: basic identity provider, IAM framework, native logging/audit services (CloudTrail, Azure Monitor, Cloud Audit Logs), physical security, CSP-managed patching for managed services. - Customer: IAM least privilege, log monitoring/alerting, SIEM integration, incident response, patching for non-managed services, configuration hardening.**Common misaligned expectations causing gaps**- Assuming provider patches guest OS (leads to unpatched EC2 instances).- Believing storage is automatically private (public S3 buckets exposed).- Treating IAM roles as secure by default—overly broad permissions.- Expecting provider to detect app-layer vulnerabilities (no runtime WAF rules).- Misunderstanding KMS ownership (customer must rotate/manage CMKs if required by policy).Being explicit during migration—document which service is managed and verify controls (patching, backups, encryption, logging, IAM)—prevents most gaps.
HardTechnical
46 practiced
Serverless functions often rely on third-party libraries and CI/CD pipelines. Describe a comprehensive approach to secure the serverless supply chain: dependency vetting and SBOMs, artifact signing and attestation, private registries with immutability, CI runner hardening, vulnerability scanning, and runtime protections that validate provenance before execution.
Sample Answer
**Approach overview (goal: prevent compromised code/artifacts from reaching runtime)****1) Dependency vetting & SBOMs**- Enforce vetted dependency lists (allowlists) and periodic pruning.- Generate SBOMs for every build in CycloneDX/SPDX formats using tools like Syft; store SBOMs in the artifact repo alongside builds.- Enforce policy: reject builds with unknown/unvetted transitive deps.**2) Artifact signing & attestation**- Sign build artifacts and container/function packages with Sigstore/Cosign or cloud KMS-backed keys; produce attestation metadata (e.g., provenance, builder-id, CI job).- Use in-toto or Sigstore Rekor for immutable transparency logs.**3) Private registries + immutability**- Host artifacts in private registries (ECR/GCR/ACR) with repo-level IAM, encryption-at-rest, and image tag immutability + retention locking to prevent tampering/rollback.- Require immutability and content-addressable references (digest) in deployment manifests.**4) CI runner hardening**- Run CI in ephemeral, isolated runners (GKE/GCF ephemeral, GitHub Actions self-hosted in isolated VPCs), with minimal privileges, network egress controls, signed runner images, and no long-lived credentials.- Use short-lived service accounts via OIDC, enforce least privilege, and inject secrets via vaults (AWS Secrets Manager/HashiCorp Vault) with audit logging.**5) Vulnerability scanning & policy gates**- Integrate SCA and image scanning (Trivy/Snyk/Clair) into CI; fail builds on high/critical findings or unpatched critical transitive deps.- Use policy engine (OPA/Gatekeeper or Sigstore policies) to enforce SBOM/attestation/scan requirements before promotion.**6) Runtime provenance validation**- At deployment and at runtime, verify signatures/attestations against trusted root keys and Rekor entries; deploy only digest-referenced artifacts that pass verification.- For serverless (Lambda, Cloud Run), use platform-native features: Lambda layers signed, ECR image policies, GCP Binary Authorization / Artifact Analysis.- Implement runtime controls: allowlisting via runtime policy agents (OPA), ephemeral identity for functions, strict IAM and network egress, and runtime monitoring (Falco, AWS GuardDuty) to detect anomalous behavior.**Trade-offs & metrics**- Trade-off: increased build latency and operational overhead vs. reduced breach risk.- Measure: mean time to detect/approve new dependency, percent of deployments with verified attestations, number of blocked vulnerable builds, and time-to-recovery.This end-to-end model ensures artifacts are traced, signed, scanned, stored immutably, produced by hardened CI, and verified at deploy/runtime—closing the serverless supply-chain loop.
HardSystem Design
52 practiced
Design an architecture to centralize and store immutable audit logs from AWS, Azure, and GCP into a single, tamper-evident store for compliance. Address log ingestion (cross-account or tenant), schema normalization, indexing/search, integrity verification (signing, checksums), immutable/WORM storage (e.g., S3 Object Lock), access controls, encryption, retention policies, and cost optimization for long-term retention.
Sample Answer
**Clarify requirements**- Centralized, tamper-evident, cross-cloud (AWS/Azure/GCP), long-term retention, searchable, per-tenant/accnt isolation, compliance (WORM), cost-optimized.**High-level architecture**- Ingest layer (cloud-native collectors) → Normalization & signing → Index/Search cluster → Immutable object store (WORM) → Archive tiers + Catalog/metadata DB → Access & monitoring.**Ingestion (cross-account/tenant)**- AWS: centralized logging account using CloudTrail multi-region + CloudWatch Logs Subscription -> Kinesis Data Firehose (cross-account role) to normalization microservices.- Azure: Event Hubs/Diagnostic Settings -> Event Hub (shared namespace) -> Azure Function -> send to normalization.- GCP: Pub/Sub sinks from Cloud Audit Logs -> Pub/Sub -> Cloud Function -> normalization.- Use mutual TLS and cross-account roles/service principals; require per-tenant metadata (account id, org, region).**Schema normalization**- Normalize to canonical JSON schema (timestamp, cloud, account, service, resource, action, status, raw_payload, tenant_id).- Implement stateless Lambda/Functions or containerized microservice (K8s/ECS) that validates, enriches (geo, user mapping), and outputs canonical records.**Integrity verification**- At normalization, compute SHA-256 checksum and sign with an HSM-backed key (AWS KMS / Cloud HSM). Store signature and checksum in metadata and a separate audit ledger (append-only DB, e.g., DynamoDB with conditional writes or QLDB) for tamper-evidence.**Immutable/WORM storage**- Primary cold store per region: S3 buckets with Object Lock in Compliance mode + versioning; Azure immutable blobs; GCS Object Holders. Write-once via service account with restricted IAM; lifecycle: S3 Standard -> S3 Glacier Deep Archive after X days.**Indexing & Search**- Stream normalized records to OpenSearch/Elasticsearch for recent period (90 days) with hot/warm nodes; store minimal index (fields needed for search). Keep full raw payloads in WORM store and store pointers in index.- For analytics at scale, export canonical records to BigQuery/Redshift Spectrum or Athena using partitioned manifests.**Access controls & encryption**- Enforce least privilege via IAM/SP; require separate read-only roles for auditors. Encrypt data at rest using CMKs (KMS) with HSM-protected keys; server-side encryption for object stores. TLS for transit.**Retention & legal holds**- Use per-tenant retention policies. Implement policy engine that sets S3 Object Lock retention and legal hold flags. Retention enforced via immutable storage—only system admin with strict processes can extend via approvals logged in QLDB.**Cost optimization**- Keep searchable window short (e.g., 90d) in OpenSearch; archive raw payloads to Glacier/Deep Archive or Coldline; use lifecycle policies; compress and bundle small events into daily objects; use partitioned query engines (Athena/BigQuery) to avoid scanning.**Observability & Compliance**- Monitor ingestion metrics, dropped/failed events, signature mismatches. Periodic integrity verification job recalculates checksums and compares ledger entries; alert on mismatches. Produce audit reports for compliance.**Trade-offs**- QLDB (managed ledger) increases cost vs raw DynamoDB but provides stronger tamper-evidence. Keeping longer searchable window increases OpenSearch cost; mitigate via rollups.This design provides per-tenant isolation, tamper-evidence via signed checksums + immutable storage, searchable recent data, and cost-effective long-term retention.
EasyTechnical
54 practiced
Outline a concise incident response runbook for a cloud security incident involving suspected credential compromise (user or machine). Include immediate containment steps, evidence collection (logs, instance snapshots), communication steps (stakeholders and providers), short-term remediation (rotate keys, revoke tokens), and post-incident actions such as root cause analysis and remediation verification.
Sample Answer
**Incident Response Runbook — Suspected Credential Compromise (Cloud Engineer)**Situation: suspected user/machine credential compromise.Immediate containment (first 15–30 min)- Isolate affected identity: disable user account and/or remove machine role from instance profile/VM service account.- Revoke active sessions and rotate short-lived tokens (OIDC/SAML) where possible.- Quarantine affected instances: detach network interfaces, apply host-level firewall rules, or move to isolated VPC/subnet.Evidence collection (preserve before destructive changes)- Capture cloud audit logs (CloudTrail / Audit Logs) for identity, STS, IAM, EC2/Compute API calls (time-window ±1h).- Snapshot affected instances/disks and preserve metadata (instance IDs, AMIs, service account bindings).- Export in-memory or filesystem artifacts if allowed; preserve environment variables and process lists.- Collect network flow logs (VPC Flow Logs / VPC Flow / NSG) and console/session recordings.- Record hashes and chain-of-custody (who collected, when, tool).Communication- Notify: Security owner, Platform/Cloud Ops, affected app/product owner, Legal/Compliance, and Incident Manager.- If provider involvement required (suspicious API activity or service abuse), engage CSP support with case number and requested logs.- Use secure channel (encrypted ticketing/briefing) and a single source of truth (incident doc).Short-term remediation (hours)- Rotate credentials: issue new keys, rotate secrets in vaults, revoke old keys, update CI/CD secrets.- Revoke and reissue service account keys; enforce shortest-lived credentials and MFA.- Patch/replace compromised instances with clean images; rebuild from known-good AMIs.- Apply compensating network controls (denylists, WAF rules).Post-incident actions (days–weeks)- Root cause analysis: timeline from logs, attack vector (phishing, leaked secret, lateral movement).- Remediate root cause: remove exposed secrets from repos, enforce automated secret scanning, tighten IAM least privilege, enable MFA and require service account key rotation policies.- Verification: run red-team/scan to confirm no lingering access; validate with replayed authentication attempts blocked.- Lessons learned: update runbook, add automation (lambda/cloud function to auto-disable suspicious accounts), train teams, and report to stakeholders.Metrics to capture: time-to-detect, time-to-contain, scope (number of identities/instances), and recovery time.
EasyTechnical
55 practiced
Explain the principle of least privilege in cloud environments. Provide three practical steps a Cloud Engineer should take to implement least privilege for both human users and machine identities (service roles). Include examples of tools or automation (e.g., IAM Access Analyzer, permission boundaries, role templates) that help maintain least privilege over time.
Sample Answer
**Principle (brief)** Least privilege means granting users and machine identities only the minimum permissions required to perform their tasks — no standing admin rights, time-limited elevation, and continuous pruning.**Three practical steps for human users**1. Role-based access + Just-in-Time: Create narrowly scoped roles (e.g., "db-readonly") and use Azure AD PIM or AWS IAM Identity Center with JIT elevation for admin tasks. 2. Approval & time limits: Require approval and issue time-bound sessions (temporary STS tokens, Azure PIM elevations). 3. Review & recertification: Automate periodic access reviews (OKTA, Azure AD entitlement management) and remove stale accounts.**Three practical steps for machine identities (service roles)**1. Principle of least privilege by design: Build minimal service roles for each service (Lambda role only with S3:GetObject if needed). Use role templates or Terraform modules to enforce patterns. 2. Use permission boundaries / workload identity: Apply AWS permission boundaries or GCP Workload Identity to constrain what service accounts can do even if misconfigured. 3. Rotate and scope credentials: Prefer short-lived credentials (IRSA, Workload Identity Federation), and automate rotation with Vault or Secrets Manager.**Automation & tools to maintain least privilege**- Discovery & recommendations: AWS IAM Access Analyzer, GCP IAM Recommender, Azure AD Access Reviews. - Policy-as-code: Enforce policies with Terraform modules, Sentinel, or OPA/Gatekeeper in CI. - Guardrails: AWS Organizations SCPs, Azure Management Groups policies to block broad permissions.Reasoning: combine least-privilege design, time-bound access, and continuous automated review to reduce blast radius and maintain security as environments change.
Unlock Full Question Bank
Get access to hundreds of Cloud Security and Compliance interview questions and detailed answers.
