Cloud Security Fundamentals Questions

Core security principles and operational practices for cloud computing environments. Topics include the shared responsibility model and delineation of provider and customer responsibilities, identity and access management basics and least privilege, secure configuration and common cloud misconfigurations, data protection including encryption at rest and encryption in transit, key and secrets management basics, network security and segmentation, secure API design, audit logging, monitoring and alerting, cloud security posture management and automated misconfiguration detection, incident response and forensic readiness in cloud environments, governance, compliance and data residency considerations, strategies to reduce blast radius and prevent privilege escalation, and common cloud specific threats and mitigations. Candidates should be able to discuss trade offs, how to apply controls across major cloud providers, detection and mitigation strategies, and practical examples of securing cloud workloads.

MediumTechnical

110 practiced

You receive a SIEM alert indicating unusual API token usage from an IAM user outside their normal geolocation and time zone. Describe the triage steps you would take: what logs and data sources to collect (management plane, host, network), how to determine the scope of compromise, containment actions, evidence preservation steps, and stakeholder communication. Be concrete about cloud-native artifacts to capture.

Sample Answer

**Situation & first actions**I treat the SIEM alert as a potential credential misuse and act quickly but methodically: confirm alert details (timestamp, user ARN, source IP, user agent, API calls) and switch to evidence-preservation mode before aggressive containment that could destroy forensic data.

**Logs & data to collect**- Management plane: AWS CloudTrail events (full event JSON for the time window), AWS Config snapshot, IAM credential report, STS:GetCallerIdentity calls, Service Control Policy logs.- Host/application: EC2 CloudWatch Logs, instance system logs (/var/log/secure, auth.log), container logs (CloudWatch/EKS Fluentd).- Network: VPC Flow Logs, ALB/ELB access logs, GuardDuty findings, Route53 logs (if DNS lookups relevant).- Other cloud artifacts: S3 access logs, CloudFront logs, KMS CloudTrail entries, CloudWatch Events/ EventBridge rules, Lambda invocation logs.

Capture: export relevant CloudTrail events to a locked S3 bucket with MFA-delete, take EBS snapshots of affected instances, preserve IAM and STS session tokens, export VPC Flow Logs for the time window.

**Determine scope**- Correlate CloudTrail API calls from the suspicious credential across all regions and services.- Identify resources created/modified (CreateUser, CreateAccessKey, PutRolePolicy, AssumeRole).- Search for lateral movement: instance access, role assumption chains, new trusted principals.- Map source IPs to geolocation and check for matching user agent strings and time-of-day patterns.- Query configuration (Config) for recent changes and scan S3 buckets, IAM policies, security groups touched.

**Containment actions**- Immediately: disable/rotate the specific API keys (Create new keys if needed), revoke active sessions (AWS IAM console: Revoke sessions / STS token revocation via deny policies), remove or restrict suspicious IAM permissions, apply conditional policy to block the source IP or geolocation.- If host compromised: isolate affected EC2 instances by modifying security groups / NACLs or move to quarantine VPC, stop non-essential services.- Preserve forensics: do not delete snapshots/logs; mark them immutable.

**Evidence preservation**- Export CloudTrail raw events and related logs to a secure S3 bucket with restricted access and versioning.- Take EBS snapshots and image instances; collect memory if needed (forensic tools).- Record hashes of logs and snapshots, timestamps, chain-of-custody notes.- Tag preserved artifacts with incident ID.

**Stakeholder communication**- Notify security/incident response team and engineering manager immediately with: affected user, time window, suspected actions, containment steps taken, and request for escalation if keys indicate broad access.- Inform application owners of resources touched and potential impact.- Provide regular updates with forensic findings, scope, and remediation timeline; prepare an incident report after resolution.

This approach balances rapid containment with preserving evidence and mapping the full blast radius in a cloud-native environment.

MediumTechnical

52 practiced

Describe a comprehensive hardening checklist for container workloads running in a managed Kubernetes service (EKS/GKE), including build-time controls (image provenance and scanning), runtime controls (admission controllers, PodSecurity admission, runtime detection), network policies, node hardening, secrets handling, and integration with cloud IAM and logging. Provide concrete enforcement points in the CI/CD pipeline and at runtime.

MediumSystem Design

74 practiced

Design a secure CI/CD pipeline for cloud deployments that prevents secrets leakage and ensures only verified artifacts are promoted to production. Cover how to store and inject secrets securely, use ephemeral runners or OIDC tokens, sign and verify artifacts, integrate SCA and SAST scanners, run approval gates, and restrict deployment permissions through least privilege.

