Cloud Security Engineer interview questions

No. Cloud runs on a shared responsibility model: the provider secures the underlying infrastructure ('security of the cloud'), but you remain responsible for your data, identity and access management, configuration, and — for IaaS — the OS and patching ('security in the cloud'). The large majority of cloud breaches are customer-side misconfigurations like public buckets and over-permissive IAM, not provider failures. Assuming the provider secures your data is how those breaches happen.

No. NAT (and PAT) maps private addresses to a public IP and, as a byproduct, drops unsolicited inbound connections because no mapping exists for them. That's not a security policy — there's no inspection, no rules, no logging — and NAT traversal, hole punching, and outbound-initiated C2 pass right through. NAT is an addressing tool; you still need an actual firewall. 'NAT = firewall' is the misconception.

A third-party model is a supply-chain dependency: verify it comes from a trusted source with matching checksums/signatures, that its license permits your use, and that the file format won't execute arbitrary code on load (prefer safe serialization over pickle-style formats). 'It loads' and 'download speed' say nothing about trust, and assuming public models are safe ignores real poisoning and deserialization risks.

SSLv3, TLS 1.0, and RC4 are broken or deprecated and enable downgrade and decryption attacks, so disable them and require TLS 1.2 or 1.3 with strong, forward-secret cipher suites — accepting the rare loss of very old clients. Leaving them on for compatibility keeps the weakness exploitable. Adding a second certificate or switching to a self-signed one doesn't remove the weak protocols, and self-signed certs harm trust without fixing the cryptography.

Unused, over-privileged service accounts are prime targets and a large attack surface. Inventory them, disable or delete the unused ones (watching for breakage), right-size the survivors to least privilege, and give each an owner plus a recurring review. Leaving them is standing risk, granting blanket admin maximizes blast radius, and consolidating onto one shared account destroys least privilege and accountability.

Because firewalls evaluate rules top-down, a broad any/any allow near the top short-circuits every rule below it and permits all traffic — the firewall effectively stops enforcing anything. Replace it with explicit least-privilege rules for the flows actually needed, ordered so specific allows and denies take effect, ending in a default deny. Calling it efficient is wrong, moving it to the bottom can still shadow the default deny, and renaming changes nothing about what it permits.

Without control-plane audit logs you're blind to who did what at the cloud layer, and detection, forensics, and compliance all depend on that record. Enable CloudTrail immediately, org-wide, delivering to a separate, access-controlled, tamper-resistant (immutable) bucket. Saying it doesn't matter while nothing is wrong ignores that you'd have no history when something does go wrong. Waiting until an incident means the formative early actions are already unlogged and unrecoverable. Application logs don't capture API, IAM, or console activity at the control plane.

Management ports open to the whole internet are scanned and brute-forced within minutes, so the fix is to shrink the attack surface: restrict the security-group ingress to known admin CIDRs or VPN, or remove inbound entirely using a bastion or SSM Session Manager. Moving SSH to a non-standard port is security by obscurity that scanners defeat trivially. A stronger password doesn't reduce the exposed surface or stop credential-stuffing. Trusting a host firewall ignores the attack surface the security group is openly advertising to the internet.

Public customer data is an active exposure, so remediate access first: enable Block Public Access and correct the bucket and IAM policy to stop ongoing leakage. Then pull access logs (S3 server access logs / CloudTrail data events) to assess what was actually reached, and trigger breach and notification processes per policy. Ticketing it for next sprint leaves regulated data exposed for days. Copying the data elsewhere creates a second copy but leaves the original bucket open. Renaming changes nothing about its permissions.

Secrets belong in a managed store with access control, audit, and rotation, injected at runtime — never committed to source control. Use a secrets manager (AWS Secrets Manager, HashiCorp Vault) and remove the committed values from history, then rotate them because they must be treated as compromised. Base64 is encoding, not protection — anyone can decode it. A private repo still spreads the secret to everyone with clone access plus CI systems and forks. Compiling it into the binary just hides a secret that's still trivially extractable.

A static key baked into an image leaks easily and lives forever, so the fix is to eliminate the long-lived credential entirely: attach an IAM role via an instance profile, which delivers short-lived, automatically rotated credentials with nothing embedded. Manual 90-day rotation still leaves a long-lived secret sitting in the AMI between rotations. Moving the key to an environment variable doesn't make it any less static or any less leaked. Emailing it to ops spreads the exposure to mailboxes and archives.

