Cloud Security Interview Questions: What to Prepare For

Security questions appear in almost every cloud engineering interview, regardless of whether the role is explicitly security-focused. This is intentional. Hiring managers have learned that an engineer who does not think about security introduces vulnerabilities into production — a problem that can take months to discover and cost significantly more to fix than hiring carefully in the first place.

You do not need to be a cloud security specialist to answer these questions well. You do need to demonstrate that security is part of how you think about building and operating infrastructure, not an afterthought you reach for when something goes wrong.

When Security Questions Appear#

At junior level, expect questions about basics: what IAM is, why least privilege matters, what encryption at rest means. These are screening questions — the interviewer wants to confirm you are not oblivious to security entirely.

At mid-level, expect questions that connect security to real decisions: how you would manage secrets, why you would choose a managed key service over rolling your own encryption, how you audit access. These questions probe whether your security thinking is practical, not just theoretical.

At senior level, expect scenario-based questions: a breach has occurred, an overly permissive policy is in place, someone left a secret in a public repository. Senior candidates are expected to understand threat models, not just controls.

Security engineer interviews go significantly deeper — threat modelling, vulnerability analysis, penetration testing approaches, compliance frameworks — and are beyond the scope of this page.

IAM Questions#

“What is the principle of least privilege and how do you apply it in a cloud environment?” Testing: security thinking baseline. Least privilege means giving an identity (user, role, service account) only the permissions it needs to do its job — no more. In practice: IAM roles scoped to specific resources and actions rather than broad wildcards, service accounts per workload rather than shared accounts, temporary credentials via role assumption rather than long-lived access keys. The follow-up question is usually “how do you know what permissions a workload actually needs?” — a strong answer mentions AWS IAM Access Analyzer, GCP Policy Analyzer, or CloudTrail/audit logs to identify what permissions are actually used.

“What is the difference between an IAM user, a role, and a service account?” Testing: IAM model understanding. IAM users are persistent identities with long-term credentials (passwords, access keys). Roles (AWS) / service accounts (GCP) are identities assumed by compute resources or services — they use temporary credentials and are the preferred pattern for workload authentication. Long-lived access keys attached to users are a security risk because they can be leaked and remain valid indefinitely if not rotated.

“How do you audit who has access to what in a cloud environment?” Testing: access governance knowledge. At minimum: use cloud-native tooling — AWS IAM Access Analyzer to flag resources accessible outside your account, AWS Config to track IAM policy changes over time, CloudTrail to log all API calls. On GCP, Cloud Asset Inventory and Policy Analyzer. More mature setups export these logs to a SIEM for centralised analysis. Strong candidates also mention periodic access reviews and the concept of access certification (having humans confirm that existing access is still appropriate).

“What is cross-account access and how do you implement it securely?” Testing: multi-account architecture knowledge. Cross-account access allows a role in Account A to assume a role in Account B to perform actions there. On AWS this uses sts:AssumeRole with a trust policy on the target role. The security consideration: the trust policy defines who can assume the role — it should be scoped to specific ARNs (not "*"), require conditions like MFA or specific external IDs, and be audited regularly.

“What is IAM policy evaluation and how does an explicit Deny interact with an Allow?” Testing: policy logic depth. AWS IAM evaluation order: explicit Deny always overrides any Allow. If no explicit Deny matches, an explicit Allow is required for access. If neither matches, the default is Deny. This matters when combining SCPs (Service Control Policies) at the organisation level with identity-based policies — an SCP Deny cannot be overridden even by an Administrator policy on the account.

Encryption Questions#

“What is the difference between encryption at rest and encryption in transit?” Testing: encryption basics. Encryption at rest protects data stored on disk — S3 objects, EBS volumes, database files. Encryption in transit protects data as it moves between services — TLS between a client and a load balancer, TLS between microservices. Both are required in any security-conscious deployment. The common mistake is assuming one covers the other.

“What is a KMS key and when would you use a customer-managed key instead of an AWS-managed key?” Testing: key management understanding. AWS Key Management Service manages cryptographic keys. AWS-managed keys are created and rotated by AWS automatically — convenient but you have no direct control. Customer-managed keys (CMKs) give you control over rotation, key policy, usage logging, and the ability to disable or delete the key. Use CMKs when your compliance requirements demand it, when you need to restrict which services can use the key, or when you need audit logs of every decrypt operation.

“How does envelope encryption work?” Testing: encryption design knowledge. Envelope encryption uses a data encryption key (DEK) to encrypt data, and a key encryption key (KEK — from KMS) to encrypt the DEK. Only the encrypted DEK is stored alongside the data. To decrypt, the service calls KMS to decrypt the DEK, then uses the DEK to decrypt the data. This pattern means KMS handles very little actual data but controls access to everything. It is how S3, EBS, and most managed services implement encryption.

Secrets Management Questions#

“How do you store and access secrets in a cloud application?” Testing: secrets hygiene. The wrong answer: environment variables with plaintext secrets, secrets hardcoded in application code, secrets stored in a repository. The right answer: use a managed secrets service (AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault) to store secrets. Applications retrieve secrets at runtime via an SDK call, authenticated by their IAM role or service account. Secrets are never written to source control or container images.

“What is the difference between AWS Secrets Manager and AWS Parameter Store?” Testing: practical tool knowledge. Secrets Manager is purpose-built for secrets — supports automatic rotation of database credentials, generates random secrets, charges per secret per month. Parameter Store is more general-purpose configuration storage — free tier available, supports hierarchical key names, works well for configuration that is sensitive but does not need rotation. Secrets Manager is the right choice when you need rotation; Parameter Store is fine for static secrets and non-secret configuration.