Sample Answer

**Clarify requirements**- Prevent secrets leakage, ensure only verified artifacts reach production, integrate SCA/SAST, use ephemeral runners/OIDC, sign & verify artifacts, enforce least privilege.

**High-level architecture**- Devs push to repo → CI builds on ephemeral runners (or cloud-hosted ephemeral agents) → SCA/SAST & tests → artifact signing + SBOM generation → push to immutable artifact repo → gated CD with verification & approval → production deploy.

**Secrets: storage & injection**- Store secrets in managed vaults (AWS Secrets Manager / Parameter Store with KMS, HashiCorp Vault).- Use short-lived credentials via OIDC: CI provider requests OIDC token, cloud STS issues temporary role credentials — no long-lived keys.- Inject secrets at runtime only to ephemeral runners or deployment pods via in-memory mounts or environment variables from vault with dynamic leasing; never write secrets to disk or artifact metadata.- Rotate and audit all secrets; enable automatic secret revocation on runner termination.

**Ephemeral runners & OIDC**- Use ephemeral, autoscaled runners (GitHub Actions self-hosted ephemeral, GitLab ephemeral) or cloud CI services. Protect runner bootstrapping with signed images and network isolation.- Use OIDC to exchange provider token for cloud roles minimizing static cloud creds.

**Artifact signing & verification**- Sign build outputs with a private key stored in HSM/KMS or using cosign + Fulcio + Rekor for transparency.- Produce and store SBOM (CycloneDX/SPDX) and attestation (in-toto) alongside artifact.- CD stage must verify signature, SBOM integrity, provenance and attestation before promoting.

**SCA & SAST integration**- Run SAST (static code analysis) and dependency SCA (e.g., Dependabot + Snyk/Trivy) in CI; fail builds on high/critical findings.- Record results, attach to attestation; optionally require remediation or approval for medium issues.

**Approval gates & policies**- Implement automated policy checks (signature, SBOM policy, vulnerability thresholds). If checks fail or if manual risk, require explicit approvers (role-based) in CD.- Record approvals in audit log and attach to promotion event.

**Least privilege & deployment restriction**- Use narrow IAM roles for each pipeline stage: build role can read source and write artifacts; deploy role only reads artifacts and updates runtime; no single role has full admin.- Use resource-bound roles (OIDC audiences, tag-restricted) and short-lived credentials.- Network controls: deployments only from CI subnets; restrict artifact repo write permissions to build role.

**Observability & auditing**- Log all pipeline actions, OIDC token exchanges, vault access, signature operations to centralized SIEM. Use Rekor transparency logs and KMS/HSM audit.

**Trade-offs**- HSM/KMS and attestation adds complexity but greatly reduces risk. Ephemeral runners cost more but reduce blast radius.

This design ensures secrets never persist in artifacts, uses short-lived creds, enforces signed/verifiable provenance, and applies layered scanning and approval gates under least-privilege controls.

EasyTechnical

65 practiced

Compare managed secrets services (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) and open-source solutions (HashiCorp Vault). For each, discuss typical use-cases, rotation strategies, access control models, integration with workloads (e.g., IAM or service identity), and trade-offs in operational complexity and cost. When is KMS sufficient versus requiring a full secrets manager?

Sample Answer

**Overview — quick comparison**- Managed: AWS Secrets Manager, Azure Key Vault, GCP Secret Manager — cloud-native, fully managed lifecycle, integrated with cloud IAM, pay-per-secret.- OSS: HashiCorp Vault — feature-rich (dynamic secrets, multiple auth backends, complex policies), self-hosted or managed (HCP Vault), greater operational overhead.

**Typical use-cases**- Managed: storing DB credentials, API keys, TLS certs for cloud-native apps, secrets for serverless and managed services.- Vault: multi-cloud or hybrid secrets, dynamic DB credentials, encryption-as-a-service, advanced tenancy/isolation, complex approle/OIDC flows.

**Rotation strategies**- Managed: built-in automatic rotation (Secrets Manager supports Lambda rotation; Key Vault with Azure Functions or event-driven rotation). Simple to set and schedule.- Vault: rotation via Vault plugins or custom jobs; supports dynamic credential leasing with TTLs and automatic revocation.

**Access control & identities**- Managed: uses cloud IAM (fine-grained IAM roles, resource policies, key/vault RBAC). Easy mapping from service identities (EC2 role, GKE Workload Identity).- Vault: policies (HCL), numerous auth backends (AppRole, Kubernetes, OIDC, LDAP). More flexible for non-cloud or cross-account scenarios.

