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

71 practiced

Design a set of SIEM detection rules to identify potential privilege escalation or abuse in an AWS environment. List the log sources you would use (for example CloudTrail, CloudWatch, LDAP), example detection rules (for example, iam:PutUserPolicy followed by console login), and strategies to reduce false positives.

Sample Answer

**Situation / Goal**Design SIEM detections to catch AWS privilege escalation/abuse using available logs and minimize noise.

**Log sources**- AWS CloudTrail (API activity, management events)- AWS CloudWatch Logs (Lambda, custom alerts)- AWS Config (resource change history)- VPC Flow Logs (suspicious data exfil)- AWS GuardDuty (threat findings)- Identity sources: Active Directory/LDAP + AWS SSO/IdP logs- CloudWatch Alarms and SNS (automation)

**Example detection rules (logic + examples)**1. IAM policy changes + immediate console access - Rule: detect iam:PutUserPolicy | iam:AttachUserPolicy | iam:PutRolePolicy followed within 10 min by ConsoleLogin (ConsoleLogin event with Success = true) from same user or source IP.2. New administrative role + role assumption - Rule: iam:CreateRole or iam:PutRolePolicy granting wildcards/effect:Allow & Action: "*" followed by sts:AssumeRole by any principal within 15 minutes.3. Inline creds creation - Rule: iam:CreateAccessKey or aws-credential-create for user with low prior usage, then high-rate API calls or S3:GetObject from sensitive buckets.4. Service control changes - Rule: Organizations:UpdatePolicy or iam:CreatePolicy attached to root/management account.5. Unusual console behavior post-privilege change - Rule: elevated API volume, creation of new keys, or policy attachments outside normal hours or from new geo-IP.6. Lateral movement via role chaining - Rule: multiple sts:AssumeRole across accounts within short window by same principal.

**Fields to correlate**- userIdentity.principalId, userIdentity.userName, sourceIPAddress, eventTime, eventName, requestParameters, awsRegion, sessionContext.sessionIssuer.

**False-positive reduction strategies**- Whitelist known automation/service accounts and scheduled runbooks (using tags, ARN patterns).- Baseline normal behavior per principal (time-of-day, IP ranges, typical API set) and only alert on deviations.- Require multi-signal escalation (e.g., policy change + immediate use) before high-priority alert.- Enrich events with asset sensitivity, business owner, and change tickets (CI/CD/Change Management) to suppress approved changes.- Use risk scoring: combine anomaly score, sensitivity of affected resource, and change type to tune thresholds.

**Investigation playbook**- Auto-enrich with recent CloudTrail events, AWS Config diff, MFA status, and IP geolocation.- Steps: identify actor, validate change, revoke temporary creds, rotate impacted keys/roles, open incident, and restore from backup/policy rollback.

This set balances catching high-risk escalation with contextual suppression to reduce noise.

MediumTechnical

70 practiced

You receive an alert for a sudden CPU spike on an instance; investigation reveals outbound connections to unfamiliar external IPs and multiple child processes spawning shells. Outline the technical investigation steps you would take to determine whether the host is compromised, how to isolate it with minimal business disruption, and what forensic artifacts to preserve.

MediumTechnical

67 practiced

How would you enforce data residency controls for sensitive PII that must not leave specific regions? Describe architecture and controls across cloud accounts and regions, including preventative controls (policies, SCPs), detection controls, and how to handle third-party SaaS vendors.

Sample Answer

**Approach summary (role perspective)** As an Information Security Analyst I’d combine preventative controls, continuous detection, and vendor governance so PII is confined to allowed regions and violations are automatically blocked or alerted.

**Preventative controls (architecture & policies)** - Global guardrails: Organization-level SCPs / Azure Management Group policies / GCP Organization Policy to deny resource creation outside approved regions (e.g., deny S3/GCS buckets, KMS keys, databases in disallowed regions). - Resource-level: Bucket/DB policies and IAM conditions requiring encryption with region-scoped KMS keys; VPC private endpoints and no public egress for storage. - Network controls: Egress firewall/NAT rules and AWS Network ACLs blocking outbound traffic to external storage endpoints in other regions. - Tagging + CI/CD checks: Require “data-class=PII” and region tags; IaC pipeline enforces allowed-region parameter and fails builds.

**Detection & response** - Logging: Enable CloudTrail/Activity Logs, Config Rules, CloudAudit, and storage access logs; centralize into SIEM. - Detection tools: Macie/DLP for S3, Cloud Security Posture Management alerts for noncompliant resources, IDS for suspicious data flows. - Automated remediation: Lambda/Runbooks to quarantine/disable offending resources, revoke cross-region KMS grants, and create incident tickets. - Monitoring metrics: Alerts for cross-region transfer, creation of untagged PII stores, or KMS key use outside region.