“What would you do if a developer committed an API key to a public GitHub repository?” Testing: incident response thinking. Immediate actions: revoke the key immediately (not after investigation — the moment it is in a public repo it must be assumed compromised). Check access logs for the key to identify any unauthorised use. Issue a new key, update any systems that use it. Check for any dependent resources that might have been accessed. File an incident report. The mistake candidates make is prioritising the investigation over revocation — revoke first, investigate second.

Network Security Questions#

“What is a WAF and when would you use one?” Testing: application layer protection knowledge. A Web Application Firewall inspects HTTP/HTTPS traffic and blocks requests that match attack patterns — SQL injection, cross-site scripting (XSS), known malicious IPs, rate limit violations. Use a WAF when you have a public-facing web application that you cannot fully control the input to. On AWS: AWS WAF in front of CloudFront or ALB. On GCP: Cloud Armor in front of Cloud Load Balancing. A WAF is not a substitute for secure application code — it is a defence-in-depth layer.

“What is the shared responsibility model?” Testing: cloud security mental model. The cloud provider is responsible for the security of the cloud infrastructure (physical hardware, hypervisors, managed service internals). The customer is responsible for security in the cloud — identity and access management, encryption of their own data, network configuration, operating system patching on IaaS, application security. The boundary differs by service type: IaaS (EC2) means you manage more; PaaS (Cloud SQL) means the provider manages the underlying OS; SaaS reduces your responsibility further.

“What is VPC flow logging and how would you use it?” Testing: network audit capability. VPC Flow Logs capture metadata about network traffic in your VPC — source IP, destination IP, port, protocol, bytes transferred, whether the traffic was accepted or rejected. They do not capture packet content. Use cases: investigating a security incident to determine what a compromised instance communicated with, identifying unusual traffic patterns, auditing security group effectiveness.

Compliance and Governance Questions#

“What is the difference between SOC 2, ISO 27001, and GDPR in the context of a cloud workload?” Testing: compliance awareness, not expertise. SOC 2 is a US attestation standard for how a service provider handles security, availability, and confidentiality — relevant if your company sells software services and customers ask for it. ISO 27001 is a certification for an information security management system — more common in enterprise and government contexts outside the US. GDPR is a data protection regulation requiring certain controls around personal data of EU residents: consent, data minimisation, breach notification, right to erasure, data transfer restrictions. For a cloud engineer, GDPR has practical implications: where you store data, how long you retain logs, and whether you have the ability to delete specific records on request.

“What is CloudTrail (or Cloud Audit Logs on GCP) and why is it important?” Testing: audit logging knowledge. CloudTrail records every API call made in an AWS account — who did what, when, from where. It is the primary source of truth for security investigations and compliance audits. Key configuration decisions: enable CloudTrail in all regions (not just the one you operate in), enable log file integrity validation (so logs cannot be tampered with), store logs in a separate dedicated account that does not have the same access as the account being audited.

Scenario Question: The Exposed S3 Bucket#

An interviewer might present this: “You discover an S3 bucket has been publicly accessible for three months containing customer data. What do you do?”

A strong answer follows this sequence:

Immediate containment. Remove the public access setting on the bucket immediately. Enable S3 Block Public Access at the bucket and account level. Do not investigate first — contain first.

Assess the exposure. Review CloudTrail and S3 server access logs for the three-month window. What objects were in the bucket? Were any accessed by external IPs? What data classification does the exposed data carry?

Notify stakeholders. Depending on the data contents and your jurisdiction, this may trigger legal obligations. GDPR requires breach notification to the supervisory authority within 72 hours if personal data was exposed. Notify legal and compliance immediately so they can make that determination.

Notify affected individuals if required. If the investigation confirms customer personal data was accessed, affected individuals may need to be notified.

Remediate and prevent. Audit all other S3 buckets for public access settings. Implement AWS Config rules to alert on publicly accessible buckets going forward. Review the IAM policies that allowed the bucket to be made public. Establish a process to catch this earlier — S3 public access reports, Macie for sensitive data discovery.

Post-incident review. Document what happened, why it was not caught sooner, and what controls will prevent recurrence. Do not assign blame — focus on the system failure that allowed this to exist undetected for three months.

What Makes a Candidate Stand Out on Security Questions#

Most candidates approach security defensively — “I would block this, restrict that, prevent this.” The candidates who stand out think like an attacker as well as a defender.

For example, when asked about IAM: instead of just saying “use least privilege,” mention that you think about what would happen if a specific role were compromised — what could an attacker do with those permissions? That framing shows security thinking is part of your architecture decision-making, not just a checklist.

Similarly, knowing common attack patterns — SSRF (Server-Side Request Forgery), which can be used to reach EC2 metadata and steal IAM credentials; confused deputy attacks in cross-account trust policies; S3 presigned URL abuse — signals that you have thought about your infrastructure from an adversarial perspective.

Cloud Engineer vs Cloud Security Engineer: Different Depth Expected#

A cloud engineer is expected to implement security controls correctly and flag security concerns in design reviews. They are not expected to perform threat modelling, conduct red team exercises, or write security policies from scratch.

A cloud security engineer goes deeper: they design the security architecture, conduct security assessments, lead incident response, and are responsible for the security posture of the environment as a whole.

If you are interviewing for a cloud engineer role, demonstrating that security is part of your thinking is what is expected. If you are interviewing for a cloud security engineer role, the questions above are the starting point, not the ceiling.