**Integration with workloads**- Managed: seamless with cloud services (Lambda, EC2, AKS); trust model uses service identity; lower friction.- Vault: integrates via sidecar agents, CSI driver, Vault Agent Injector for Kubernetes; better for polyglot and hybrid environments but requires agent/config.

**Operational complexity & cost**- Managed: lower ops, pay-per-secret/month + API calls. Limited customization but fast to adopt.- Vault: higher ops (HA, storage backend, auto-unseal, upgrades), potential licensing or infra cost but powerful features.

**When is KMS sufficient vs full secrets manager?**- KMS (Cloud KMS) is for key storage and cryptographic operations (encrypt/decrypt, sign). Use KMS when you only need envelope encryption for data at rest or to protect config secrets stored elsewhere.- Use a secrets manager (or Vault) when you need secret lifecycle (rotation, versioning), secret distribution, fine-grained secret access, dynamic credentials, or secret injection into workloads.

Recommendation: For typical cloud-first apps use cloud-managed secrets. Choose Vault when you need advanced features, multi-cloud/hybrid support, or dynamic secrets despite higher ops.

HardTechnical

75 practiced

Design detection and prevention controls to stop privilege escalation and lateral movement inside cloud accounts. Include identity hardening (no wildcards, permission boundaries, managed policy reviews), monitoring (detect iam:CreatePolicy, PassRole, unusual role assumption), network controls (micro-segmentation, private endpoints), and runtime detection (behavioral baselining). Explain how to surface high-risk activities and how you'd automate containment actions without breaking legitimate workflows.

Sample Answer

**Approach summary**Design layered controls across Identity, Monitoring, Network and Runtime with automated, safe containment. Goals: prevent privilege escalation, detect lateral movement early, minimize false positives and avoid breaking legitimate workflows.

**Identity hardening**- Enforce least privilege: no wildcard actions/resources in policies; require permission boundaries for delegated principals.- Managed policy review pipeline: CI check that rejects policies with iam:* or wildcards, and flags new inline policies for human review.- Require MFA, short-lived credentials (OIDC, STS), and role session tags for traceability.- Example: deny iam:CreatePolicy unless request originates from a specific management role and has an approval tag.

**Monitoring / detections**- Log sources: CloudTrail/Activity Logs, VPC Flow, GuardDuty, Sentinel.- Detections: - iam:CreatePolicy, iam:PutRolePolicy, iam:AttachRolePolicy by non-admins - iam:PassRole when target role has high-privilege boundary - Unusual role assumption (new principal, atypical region/time, or cross-account patterns) - Rapid sequence: create policy → attach → assume role- Surface risk via risk score combining action sensitivity, asset criticality, anomaly score; push high-risk alerts to SOAR/PagerDuty and a dedicated dashboard.

**Network controls**- Micro-segmentation: use security groups/NACLs and service endpoints to limit east–west access.- Private endpoints and VPC-only access for management planes; restrict IAM/API access via allowlists.- Host-based EDR + host firewalls to prevent lateral hops.

**Runtime detection**- Behavioral baselining per principal and workload (API call frequency, services accessed).- Detect deviations (new API sequences, access to secrets, mass enumeration).- Use ML models with adjustable thresholds and feedback loop to reduce false positives.

**Automated containment (safe by design)**- Containment actions ranked: notify → throttle → session revoke → quarantine.- Example flow: detection of suspicious policy creation + immediate assume-role anomaly triggers: 1. Create high-priority alert and annotate incident ticket. 2. Use IAM session revocation for the offending principal (revoke tokens) — reversible and minimal blast radius. 3. Temporarily add a conditional deny permission boundary to the principal (scoped, time-limited) if automated confidence high. 4. Isolate affected hosts (move to quarantine subnet via tagging + network ACL change).- Safeguards: action approval workflow for destructive steps, automated canary/tier testing to ensure containment won’t break critical CI/CD roles, whitelist of emergency service accounts excluded from auto-quarantine.- Post-action: collect forensic snapshot, run post-mortem, and update detection rules.

**Trade-offs & operationalization**- Balance sensitivity with business impact: start with detection + manual approvals, then escalate automation as model precision improves.- Continuous policy as code, periodic privilege reviews, and drills to validate containment playbooks.

Unlock Full Question Bank

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

Join thousands of developers preparing for their dream job.