The manual console change is configuration drift: the next terraform apply can silently revert the fix, and the change also bypassed peer review and audit. Reconcile it by codifying the change in Terraform, running plan/apply so code and reality match, and adding guardrails against ad-hoc console edits (least-privilege console access, SCPs, drift detection). Doing nothing leaves a landmine for the next apply. Deleting the Terraform state is destructive and can orphan or duplicate resources. Abandoning Terraform throws away reproducibility, review, and audit trails.

An over-privileged instance role turns any application-level flaw — notably an SSRF that reaches the instance metadata service — into full-account takeover, because the attacker inherits the role's credentials. Replace the wildcard with the minimal actions and resource ARNs the workload actually uses, and require IMDSv2 to harden the metadata endpoint. A VPC doesn't constrain IAM at all. A single deny rule is whack-a-mole that leaves everything else permitted. A load balancer is irrelevant to the credential's blast radius.

Least privilege plus just-in-time access: grant the minimum permissions needed, time-boxed and logged, so debugging is possible without standing admin that becomes a permanent risk and audit gap. Permanent cluster-admin violates least privilege and widens the blast radius of any compromise. A blanket denial blocks legitimate work and invites risky shadow workarounds. Sharing the common admin service-account credential destroys accountability — actions can't be traced to a person.

Treat any pushed secret as burned: revoke and rotate it first, because bots scrape public commits within seconds, then review CloudTrail for misuse and purge it from history. Deleting the commit doesn't help — the key is already cloned, forked, and cached by third parties. Making the repo private leaves a live, already-leaked key in attackers' hands. Adding the file to .gitignore does nothing for a secret that is already committed.

Start from a minimal, trusted base image (distroless or slim) to shrink attack surface, scan images for known CVEs in CI and in the registry, pin and verify image digests, run as a non-root user, and avoid baking in secrets. Sign images and enforce admission policies so only scanned, signed images run. Rebuild regularly so patched base layers flow through.

Encryption in transit (TLS) protects data moving over the network from eavesdropping and tampering; enforce TLS everywhere and reject plaintext. Encryption at rest protects stored data on disks and backups, typically via KMS-managed keys using envelope encryption. Both are baseline controls, but neither stops an authorized-but-malicious request — the service decrypts transparently for valid callers — so access control still matters most.

A user is a long-lived identity with permanent credentials; a role is an identity with no permanent credentials that any trusted principal can assume to get short-lived tokens; a policy is the JSON document that grants permissions, attached to either. Least privilege means preferring roles over users, scoping policies to specific actions and resources, and granting only what a task needs — then reviewing and pruning over time.

IMDS is a link-local endpoint (169.254.169.254) that gives an instance its metadata, including temporary credentials for its attached IAM role. SSRF can trick the server into fetching that URL and leaking those credentials. IMDSv2 requires a PUT to obtain a short-lived session token, sets a default IP TTL/hop limit of 1, and rejects requests with certain headers — so a simple SSRF GET can no longer reach it.

RBAC controls what identities can do against the Kubernetes API — Roles and ClusterRoles grant verbs on resources, bound to subjects via RoleBindings — and should follow least privilege, avoiding cluster-admin and wildcards. Network policies control pod-to-pod traffic, which is allow-all by default until you apply a default-deny and then explicitly permit required flows. Together they limit blast radius if a pod or token is compromised.

CloudTrail records every API call in the account — who did what, when, from where — giving you the authoritative audit trail for investigations and compliance. GuardDuty is a managed threat-detection service that analyzes CloudTrail, VPC flow, and DNS logs to surface findings like credential exfiltration or crypto-mining. CloudTrail is the source of truth you must protect; GuardDuty turns that telemetry into actionable alerts.

The classic mistakes are public ACLs or bucket policies that allow anonymous or all-AWS-users access, overly broad principals or wildcard actions, no default encryption, and no logging. Prevent them by enabling account-level Block Public Access, using IAM/bucket policies with least privilege, enforcing default encryption and TLS, and turning on access logging and Config rules to catch drift.

