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.

EasyTechnical

93 practiced

Explain the cloud shared responsibility model for public cloud providers (for example AWS, Azure, GCP). For each of the following layers: infrastructure (physical hosts), virtualization/compute, storage, networking, and managed platform services, describe which responsibilities are typically owned by the provider and which are owned by the customer. Give two concrete examples where responsibilities shift depending on service type (IaaS vs PaaS vs SaaS).

Sample Answer

High-level principle: public cloud providers secure the global and regional infrastructure and the services they offer; customers secure everything they deploy and configure on top. As a Solutions Architect you must explicitly map responsibilities by layer so designs and SOWs are correct.

Infrastructure (physical hosts, data centers)- Provider: physical security, power, cooling, hardware lifecycle, hypervisor patching, network fabric in the data center, geographic redundancy.- Customer: none (except contractual requirements like data residency choices).

Virtualization / Compute (VMs, container hosts)- Provider: hypervisor security, host OS patching for fully managed KVM/VMware-like hosts, isolation between tenants.- Customer: guest OS patching, runtime configuration, endpoint hardening, agents and root access if using VMs.

Storage (block, object)- Provider: durability, replication, physical disk replacement, underlying encryption-at-rest implementation options, availability SLAs.- Customer: access control (IAM), encryption keys (customer-managed KMS vs provider-managed), lifecycle policies, data classification.

Networking (VPCs, subnets, routing)- Provider: physical network, DDoS protection services, global backbone.- Customer: VPC design, subnetting, security groups/NSGs, route tables, VPN/peering configuration, firewall rules.

Managed Platform Services (RDBMS, serverless, SaaS)- Provider: service software patching, scaling, underlying OS and middleware, backup infrastructure (depending on SLA), availability.- Customer: data inside service, schema design, user access/roles, application-level encryption, secure configuration.

Two concrete shifts depending on service type1) Databases:- IaaS (self-managed DB on VM): customer responsible for DB engine patching, backups, replication, scaling; provider only supplies VM and hypervisor security.- PaaS (managed DB like RDS / Cloud SQL): provider handles engine patching, backups (if enabled), and HA options; customer handles schema, user accounts, and encryption keys if CMK used.

2) Application runtime:- IaaS (VM): customer manages OS, app server, scaling automation.- PaaS / FaaS (App Service, Cloud Functions): provider manages OS/runtime, scaling, and many patches; customer responsible for code, auth, and input validation.

Key takeaway: when moving from IaaS → PaaS → SaaS, operational burden shifts left to the provider but security of customer data, identities, access controls, and secure configuration remains the customer’s responsibility unless explicitly contracted otherwise.

HardTechnical

53 practiced

Design an automated detection system to identify potential lateral movement across cloud accounts using identity and network telemetry. Describe the data model, correlation techniques (graph analysis, entity behavior analytics), false positive reduction strategies, and how you would surface high-confidence incidents to SOC analysts.

Sample Answer

Requirements clarification: detect lateral movement across cloud accounts using identity (CloudTrail, IAM, STS, SSO logs) and network telemetry (VPC Flow Logs, Transit Gateway, peering, VPN, endpoint logs). Low latency, scalable across many accounts, high signal-to-noise for SOC consumption.

Data model- Entity-first: nodes = identities (user, service/principal, role, temporary STS session), hosts (instance IDs, container/pod IDs), network locations (subnet, VPC, AZ), accounts/tenants, processes/services.- Edge types: authentication (assume-role, login), network connection (src→dst with ports), resource access (API calls to S3/Secrets Manager), delegation (role chaining). Store time-series attributes per edge (count, first/last, geo, device, user-agent).- Storage: graph DB (JanusGraph/Neo4j or scalable property graph like Amazon Neptune) + time-series store for raw telemetry (S3 + Parquet + Athena/Glue) and feature store for UEBA.

Correlation techniques- Graph analysis: - Build temporal multi-hop graphs. Detect new or rare cross-account edges (e.g., role assume from account A to B then API access in B). - Pathfinding for "attack chains": identity->assume->instance->dst account resource. Use weighted shortest paths and subgraph matching for known lateral patterns. - Community detection to find outlier nodes bridging communities (sudden cross-account pivot).- Entity Behavior Analytics (UEBA): - Per-identity baseline of login hours, source IPs, typical API surface, assumed roles, network flows. - Feature engineering: role-chain depth, unusual assume-role sequences, first-time network flows between accounts, net new cross-account destinations, entropy of source IPs, short-lived credentials usage. - Anomaly scoring via hybrid model: deterministic rules for high-fidelity indicators (e.g., assume-role + remote exec) plus supervised/unsupervised models (isolation forest, seasonal hybrid autoencoders) for behavioral anomalies.- Correlation rules: combine graph-derived risk signals with UEBA scores and enrichment (threat intel, known compromised IPs, device posture) to compute composite confidence.

