Cloud Security (Multi-Cloud), Interview Questions.

With IaaS (virtual machines, networks) the provider secures hardware and virtualisation, you secure OS, apps, data and identity. With PaaS the provider also manages the runtime and platform, you keep app code, data and access. With SaaS the provider runs almost everything, and you still own identity, configuration, data classification and user behaviour. Responsibility for identity and data never moves to the provider.

Cloud Security Posture Management continuously checks cloud configuration against best practice and compliance benchmarks (public storage, open ports, missing encryption, weak IAM) and reports drift. It finds misconfigurations, which are the most common cause of cloud incidents.

A Cloud Workload Protection Platform secures running workloads (VMs, containers, functions) with vulnerability scanning, runtime protection and integrity monitoring. A CNAPP combines CSPM, CWPP, entitlement analysis, code-to-cloud scanning and more into one platform with shared context.

Cloud resources are reachable by API from anywhere, so network location matters less than who is calling. A stolen token or over-privileged role lets an attacker act with full legitimate authority. That makes strong authentication, least privilege and short-lived credentials the core controls.

Grant only the permissions needed for a task, for the time needed. Start from deny, use roles and groups, review access regularly, and prefer just-in-time elevation. It limits damage when an identity is compromised.

Passwords leak or get phished. MFA adds a second proof. Phishing-resistant methods (FIDO2 security keys, passkeys) are best, because push approvals and one-time codes can be phished or fatigued.

Defining infrastructure in files (Terraform, CloudFormation, Bicep) allows review, versioning, repeatability and automated policy checks before deployment. Scan templates in CI to catch open security groups or unencrypted storage before they exist.

Use organisation-level policy (SCPs, Azure Policy, Organization Policy) for hard limits, IaC with policy-as-code checks (OPA, Sentinel, Checkov) for preventive review, and CSPM for detection and drift. Prefer prevent, then detect, then respond, and manage exceptions with expiry dates.

Workloads receive short-lived credentials from the platform (instance roles, managed identities, service accounts, OIDC federation) instead of long-lived keys stored in code or CI. Static keys leak, are rarely rotated and are hard to attribute.

Classify data, encrypt at rest and in transit with managed keys, control access with least privilege, prevent public exposure, enable object versioning and immutable backups, monitor access, apply DLP for sensitive types, and set retention and deletion policy. Key access is as important as data access.

Provider-managed keys are simple and automatic. Customer-managed keys give control over policy, rotation, disabling and audit. Bring-your-own or external key stores add more control but add operational burden and availability risk, so use them where compliance demands.

Unify identity (one IdP with federation), standardise policy and tagging, centralise logs into one SIEM, use a CNAPP for consistent posture view, and define a baseline per provider. Beware of lowest common denominator design: use native controls but keep one operating model.

Public storage, wide-open security rules for admin ports, unused but active access keys, missing MFA, no logging, over-permissive roles, unencrypted snapshots, default network settings, exposed databases and unpatched images. Automate detection and auto-remediation for the repeat offenders.

Enable control plane audit logs everywhere and ship them to a protected central store, add network flow, DNS and workload logs, normalise into the SIEM, and write detections for high-risk events (root or owner use, policy changes, disabled logging, new keys, unusual regions). Test detections with simulated actions.

Multi-account or multi-subscription structure by environment and data sensitivity, centralised identity with MFA and just-in-time admin, baseline guardrails, private networking with controlled egress, central logging and security accounts with immutable storage, standard encryption keys, automated account vending with policy baked in, and compliance reporting. Document the control mapping to the regulation.

Compromised dependencies, build systems, base images or pipeline credentials can push malicious code into production. Controls: pinned and verified dependencies, SBOMs, signed artefacts and provenance (SLSA concepts), isolated ephemeral build runners, short-lived federated credentials, mandatory review, and admission policies that only run signed images.

Discover through billing, SSO logs, DNS and egress data, and CASB tools. Bring accounts into the organisation, apply baseline guardrails, and give teams a fast sanctioned path so they stop going around security. Treat it as a platform problem as well as a policy one.

Cloud identities accumulate permissions far beyond use. CIEM tools analyse effective permissions across providers, find unused or risky grants and toxic combinations (for example, ability to create roles plus attach policies), and recommend right-sizing. Privilege escalation paths through IAM are a key hunting target.

Enforce tenant isolation at every layer: identity claims carrying tenant ID checked server-side, row-level security or separate schemas, per-tenant encryption keys for sensitive data, isolated compute for high-risk tenants, rate limiting, and tests that try cross-tenant access. Cross-tenant data exposure is the top risk.

Agentless scanning reads disk snapshots and APIs: fast coverage, no deployment, but no live runtime view. Agents give runtime visibility and blocking, at the cost of deployment and overhead. Many programmes use agentless for breadth and agents for critical workloads.

Evidence is API logs and snapshots instead of servers you can seize. Plan for automated isolation (swap security group, disable role), snapshot capture, ephemeral resources that vanish, cross-account forensic access prepared in advance, and provider support contacts. Practise with game days.

Restrict the endpoint immediately, check access logs for unknown sources, review credentials and rotate if exposed, then add a preventive policy (deny public database creation) and an IaC check. Teach the team the private connectivity pattern.

Data classification and residency, shared responsibility mapping, provider compliance reports, encryption and key control, identity design, logging and retention, exit strategy and backup, third-party risk, and incident notification terms. Deliver a risk-based decision, not a blanket yes or no.

Weight by exploitability and exposure: internet-reachable, sensitive data, privileged identity, known exploited issue, then by blast radius. Group by root cause (one template causing hundreds), assign owners, set SLAs, and automate fixes for repetitive findings. Reduce the flow by fixing the pipeline.

Use configuration queries and compliance rules to list every storage resource and its encryption setting and key, enforce with policy, produce evidence reports with timestamps, and show the process for exceptions. Evidence should be repeatable, not manual screenshots.