Store secrets in a dedicated managed service (Secrets Manager, Parameter Store, Vault), encrypted with a KMS key, and grant access through IAM roles so workloads fetch them at runtime with short-lived credentials. Never bake secrets into code, container images, or committed .env files. Add automatic rotation, scoped key policies, and audit logging so every retrieval is traceable.

Security groups are stateful firewalls attached to instances/ENIs: they allow rules only, and return traffic for an allowed flow is automatically permitted. Network ACLs are stateless filters at the subnet boundary: they have ordered allow and deny rules and you must explicitly allow return traffic on ephemeral ports. Security groups are the primary control; NACLs add coarse subnet-level guardrails like blocking an IP range.

The provider secures the cloud itself — physical data centers, hardware, the hypervisor, and the managed services they run. You secure what you put in the cloud — your data, identities, configurations, OS patching where applicable, and access controls. The exact line shifts: with IaaS you own the OS up, with SaaS you mostly own data and access.

CI/CD is high-value because it holds deploy credentials and runs untrusted code. Risks include compromised dependencies and build actions, leaked or over-broad secrets, mutable third-party actions, and over-privileged runners or OIDC trust. Reduce them with pinned and verified dependencies, short-lived OIDC federation instead of long-lived keys, least-privilege scoped to specific repos/branches, isolated ephemeral runners, and signed, provenance-tracked artifacts (SLSA).

The app redirects the user to the authorization server to log in and consent. The server redirects back with a short-lived authorization code. The app's backend then exchanges that code (plus its client secret) at the token endpoint for an access token, over a server-to-server back channel. This keeps tokens out of the browser/URL. Public clients add PKCE to bind the code to the original requester.

SSO centralizes authentication at an Identity Provider (IdP). When a user visits a Service Provider (the app), the app redirects to the IdP; the user logs in once, and the IdP returns a signed assertion or token vouching for their identity. SAML carries this as a signed XML assertion; OIDC carries it as a signed JSON ID token layered on OAuth 2.0. The app trusts the IdP's signature rather than handling passwords itself.

Signing cryptographically binds an artifact to its producer so consumers can verify it wasn't tampered with or swapped. Provenance is signed metadata describing how, where, and from what source the artifact was built. Together — via tooling like Sigstore for keyless signing and the SLSA framework for provenance levels — they let a deployer verify an image came from the expected pipeline and source, defeating tampering and dependency-substitution attacks.

Scan images for known CVEs in OS packages and app libraries, plus misconfigurations and embedded secrets, both at build time and continuously in the registry — because new CVEs appear after an image is built. Use minimal or distroless base images to shrink the attack surface, pin and digest-reference base images, and run the container as non-root. Scanning is necessary but doesn't replace runtime protection.

IaC scanning statically analyzes Terraform, CloudFormation, Kubernetes, and similar definitions against policy to catch misconfigurations — public S3 buckets, open security groups, missing encryption — before they're ever provisioned. Because the same template provisions many resources, fixing it once prevents repeated drift, and catching it pre-apply is far cheaper than remediating live cloud resources. Tools include Checkov, tfsec, and KICS, ideally enforced as policy-as-code gates.

Treat the pipeline as production infrastructure: it holds the credentials to ship code and reach prod, so compromising it bypasses every downstream control. Harden it with isolated, ephemeral runners; least-privilege, short-lived tokens (OIDC federation instead of long-lived secrets); protected branches and reviewed pipeline config; pinned third-party actions by digest; and full audit logging. The pipeline is a top-tier target, not plumbing.

An SBOM is a machine-readable inventory of every component, library, and dependency in a piece of software, with versions and ideally hashes. It matters because when a new vulnerability drops, you can query your SBOMs to instantly answer 'are we affected and where?' instead of scrambling. The two dominant standards are SPDX and CycloneDX, and SBOMs are increasingly required by regulation and procurement.

Least privilege means every user, process, and service gets only the minimum access required for its task, and nothing more. It limits the blast radius of a compromised account, reduces insider-threat risk, and shrinks the attack surface. You apply it via role-based access, regular access reviews, and just-in-time elevation.

MFA requires two or more authentication factors from different categories — something you know (password), something you have (phone/token), something you are (biometric). It helps because an attacker who steals one factor, like a password, still can't log in without the others. Phishing-resistant MFA like FIDO2 is strongest.

