Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort. The five NIST essential characteristics are:

• On-demand self-service: Users provision resources without human CSP interaction.
• Broad network access: Services accessible over any network from any device.
• Resource pooling: Multi-tenant model where resources are pooled and dynamically assigned.
• Rapid elasticity: Resources scale up/down automatically on demand.
• Measured service: Usage monitored, controlled, and billed transparently.

The shared responsibility model defines the division of security duties between the Cloud Service Provider (CSP) and the customer. The CSP secures of the cloud (physical datacenters, hardware, hypervisor, global network), while the customer secures in the cloud (data, identity, applications, configurations).

The exact boundary shifts by service model: IaaS customers own more, SaaS customers own less. The most common security failures come from customers misunderstanding their responsibilities — e.g., assuming the CSP encrypts data when it is actually the customer's job.

Multi-cloud means using two or more cloud providers simultaneously (e.g., AWS for compute, Azure for identity, GCP for ML). Drivers: avoid vendor lock-in, best-of-breed services, geographic redundancy, regulatory requirements.

Security challenges:

• Inconsistent security controls (AWS security groups ≠ Azure NSGs)
• Identity federation complexity across providers
• Visibility gaps — no single pane of glass without third-party CSPM
• Separate audit logs and SIEM integration challenges
• Different compliance postures per provider
• Skills gap — teams must know multiple cloud platforms

The cloud attack surface includes all the points where an attacker could try to gain unauthorized access. In cloud environments, this includes:

• Management APIs: Cloud control planes (AWS API, Azure ARM) accessible over the internet.
• Credentials: API keys, access tokens, service account keys — often with broad permissions.
• Storage: Object storage (S3, Azure Blob) that can be made publicly accessible by misconfiguration.
• IAM policies: Overly permissive roles and policies.
• Serverless functions: Lambda functions with misconfigured triggers or permissions.
• Container registries: Public ECR/Docker Hub images with vulnerabilities.

Vs. traditional: attackers needed network access first. In cloud, internet-exposed management APIs mean the attack surface is global and always-on.

In traditional on-premises security, a network firewall defined a trusted internal zone. Everything inside was (incorrectly) assumed to be trusted. In cloud environments, there is no fixed network perimeter — resources are internet-accessible, and attackers don't need to "get inside the network" first.

Instead, identity (who you are, and what you're authorized to do) becomes the primary security control. Every API call in AWS, Azure, or GCP is authenticated with an identity (IAM user, role, service account). If an attacker steals a credential, they can act as that identity from anywhere in the world.

This is why Zero Trust Architecture — "never trust, always verify" — is critical in cloud environments.

Data sovereignty refers to the principle that data is subject to the laws and governance of the country/region where it physically resides. When you store data in a cloud region, that data is subject to local law — including government access requests.

Why it matters:

• GDPR requires EU citizen data to not leave the EU without adequate protections.
• India's DPDP Act (2023) has data localization requirements for sensitive data.
• Some countries require health/financial data to remain in-country.
• US CLOUD Act allows US government to demand data from US companies regardless of where it's stored.

Mitigations: Select specific cloud regions, use data residency guarantees from CSPs, encrypt with customer-managed keys (CMEK), use data residency zones in Azure/GCP.

Ephemeral resources (containers, serverless functions, auto-scaling VMs) spin up and terminate within seconds or minutes, creating significant security challenges:

• Asset inventory: Traditional CMDBs can't track resources that exist for 30 seconds.
• Log retention: Logs from terminated instances may be lost if not forwarded to centralized logging.
• Forensics: Post-incident investigation is harder — the "crime scene" may no longer exist.
• Patching: Traditional patch management doesn't apply — instead, use immutable infrastructure (replace, don't patch).
• Security scanning: Container images must be scanned before deployment; runtime scanning (Falco) monitors live.

A CASB is a security policy enforcement point between cloud service consumers and cloud service providers that aggregates and applies enterprise security policies. It provides four core capabilities:

• Visibility: Discovers what cloud apps employees are using (Shadow IT detection).
• Compliance: Ensures cloud usage complies with regulations (GDPR, HIPAA).
• Data Security: DLP policies to prevent sensitive data leaving via cloud apps.
• Threat Protection: Detects malware, compromised accounts, and insider threats.

CASB can be deployed in three modes: forward proxy (agent-based), reverse proxy, or API-based.

Examples: Microsoft Defender for Cloud Apps, Netskope, Zscaler CASB.

The Cloud Security Alliance (CSA) is a not-for-profit organization that promotes best practices for cloud computing security. Key contributions:

• CSA Cloud Security Guidance v4: Comprehensive guide covering 14 domains of cloud security.
• Cloud Controls Matrix (CCM): Framework of cloud-specific security controls mapped to major compliance standards (ISO 27001, PCI-DSS, GDPR, HIPAA).
• CCSK Certification: Certificate of Cloud Security Knowledge — widely recognized cloud security credential.
• Top Threats Report: Annual report on the top cloud security threats (Egregious Eleven, Pandemic Eleven).
• STAR Registry: Cloud provider security transparency program.

