Cloud Security Engineer Interview Questions

"I started as a systems engineer moving a few internal apps into the cloud. During that move I noticed how easy it was to get things badly wrong, like a storage bucket opened up for a quick test and never closed again. I started writing small checks to catch those mistakes, and the security team began asking me to help them. That's when it clicked for me. In the cloud, most security problems are configuration problems, and configuration is code, so you can fix them at scale if you think like an engineer. General security felt too far from the build, and pure infrastructure work didn't let me focus on risk. This role sits exactly in the middle, which is where I'm happiest."

"Most of my hands-on work is on AWS, about three years. I've set up the organisation-wide audit trail into a separate log account, turned on the threat detection service across every account and routed its findings to our ticketing system, and written service control policies for things like blocking unused regions. I've also written a lot of IAM policies and trust policies for cross-account roles. On Azure I'm lighter: I've worked with Defender for Cloud recommendations and Azure Policy assignments on one project, but I haven't designed a tenant from scratch. The concepts carry over well, so if your main platform is different, I'd start by mapping identity, logging and guardrails to what I already know, then fill the gaps in a sandbox."

"In the first couple of weeks I'd build a picture of the estate: how many accounts or subscriptions there are, who owns each one, what's reachable from the internet, and where customer data lives. Then I'd look at the few things that cause most real breaches: who has admin, whether there are long-lived keys, whether anything sensitive is public, and whether audit logs are on everywhere and stored somewhere safe. I'd also sit with a couple of product teams to see how they deploy, because the fixes need to fit their workflow. What I'd avoid is rolling out broad deny guardrails or auto-remediation in my first month. If I don't know the estate, I could break production and lose trust I haven't earned yet. The one exception is something actively exposed, which I'd raise straight away."

"I'd agree the provider takes on a lot. They run the data centre, the hardware, the host operating system, and they patch the database engine, though you often pick the maintenance window. But the team still owns everything about how the database is used. They decide whether it's reachable from the internet or only from private subnets, and which security groups can connect. They own the database users and passwords, or the identity-based login if they use it. They choose whether to use a customer-managed encryption key, whether to force encrypted connections, how long backups are kept and who can restore or share a snapshot. And they own the data itself and who in the company can see it. Honestly, when managed databases leak, it's almost always one of those customer settings, not the provider's part."

"I'd stop reading the list by severity label, because a critical finding on an empty sandbox matters less than a medium one on a public service holding customer data. First I'd filter for combinations that lead to real harm: internet-exposed resources with known exploitable flaws, public storage or snapshots, admin roles attached to exposed machines, and missing logging in production. That's usually a small list and we fix it this week. Then I'd group the rest by root cause. Often hundreds of findings come from one shared infrastructure module, so one fix closes them all. Everything gets routed by account and owner tags to the right team with a due date based on risk. Accepted risks get recorded with an owner and an expiry, not just muted. And I'd add checks in the deployment pipeline so the same misconfigurations stop arriving."

"First I'd map the control to what we actually do, because the same access review usually satisfies several frameworks at once, like ISO 27001, SOC 2 or PCI DSS, plus any local data protection rules. Then I'd show two things. Design: production access only comes through identity provider groups mapped to roles, and a config check proves there are no local cloud users or long-lived keys in production accounts. Operation: for each quarter, an export of who was in each group, the review ticket showing who approved it and when, and proof that the people flagged for removal were actually removed. I'd rather collect this automatically every quarter into one evidence folder, so the audit is a matter of handing over what's already there. If a quarter was missed, I'd say so honestly and show the fix."

"I'd start by owning it. Their site broke because of my change, and our rollout should have caught that case. Then I'd offer a fix that restores the site without making the bucket public again: put a CDN in front of it and give only the CDN access to read from the bucket. It's usually a short change, it's faster for their users, and I'd pair with them on it right away. If that couldn't be done today, I'd grant a time-limited exception on just that bucket, recorded with an expiry, because a dead website for a day is a bad trade for a bucket that only holds public pages. After that, I'd search for other buckets serving websites before they break too, and change our process to warn teams earlier and test new controls against real workloads first."

"At my last company I was reviewing security group rules and noticed a database in a staging account allowed connections from anywhere on its port. Staging sounded harmless, but when I checked, it had been restored from a production backup a few months earlier, so it held real customer records. I messaged the team lead directly rather than just filing a ticket, showed him the rule and what was in the database, and we closed the rule within the hour. Then I checked the database's connection logs with him and found no connections from outside our own addresses, which was a relief. Afterwards I added a check to our pipeline that fails any change opening a database port to the internet, and we agreed that restoring production data into staging needs masking first."