A firewall controls traffic between network zones by allowing or denying it based on rules. A stateless firewall evaluates each packet in isolation against rules; a stateful firewall tracks the state of connections so it can allow return traffic for sessions it permitted. Next-gen firewalls add application-layer awareness.

Conditional access makes the access decision depend on context rather than a fixed rule. It evaluates signals — who the user is, device compliance, location, the app, and a computed risk score from anomaly detection — and responds proportionally: allow, block, or require step-up like MFA or a compliant device. Risk-based access is the dynamic variant where a real-time risk signal drives the policy.

Identity federation establishes trust between an identity provider (IdP) that authenticates users and service providers (relying parties) that consume that authentication. The IdP verifies the user and issues a signed assertion or token; the service provider trusts it instead of managing its own credentials. This enables cross-domain SSO and centralized control, but concentrates risk: compromise the IdP and you compromise everything that trusts it.

Just-in-time access grants elevated privileges only when needed, for a limited time, usually with approval — then they expire automatically, so there's no standing privilege to steal. Break-glass accounts are the deliberate exception: highly privileged emergency accounts, normally dormant, locked behind strict controls and heavy alerting, used only when normal access paths fail. JIT shrinks the everyday attack surface; break-glass guarantees you can still get in during a crisis.

RBAC grants permissions through roles assigned to users — simple to reason about but prone to role explosion as edge cases multiply. ABAC evaluates policies over attributes of the user, resource, action, and environment, so it scales to fine-grained, context-aware decisions at the cost of complexity. Most mature systems layer them: roles for coarse grants, attributes and policy for the conditional details.

SCIM (System for Cross-domain Identity Management) is a standard REST/JSON API and schema for creating, updating, and deleting user accounts across applications. Wired to an HR system or IdP, it automates the joiner-mover-leaver lifecycle: accounts and entitlements are provisioned on hire, adjusted on role change, and — most importantly — deprovisioned on departure, eliminating the orphaned accounts attackers love.

Keep access tokens short-lived (minutes) so a stolen one expires fast, and use longer-lived refresh tokens to get new access tokens without re-prompting the user. Rotate refresh tokens on every use and detect reuse of a consumed token as a theft signal, revoking the chain. The goal is to balance limiting the window of a compromised token against not forcing users to re-authenticate constantly.

Zero Trust drops the assumption that being inside the network makes you trusted. Every request to a resource is authenticated and authorized on its own merits — verifying identity, device health, and context — by a policy decision point, granting least-privilege access per session. There is no trusted internal zone; the network location of a request is just one signal, not a free pass.

Reduce attack surface (remove unused packages/services), enforce key-only SSH with no root login, keep the system patched, run a default-deny firewall exposing only needed ports, apply least privilege via sudo and file permissions, enable auditd and centralized logging, and add integrity monitoring plus MAC like SELinux or AppArmor.

Least privilege means every user, process, or service gets only the minimum access required to do its job, and nothing more. It shrinks the blast radius of any compromise or mistake. You enforce it with role-based access, just-in-time elevation, regular access reviews, and removing standing admin rights.

Never hardcode secrets in source or commit them to git. Store them in a dedicated secrets manager or vault, inject them at runtime, scope access with least privilege, rotate regularly, and prefer short-lived dynamic credentials over long-lived static ones. Audit every access.

Enforce TLS everywhere, authenticate every request (e.g. OAuth2/OIDC tokens), and authorize per-object so users can only reach their own data. Add input validation, rate limiting and quotas, schema validation, and thorough logging. The most common API flaw is broken object-level authorization, so check ownership on every resource access.

Segmentation divides a network into isolated zones so a breach in one can't freely reach others, limiting lateral movement. Zero trust goes further: it removes implicit trust based on network location entirely, authenticating and authorizing every request regardless of where it originates — microsegmentation is one way to implement it.

SSRF tricks a server into making HTTP (or other) requests to a destination the attacker chooses, abusing the server's network position to reach internal services behind the firewall. In the cloud it is especially severe because the instance metadata service (e.g. 169.254.169.254) can hand back IAM credentials, turning an SSRF into cloud account compromise.