The Center for Internet Security (CIS) publishes Cloud Benchmarks — prescriptive, consensus-based configuration guidelines for securing cloud environments. Available for AWS, Azure, GCP, and others.

CIS Benchmarks have two levels:

• Level 1: Basic, widely applicable controls with minimal performance impact (recommended for all).
• Level 2: Stricter controls for high-security environments; may reduce functionality.

Examples of CIS AWS Benchmark controls: Enable CloudTrail in all regions, enable MFA on root account, avoid root account usage, rotate access keys every 90 days, enable GuardDuty.

CSPM tools (AWS Security Hub, Prisma Cloud) can automatically audit against CIS Benchmarks and report compliance scores.

Shadow IT is the use of IT systems, software, or services without explicit organizational approval — enabled by cloud's on-demand, credit-card-purchasable nature.

Security risks:

• Sensitive data stored in unauthorized SaaS apps (personal Dropbox, free Slack).
• Unauthorized cloud accounts not covered by corporate security policies.
• No encryption, access controls, or audit logging on shadow systems.
• Data may be stored in unapproved geographic regions.
• Violates compliance requirements (GDPR, HIPAA) if regulated data is involved.

Controls: CASB for SaaS visibility, DNS filtering, CSPM for unauthorized cloud accounts, regular cloud spend analysis, employee security training.

In cloud environments, the entire infrastructure control plane is API-driven — every resource creation, modification, and deletion happens via authenticated API calls. This creates unique security considerations:

• Scale: Cloud APIs are internet-facing 24/7 — no network perimeter protection.
• Blast radius: A compromised cloud management API key can delete entire environments.
• IMDSv1 vulnerability: SSRF attacks can access EC2 instance metadata and steal IAM credentials via 169.254.169.254.
• Service-to-service: Cloud services communicate via internal APIs — IAM roles must be tightly scoped.
• Rate limiting: CSPs have API rate limits, but attackers can still exfiltrate data within limits.

Controls: Enforce IMDSv2, use API gateway with WAF, enable CloudTrail for all API calls, rotate keys, use short-lived tokens (STS).

Cloud sprawl is the uncontrolled proliferation of cloud instances, services, and accounts across an organization — often due to the ease of provisioning cloud resources. Security risks include:

• Unknown assets that aren't patched or monitored.
• Abandoned accounts with valid credentials still active.
• Unmanaged data stores with sensitive data.
• Inconsistent security policies across sprawled environments.
• Increased attack surface and compliance scope.

Controls: Cloud governance policies, tagging enforcement, resource lifecycle management, automated decommissioning, CSPM tools, cloud cost management tools (which indirectly reveal sprawl).

The AWS Well-Architected Framework has six pillars; the Security Pillar focuses on protecting information and systems. Its five design principles are:

• Implement a strong identity foundation: Least privilege, MFA, short-lived credentials.
• Enable traceability: Log and audit all actions (CloudTrail, Config, GuardDuty).
• Apply security at all layers: Defence in depth — VPC, subnets, security groups, WAF, application, data.
• Automate security best practices: IaC security, automated guardrails (SCPs, Config Rules).
• Protect data in transit and at rest: TLS everywhere, KMS encryption.
• Keep people away from data: Automate operations; humans shouldn't access prod data.
• Prepare for security events: IR playbooks, GameDays, AWS Incident Manager.

CSA's "Pandemic Eleven" top cloud security threats (2022):

1. Insufficient Identity, Credentials, Access and Key Management
2. Insecure Interfaces and APIs
3. Misconfiguration and Inadequate Change Control
4. Lack of Cloud Security Architecture and Strategy
5. Insecure Software Development
6. Unsecured Third-Party Resources
7. System Vulnerabilities
8. Accidental Cloud Data Disclosure
9. Misconfiguration and Exploitation of Serverless and Container Workloads
10. Organised Crime/Hackers/APT
11. Cloud Storage Data Exfiltration

This tests communication skills. A strong answer avoids jargon:

"Think of renting an office versus owning a building. When you rent (public cloud), the landlord (CSP) is responsible for the building structure, locks on the main entrance, fire suppression systems, and utilities. But you're responsible for locking your office door, who has a key, what files you keep in your cabinets, and your own security cameras inside. If you leave confidential papers on your desk and a cleaner photographs them — that's your responsibility, not the landlord's. AWS/Azure/GCP works exactly the same way."

Key points:

• Frame it as a risk and cost discussion, not a technical detail.
• Clarify what YOUR team is responsible for — this is often misunderstood.
• Explain that cloud security failures are mostly customer mistakes, not CSP failures.