"In my last role I rolled out a rule that stops anyone creating storage with public access across about 40 accounts. Before enforcing anything, I ran it in audit-only mode for two weeks, which showed us every existing public bucket and every deployment that would have been blocked. That found six buckets that were public on purpose, mostly website assets, so we moved those behind a CDN first. Then I enforced it on sandbox accounts, then dev, then production in two waves, each announced a week ahead with a short guide on what to do if something was blocked. One team still hit a problem with an old deploy script, and because we had an exception process ready it took an hour to sort. Since then, no new public buckets. Next time I'd involve a couple of product engineers in writing the guide."

"I'd start with single sign-on from the company identity provider, so nobody has cloud users or long-lived keys of their own, and leaving the company removes their access everywhere. Developers get groups that map to roles per environment: fairly broad rights in their dev account, read-only in production so they can see logs and metrics and debug. Changes to production go through the deploy pipeline, and that pipeline's role is the only one that can modify production resources, with a trust policy that only the pipeline can use. For emergencies there's an elevated role you request for a few hours with an approval, which pages the security channel and gets reviewed afterwards. On top of that, I'd put guardrails at the organisation level so even an admin can't turn off logging. Then a quarterly review of who's in which group."

"I wouldn't guess. First I'd look at what the role actually does. Most clouds show when each service was last used by a role, and the audit log shows the exact API calls, so I'd collect at least a month or two of activity to catch monthly jobs and batch runs. Some providers can even generate a starting policy from that activity. From there I'd write a policy with just those actions, scoped to the specific buckets, queues or tables rather than every resource. I'd deploy it in staging, run the full test suite, then roll it to production with an alert on any access-denied errors from that role for the first couple of weeks. And I'd keep the old policy ready to reattach in minutes, and agree that plan with the owning team before I start."

"We create a role in our account whose trust policy says the vendor's account may assume it. The vendor calls the token service, gets short-lived credentials for our role, and works with whatever permissions we attached, ideally read-only. No keys ever change hands. The confused deputy problem comes from the vendor serving many customers. If an attacker is also a customer, they could type our role's identifier into their own settings, and the vendor, acting with its own trusted identity, would assume our role on the attacker's behalf. The fix is an external ID: the vendor generates a unique value for each customer, we put it as a condition in our trust policy, and the vendor always sends the ID belonging to whoever made the request. Then the attacker's request carries the wrong ID and fails. The vendor must generate it, not let customers pick it."

"A role's policy grants actions to that role. A guardrail at the organisation level, like a service control policy, does the opposite job: it never grants anything, it sets the ceiling for every identity in the member accounts it covers, including the account's own admins and root user. So even if someone makes themselves admin in a member account, they still can't do what the guardrail denies. I use them for a short list of things that should never happen: turning off or deleting the audit trail, disabling threat detection, leaving the organisation, and using regions we don't operate in. Sometimes also blocking public access settings from being turned off. I keep them few and simple, add an exception condition for a dedicated security role, and always try them on a sandbox part of the organisation first, because a bad deny breaks everything below it."

"Only the load balancer would be public, ideally with a web application firewall in front. The web servers, the API and the database all sit in private subnets with no public addresses. Then I'd chain the security groups: the web group accepts traffic only from the load balancer's group, the API group only from the web group on its one port, and the database group only from the API group on the database port. Referencing groups rather than IP ranges means it keeps working as instances scale. So if a web server is compromised, the attacker can reach the API, but not the database directly and not anything else in the network. I'd also give each tier its own role with only the permissions it needs, use private endpoints for storage so that traffic never touches the internet, and turn on flow logs to catch anything odd."

"Every virtual machine can call a special link-local address, 169.254.169.254, to read its own configuration, and if it has a role attached, to fetch temporary credentials for that role. Server-side request forgery is when an attacker makes your app fetch a URL of their choosing, say an image-preview feature. If they point it at the metadata address, the app fetches the role's credentials and hands them back, and now the attacker can call the cloud API as your server. The fixes are layered. On AWS I'd enforce the token-based version of the metadata service, which needs a PUT request with a special header first, something most SSRF bugs can't send; other clouds require a special header too. I'd keep the instance role minimal, validate and allow-list outbound URLs in the app, and block unneeded egress. And I'd alert when those credentials are used from outside our environment."

