Cloud Security Interview Questions for Cyber Security

The cloud provider secures the infrastructure: data centres, hardware, hypervisors and managed service internals. The customer secures what they put in the cloud: identities, data, configurations, network rules and their applications. The split changes by service type; with IaaS you patch the OS, with SaaS you mainly manage users and data settings. Most cloud breaches come from customer-side misconfiguration, not provider failures.

Frequent issues are publicly accessible storage buckets, overly permissive IAM policies with wildcards, long-lived access keys, security groups open to 0.0.0.0/0 on SSH, RDP or databases, disabled audit logging, unencrypted snapshots shared publicly, and exposed instance metadata. Cloud Security Posture Management tools and native services such as AWS Security Hub, Microsoft Defender for Cloud and Google Security Command Center detect them continuously.

Enable the native posture service, such as AWS Security Hub with the CIS AWS Foundations standard, Microsoft Defender for Cloud with the CIS Azure benchmark, or Security Command Center on Google Cloud. Open source tools like Prowler or ScoutSuite also work. Export findings, prioritise critical ones like root MFA, public storage and open admin ports, assign owners and track remediation over time.

I follow provider security blogs and release notes, since services change monthly, and read incident write-ups to learn real attack paths. I practise in personal free-tier accounts with budget alerts, using deliberately vulnerable labs. I hold a cloud security certification and plan the next one. I also share short notes with my team, which helps me learn more deeply.

AWS IAM controls who can do what on which resources through users, groups, roles and JSON policies. Best practices are avoiding root account use and protecting it with MFA, using roles with temporary credentials instead of access keys, least privilege policies, permission boundaries, and Service Control Policies in AWS Organizations to set guardrails across accounts. IAM Access Analyzer helps find unused and external access.

Essential sources are control plane audit logs such as AWS CloudTrail, Azure Activity Log and Entra sign-in logs, and Google Cloud Audit Logs. Add network flow logs, DNS logs, load balancer and WAF logs, storage access logs for sensitive buckets, and Kubernetes audit logs. Send them to a central account or SIEM that workload owners cannot delete, and enable threat detection services like GuardDuty.

IaC scanning checks Terraform, CloudFormation, Bicep or Kubernetes manifests for misconfigurations before deployment, such as public buckets or unencrypted databases. Tools include Checkov, tfsec in Trivy, and KICS. It shifts security left, so issues are fixed in a pull request rather than in production. Combine it with policy as code, like OPA, and drift detection to catch manual changes made in the console.

Situation: a scan found a critical vulnerability in a library used by five microservices just before a release. Task: fix it without delaying the launch. Action: I paired with the lead developer, confirmed which services were truly exploitable, prepared tested upgrade pull requests and added a WAF rule as a temporary safeguard. Result: all services were patched in two days and release stayed on schedule.

Most cloud storage, databases and disks encrypt data at rest by default with provider-managed keys. For more control, use customer managed keys in KMS, with key policies, rotation and logs of every use, or bring and hold your own keys for strict regulatory needs. Encryption at rest protects against physical media theft, but not against someone with valid IAM permissions, so access control remains critical.

Block public access on the bucket immediately and confirm with the owner whether any public access was intended. Check access logs and CloudTrail data events, if enabled, to see who downloaded files and when. If personal data was accessed, start the incident and breach notification process with legal. Then enable account-level block public access, add a preventive guardrail and alert on policy changes.

Give them freedom inside guardrails. Provide sandbox accounts where they have broad rights, but production changes go through IaC pipelines with scanning and review. Use permission boundaries and SCPs to block dangerous actions like disabling logging or making resources public. Offer pre-approved modules for common patterns. This keeps speed high while preventing the riskiest mistakes.

Isolate the instance by changing its security group to a quarantine group with no traffic, and snapshot its volumes for analysis. Check how it was compromised: exposed SSH, vulnerable app or leaked key. Review CloudTrail for actions by its instance role. Terminate and rebuild from a clean image, rotate secrets the instance could access, and fix the root cause, such as closing public ports.

Situation: our team checked cloud accounts manually every week for public buckets, which took hours. Task: make it faster and continuous. Action: I wrote a small script using the cloud CLI, scheduled it, and sent findings to a team channel with owner tags, then moved it into the CSPM tool. Result: checks ran hourly and average exposure time dropped from days to under an hour.

CSPM, Cloud Security Posture Management, checks cloud configurations against benchmarks like CIS and flags risks. CWPP, Cloud Workload Protection Platform, protects running workloads such as VMs, containers and serverless with vulnerability scanning and runtime detection. CNAPP combines these with identity analysis, IaC scanning and attack path analysis in one platform. The goal is to prioritise risks that combine, like a public VM with a critical flaw and admin role.

Cloud VMs can query a local metadata endpoint at 169.254.169.254 to get instance details and temporary role credentials. If an application has a server-side request forgery flaw, an attacker can make it fetch these credentials. AWS IMDSv2 requires a session token obtained with a PUT request and limits hops, which blocks most SSRF abuse. Enforce IMDSv2 and give instance roles minimal permissions.

Use minimal, scanned base images and sign them. Run containers as non-root with read-only filesystems and dropped capabilities. In Kubernetes, enforce Pod Security Standards, use RBAC with least privilege, network policies to restrict pod traffic, secrets from an external store, and keep the API server private. Enable audit logs and runtime detection such as Falco, and patch clusters regularly.

Separate accounts or subscriptions for production, development, security tooling, logging and shared services create strong blast-radius boundaries and simpler permissions. A compromised dev account cannot touch production. Central guardrails like AWS Service Control Policies or Azure Policy enforce rules everywhere, and a dedicated log archive account protects audit logs. Landing zone frameworks automate this setup for new teams.

The DPDP Act 2023 allows cross-border transfer of personal data except to countries the government restricts, though sector rules can be stricter. RBI requires payment system data to be stored only in India. CERT-In requires ICT logs to be kept in India for 180 days. SEBI and IRDAI have their own requirements for regulated entities. Cloud architects choose Indian regions such as Mumbai or Hyderabad for compliance.

I would require a landing zone with separate accounts, Indian region hosting for data residency, private networking with no public database endpoints, WAF and DDoS protection, customer managed KMS keys, PAM for admin access, central immutable logging to the SIEM, CSPM against CIS benchmarks, vulnerability scanning in CI, and a tested backup and disaster recovery plan. All mapped to RBI and audit requirements.

Capture the pod spec, image digest, logs and runtime alerts before deleting anything. Check how it got in: a vulnerable app, a compromised image in the registry or an exposed dashboard or kubelet. Review Kubernetes audit logs for who created the workload and what service account it used. Cordon affected nodes, rotate service account tokens and secrets, patch the entry point and enforce image signing.

Use workload identity federation with OIDC. The CI system issues a short-lived signed token for each job, and the cloud provider trusts that issuer and exchanges the token for temporary credentials of a narrow role. Restrict the trust policy to a specific repository and branch. This removes long-lived secrets from pipeline settings, so a leaked log or variable no longer gives permanent access.