False positive reduction- Contextual enrichment: resolve identity owner, known automation/service accounts whitelist, scheduled job calendars, CI/CD pipeline inventory, trusted peering list.- Temporal smoothing & persistence: require multi-evidence (>=2 independent signal types within time window) or persistent deviations, not single transient anomaly.- Adaptive baselining per account and per role; dynamic thresholds (percentile-based) to account for business seasonality.- Feedback loop: SOC analyst feedback feeds supervised model labels and whitelist/blacklist tuning; maintain audit trail for model drift.- Risk weighting: penalize common low-risk patterns (e.g., cross-account read-only S3 list calls) while elevating sensitive operations (create-key, get-secret, console login).

Surfacing high-confidence incidents- Incident score: weighted aggregation of (graph novelty, UEBA anomaly score, sensitive API usage, threat intel hit, lateral path length). Map to severity tiers (High/Med/Low).- Alert content for SOC: - Short summary: why high confidence (e.g., "Cross-account assume-role from Account A→B + instance in B accessed Secrets Manager and outbound connection to external IP flagged by TI — composite score 0.92") - Visualized attack path: clickable graph with timeline, edges colored by evidence type. - Evidence bundle: raw CloudTrail events, VPC Flow log snippets, session tokens, IP geolocation, user-agent, host process logs. - Recommended playbook actions: isolation steps, credential revocation, MFA enforcement, confirm automation, suggested queries for further scope (search for other assume-role tokens from same source).- Automation: for critical/high-confidence incidents, trigger automated containment (revoke session tokens, block IP in WAF/SG, disable role) behind change-control with manual approval workflow.- UX: ticket integration (SOAR/SIEM) with one-click triage actions and analyst feedback button to update models.

Operational considerations- Scale: batched graph construction with incremental updates; time-windowed indices for sliding-window detection.- Privacy & access control: role-based access to graph and alerts.- Metrics: mean time to detect, false positive rate, analyst triage time, alerts per 1000 users — iterate thresholds.

Example scenario- Detection: unusual assume-role from external EC2 in account A to role in account B, then SecretsManager:GetSecretValue in B and outbound flow to uncommon IP. Graph shows new cross-account pivot path length 3; UEBA flags role usage outside normal hours. Composite score >0.9 → High incident with path visualization and playbook to disable role and rotate secrets.

This design balances graph-based chain detection with UEBA scoring and enrichment to reduce noise and deliver high-confidence, actionable incidents to SOC analysts.

EasyTechnical

76 practiced

Explain the concept of blast radius reduction. Provide two architecture patterns that reduce blast radius in multi-tier cloud applications and explain one operational impact or cost trade-off for each pattern.

HardTechnical

65 practiced

As a solutions architect, propose an approach for continuous compliance and evidence collection for regulatory audits (for example SOC2 or GDPR) across hundreds of cloud accounts. Include automation for evidence gathering, mapping controls to evidence, and how to handle accounts that fall out of compliance.

Sample Answer

Requirements:- Continuous evidence collection across hundreds of cloud accounts (multi-AWS/Azure/GCP) for SOC2/GDPR.- Automated mapping of controls to evidence.- Alerting and automated remediation for drift; audit-ready immutable evidence storage.- Low operational overhead, scalable, secure, and auditable.

High-level architecture:- Account-level agents & collector Lambdas → Central ingestion bus (Kafka/EventBridge) → Evidence processing & metadata store (DynamoDB/Postgres) → Control mapping engine → Immutable evidence lake (S3/Blob with WORM + object versioning) → Compliance dashboard & alerting → Orchestration for remediation (SSM/Runbooks/Workflows).