"I'd be clear that SSH open to the whole internet isn't something we'll do on production. Anything on port 22 gets scanned and brute-forced within minutes, and one weak key or unpatched daemon is all it takes. But I'd take the complaint seriously, because a bastion people hate is a bastion people work around. I'd ask what's actually slow. Often the better answer is the provider's session manager or identity-aware access, where engineers connect through their normal single sign-on, there's no inbound port open at all, and every session is logged. I'd offer to help set that up with them this week. If they truly need access today, I'd open a narrow rule from the company VPN range only, with an expiry and a named owner, and close it once the new route works."

"The KMS holds a master key that never leaves it. When I want to encrypt a file, I ask the KMS for a data key. It gives me two copies: one in plain form and one encrypted under the master key. I encrypt the file locally with the plain data key, throw that plain key away, and store the encrypted data key next to the file. To decrypt, I send the encrypted data key back to the KMS. It checks that I'm allowed to use the master key, logs the request and returns the plain data key, and I decrypt locally. You don't send all the data to the KMS because it only encrypts small payloads directly, and pushing gigabytes through an API would be slow and costly. Envelope encryption keeps the bulk work local while access control and the audit trail stay in one place."

"It should live in the cloud's secrets manager, and the app should read it at startup or on a short cache using its own role, so there's no password in the code, the container image or a config file. Access to that secret is limited to that one role and every read is logged. For rotation, the key is ordering. You create the new credential and make it valid in the database first, then update the secret, then give the apps time to pick it up, and only then disable the old one. A common pattern is two database users that take turns: while one is active, the other gets its new password. Apps need to retry with a fresh secret if a login fails. Where the managed database supports it, I'd rather skip passwords entirely and use short-lived tokens from the cloud identity."

"I'd check before agreeing, because test data is very often a copy of production. I'd look at which database the snapshot came from and, with the owner, look at a sample of the tables for real names, emails or payment details. Then I'd ask why it needs to be public at all. Usually it's shared with a partner or another account, and that can be done by sharing with that specific account instead. If it really is synthetic data and there's a real reason, I'd record a formal risk acceptance signed by the owner, with an expiry date, rather than silently suppressing the finding. If it turns out to contain real customer data, it's an incident, and I'd make it private first and then check who could have copied it. Longer term, a guardrail that blocks public snapshot sharing unless an exception is approved."

"The first thing is the audit trail of API calls, turned on for every region, ideally at the organisation level so new accounts get it automatically. That tells you who did what to your cloud resources. Next I'd turn on the provider's threat detection service, then network flow logs, DNS query logs, and data-access logging on buckets or databases that hold sensitive data, because the default audit trail usually doesn't record every object read. To protect them, I'd send everything to a separate log archive account that almost nobody can log in to, with write-once retention so even an admin can't delete logs early. Then I'd add a guardrail so no one in the workload account can stop the trail, and an alert that fires if anyone tries."

"It tells me the credentials that should only ever be used from that instance have left it, so either the instance is compromised or the app leaked them, often through SSRF against the metadata service. First I'd cut access. Temporary credentials can't be deleted, so I'd revoke active sessions for the role, which adds a deny for any session issued before now. The stolen ones stop working at once. The instance's own copy is blocked too until it fetches new ones, so I'd warn the owning team to expect errors. I'd snapshot the instance's disks and isolate it with a restrictive security group for forensics rather than terminating it. Then I'd search the audit log for every call made with that session: what was listed, read or created, especially new users, keys or roles for persistence. Finally, root cause: check the app for SSRF, enforce token-based metadata, and shrink the role's permissions."

"First I'd record the bucket's current policy and settings for evidence, then block public access straight away. Next, open an incident and bring in the data owner, legal and privacy that same day, because notification rules differ by country and some have tight deadlines. The EU's GDPR, with 72 hours to tell the regulator, is one example. Then I'd investigate two things. Who made it public and when, which the audit trail shows from the policy or access change. And whether anyone actually read the data. That depends on whether access logging or data-event logging was on. If it was, I'd look for reads from outside our own addresses. If it wasn't, I'd say plainly that we can't rule out access, and legal needs to know that. I'd also list what's in the bucket and whose data it is. Finally, turn on account-wide public-access blocking with a guardrail so it can't recur."