**Third‑party SaaS** - Risk/contract: Require data residency clauses, subprocessors list, and SOC2 / ISO certifications; contractually restrict where PII is stored/processed. - Technical controls: Use a CASB or reverse proxy to enforce inline DLP, encrypt/tokenize PII before sending, or use regional tenant options. - Assessment: Periodic audits, penetration tests, and contractual right-to-audit.

**Operational governance** - Inventory: Maintain authoritative data map and ownership. - Periodic reviews and training for teams. - Documented incident playbook for cross-region leaks.

This layered model prevents most misconfigurations, detects anomalies quickly, and ensures third-party handling meets residency requirements.

EasyTechnical

53 practiced

Explain the difference between cloud security groups and network ACLs (stateless vs stateful) and provide examples of when each should be used. Include a short explanation of how you would implement microsegmentation for a three-tier web application in a VPC.

HardTechnical

69 practiced

A production managed database shows suspicious read activity at odd hours. You cannot take disk-level snapshots, but you have DB logs, backups, and read replicas. Describe a step-by-step forensic approach to determine which data was accessed and whether data exfiltration occurred. Include the use of logs, replicas, snapshots, and any provider-specific features you would leverage.

Sample Answer

**High-level approach (preserve → collect → analyze → verify → remediate)**

1. Preserve evidence- Immediately freeze automated jobs that could overwrite logs (don’t restart DB processes).- Snapshot any available logical artifacts: take a read-replica snapshot or logical backup (pg_dump/mysql dump) of replica; export current DB parameter group and audit settings.- Export/secure existing backups and DB logs to an isolated, immutable location (S3 with Object Lock or equivalent).

2. Collect logs & telemetry- Gather DB logs: general/slow query logs, binary logs (binlog/mysql binlogs; WAL segments/pg_wal), audit logs (pgaudit, MySQL Enterprise Audit), error logs.- Pull cloud provider telemetry: AWS CloudTrail, RDS Enhanced Monitoring, VPC Flow Logs, GuardDuty findings, CloudWatch logs/metrics.- Query SIEM for correlated alerts (VPN, bastion, IAM/API calls) and host logs for possible exfil tools.

3. Reconstruct access timeline- Correlate timestamps across logs to identify client IPs, usernames, connections, session duration, and queries run.- From binlogs/WAL: extract read-only statements aren’t always recorded — focus on slow/general logs and audit/audit-log filters for SELECTs. If audit wasn't enabled, find connection/session start/stop events and SQL text in proxies (pgbouncer) or app logs.- Use CloudTrail for RDS Data API or snapshot/export actions and IAM usage.

4. Use replicas and backups for forensic analysis- Restore a read-replica snapshot or a backup to an isolated forensics VPC/instance to run safe queries and comparisons.- If point-in-time recovery (PITR) available, restore DB to key timestamps before/after suspicious sessions to compare row-level changes.- Hash critical tables (checksum) on restored copy and on most recent backup; differences indicate tampering/exfil or deletion.

5. Determine data exfiltration vectors- Check network egress: VPC Flow Logs, NAT gateway logs, CloudTrail S3 GetObject/PutObject, data transfer to external IPs.- Search for large read volumes or use of export features: RDS export to S3, snapshot copy, read replica creation, or EXPORT_TO_S3 operations.- Inspect application and bastion host logs for tools (scp, aws s3 cli, curl) and abnormal processes.

6. Verify and prove access- Reproduce suspicious SELECTs safely against restored copy to identify exact rows/columns accessed.- Produce audit trail: connection → query → data returned (size/rows) → egress evidence (network/S3/API).- Create cryptographic hashes of impacted tables/rows and archive for legal chain-of-custody.

7. Remediate & harden- Rotate DB credentials, revoke suspicious IAM roles, isolate compromised hosts, block offending IPs.- Enable/augment audit logging (full SELECT logging where needed), enable binlog/WAL archiving with retention, enforce TLS, restrict replica creation and snapshot permissions.- Implement granular monitoring: alert on large reads, unexpected snapshot/export, anomalous read patterns via SIEM/UEBA.

Provider-specific notes (AWS example)- Use RDS read-replica snapshot or restore point-in-time from automated backups to isolated account/VPC.- Query CloudTrail for rds:CreateDBSnapshot, rds:StartExportTask, s3:GetObject, and AWSConfig for configuration changes.- Use VPC Flow Logs, NAT gateway metrics, and GuardDuty to spot exfil IPs.- Leverage RDS Performance Insights and Enhanced Monitoring for session-level metrics.

Why this approach- Preserves chain-of-custody, avoids altering production state, uses replicas/backups to safely reconstruct what data could be read, and combines DB and network logs to prove exfiltration.

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.