Core components and flow:1. Discovery & onboarding: Organization-wide orchestration (CloudFormation/ARM/Terraform + Landing zone) automatically deploys a lightweight collector (Cloud Function/Lambda + read-only IAM role) to each account. Collector pulls config snapshots, IAM policies, logs, VPC flow, config rules, snapshots of relevant resources, and pushes events.2. Evidence ingestion: Event bus normalizes artifacts; processors enrich (timestamp, account, region, hash), store original artifact in immutable lake, and index metadata into the evidence catalog.3. Control mapping: A rules engine maps artifacts to control statements (SOC2/GDPR) using configurable mapping files (YAML/JSON). Each control has required evidence types, TTL, and acceptance criteria (e.g., policy present + last-changed <30d).4. Continuous assessment: Evaluate controls in near real-time; produce control status (pass/warn/fail) with links to evidence items. Use Config/Policy-as-Code (Open Policy Agent/Rego) for deterministic checks.5. Remediation & escalation: For WARNING/FAIL: - Automated remediation playbooks for safe fixes (apply policy, rotate keys, enable encryption). Playbooks run via orchestrator with RBAC and dry-run mode. - If auto-remediation fails or is risky, create ticket in ITSM, notify owners, and apply temporary compensating controls (restrict access).6. Audit evidence lifecycle: - Evidence retention policy per regulation (e.g., SOC2 1 year) enforced via lifecycle rules; immutable storage with access logging and checksum. Provide signed manifests for auditors.7. Observability & reporting: - Central dashboard showing controls, risk heatmap, account inventory, and audit packages (pre-built zip of evidence + mapping). - Alerts (PagerDuty/Slack/email) for high-risk failures, and periodic compliance reports (weekly/monthly).

Security, governance & scale:- Least privilege collectors, cross-account roles, KMS customer-managed keys for encryption, centralized key policies.- Use organization-level SCPs to prevent disabling collectors.- Horizontal scaling via serverless processors, partitioned evidence store, and sharding for hundreds+ accounts.

Trade-offs & considerations:- Depth of agent vs API-only: agents give richer telemetry but require maintenance; start API-first, add agents for sensitive resources.- Full auto-remediation vs manual: prefer idempotent safe fixes, require approvals for high-impact changes.- Mapping maintenance: keep control mappings as code in repo with CI to allow auditability and change history.

Metrics to track:- % controls passing, mean time to detect, mean time to remediate, evidence freshness, accounts out-of-compliance.

This approach provides end-to-end automation: continuous evidence collection, deterministic mapping to controls, automated remediation, and audit-ready immutable evidence for SOC2/GDPR at scale.

MediumTechnical

75 practiced

Write an example GCP IAM binding (in YAML or pseudo-YAML) that grants a Cloud Function the minimum permission to consume messages from a specific Pub/Sub subscription but nothing else. Explain how you would scope the binding to follow least privilege and what audit logs to review to ensure it is not misused.

Sample Answer

YAML (pseudo-YAML) binding that grants a specific Cloud Function's service account the minimum permission to consume messages from one Pub/Sub subscription:

resource: //pubsub.googleapis.com/projects/my-project/subscriptions/my-subscriptionbindings:- role: roles/pubsub.subscriber # least-privilege role for consuming messages members: - serviceAccount:my-func-sa@my-project.iam.gserviceaccount.com

Notes and reasoning:- Scope to the subscription resource (not the whole project or topic). Applying the binding directly to the subscription limits the principal to that single subscription.- Use roles/pubsub.subscriber because it grants the ability to Pull and Acknowledge messages but not to create/delete subscriptions or manage IAM.- Prefer a dedicated service account per Cloud Function (my-func-sa@...) so access is narrow and auditable.- Consider adding an IAM Condition if available to further restrict (e.g., require request.time constraints or source principal attributes) — e.g., allow only when request originates from the Cloud Functions service account identity or from the function's region.

Example with a simple IAM Condition (pseudo-YAML):resource: //pubsub.googleapis.com/projects/my-project/subscriptions/my-subscriptionbindings:- role: roles/pubsub.subscriber members: - serviceAccount:my-func-sa@my-project.iam.gserviceaccount.com condition: title: restrict-to-prod expression: request.time < timestamp("2026-01-01T00:00:00Z") # example constraint

Audit logs and monitoring to ensure least-privilege and detect misuse:- Enable and review Cloud Audit Logs: specifically Data Access logs for Pub/Sub (look for methodName like "google.pubsub.v1.Subscriber.Pull" and "google.pubsub.v1.Subscriber.Acknowledge"). These show which principal pulled/acked messages and when.- Review Admin Activity logs for IAM changes on the subscription resource to detect role/grant modifications.- Check Cloud Functions logs and metrics for anomalous invocation patterns (spikes, unexpected latencies, or failed ack rates).- Set up alerting on unusual Pull/Ack patterns or new IAM bindings created on subscription resources.- Optionally enable VPC Service Controls and Organization Policy constraints to limit where service accounts can be used.

This approach enforces least privilege by scoping permissions to the narrowest resource, using the minimal role, isolating a dedicated service account, and monitoring the relevant audit logs (Data Access and Admin Activity) for any misuse.

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.