"I'd treat it as an attack until proven otherwise, because turning off logging is a classic first move. Step one, turn the trail back on, which takes a minute. Step two, find who did it. The stop call itself was recorded, so I'd see the identity, source IP and time. Then I'd check whether that fits a known change. If there's a planned change ticket and the IP is ours, it may be a mistake, and I'd still confirm with the person. If not, I'd disable that user's access or revoke that role's sessions right away, then look at everything that identity did around that time, especially new users, keys, roles or opened security groups. I'd also check other logs the attacker can't touch, like the organisation-level trail. And I'd page the incident lead instead of working it alone. Afterwards, a guardrail so no one below the security role can stop logging."

"At my last company our billing alert fired because compute spend in a dev account had jumped overnight. I was on call for security, so I took it. The audit trail showed that an access key belonging to a developer's old test user had been used from an unfamiliar IP to launch large instances in three regions we never use. They were mining crypto. I disabled the key, terminated the instances after snapshotting one for analysis, and searched the logs for anything else the key had done. It had also created a new user, which we deleted. The key had been pasted into a public code snippet months before. Afterwards we removed every long-lived key for human users, moved people to single sign-on, and added a guardrail blocking regions we don't use, which alone would have limited that attack."

"I'd start with who can reach the cluster: restrict the API endpoint to private networks or known ranges, turn on audit logging, and keep cluster-admin for a tiny group, with teams getting roles only in their own namespace. Each team gets a namespace with a default-deny network policy, then explicit allows, which needs a network plugin that actually enforces policies. I'd label namespaces to enforce the restricted pod security level, so no privileged pods, no host paths, and containers run as non-root. For cloud access, each workload should get its own identity mapped to a cloud role, and pods should be blocked from reaching the node's metadata credentials, otherwise every pod inherits the node's permissions. Finally, admission rules to only allow images from our registry, and Kubernetes secrets encrypted with a KMS key."

"I wouldn't just say yes or no. A privileged container can see and change almost everything on the node, so if that agent is compromised or has a bad update, every workload on that node is exposed, including other teams'. So first I'd ask what the agent actually needs. Monitoring agents usually need to read host metrics, some log paths, maybe one or two Linux capabilities. Many vendors document a reduced setup, and I'd ask the vendor directly if not. Then I'd run it in its own namespace with exactly those capabilities, read-only host mounts, and a pinned image from our registry. That namespace gets a documented exception from the restricted pod policy, and every other namespace stays restricted. If it truly needs full privilege, I'd want the vendor's security review and a plan to replace it if one appears."

"At my last company most of our services shared one cloud account, and every engineer had broad admin in it. I needed two engineers for most of a quarter to split it into separate accounts. The head of product didn't care about accounts, so I explained it as: right now one stolen laptop could take down every product we sell and expose all customer data at once. Then I showed a simple picture of how separate accounts would contain that to one product. I also offered a smaller first step, moving just the payments service first, so she could see the cost and the disruption were manageable. She agreed to that first step, it went smoothly, and the rest of the split got scheduled over the next two quarters."

"We had a finding that an older internal service used a shared database password instead of per-service identities. Fixing it properly meant a code change in a service that was due to be replaced in about four months, and the team was in the middle of a major release. The database was only reachable from that one service's private subnet, and the password was already in the secrets manager with access logged. So I judged the risk as low for a few months. I wrote it up as an accepted risk with the service owner and my manager signing it, listed the controls that reduced it, and set a review date for the end of the quarter. When the date came, the replacement had slipped, so we did a simpler fix, rotating the password and narrowing its database rights, rather than just extending the exception."

"I want engineers to see us as the people who make the secure way the easy way, so they come to us early instead of hoping we don't notice. Personally, I try to earn that in a few ways. I build and maintain secure templates, like a storage module that's private and encrypted by default, so doing the right thing takes less effort than doing it by hand. When I have to block something, I explain the actual risk and offer another way to get what they need, and I try to answer requests quickly because a slow security team gets bypassed. When a team fixes something well, I say so publicly. And I never name and shame people for mistakes in open channels. That builds the trust you need when something is really urgent."

"I'd say it early and plainly: I reviewed and approved that change. Hiding it only slows everyone down and hurts trust later. During the incident I'd put my energy into helping contain it, since I probably know that change well. Afterwards, in the review, I'd look at why I missed it. Maybe the review checklist didn't cover that kind of setting, maybe the diff was too big to review properly, or maybe I didn't know how that service behaved. Then I'd push for a fix that doesn't rely on me being more careful next time, like an automated policy check in the pipeline for that exact setting. I wouldn't blame the author either. We both missed it, and the process should catch what people miss."