Cloud Security Interview Questions: Secure SDLC Practice
Reviewed by Mark Dickie · Last updated
6 questions on this page you can answer and see marked on the spot. Go to the first one
Secure SDLC in cloud security is the practice of embedding security controls and verification steps at every phase of the software development lifecycle, from design through deployment and operation. For interview preparation, expect questions on threat modeling (STRIDE, DAST/SAST integration), infrastructure-as-code security (Terraform policy scans, CIS benchmark compliance), secret management (Vault, AWS Secrets Manager rotation), and CI/CD pipeline hardening (signed commits, image scanning, least-privilege deployment roles). You should also be ready to discuss shift-left testing, SBOM generation, and how cloud-native controls like IAM policy boundaries and network segmentation map onto each SDLC phase.
The table below maps the core secure SDLC domains you are likely to be tested on:
| SDLC Phase | Security Activity | Common Cloud Tools |
|---|---|---|
| Design | Threat modeling, architecture review | OWASP Threat Dragon, Microsoft TMT |
| Build | SAST, dependency scanning, SBOM | Semgrep, Syft, Trivy |
| Test | DAST, IaC policy scanning | OWASP ZAP, Checkov, tfsec |
| Deploy | Image scanning, signed artifacts | Cosign, Trivy, AWS Inspector |
| Operate | Runtime monitoring, secret rotation | Falco, HashiCorp Vault, GuardDuty |
What does a secure SDLC interview in cloud security typically cover?
- Threat modeling frameworks and how to apply them to cloud-native architectures (containerized services, serverless functions, managed databases).
- IaC security: scanning Terraform and CloudFormation for misconfigurations before merge, enforcing CIS or NIST benchmarks as policy gates.
- Secret lifecycle management: where secrets live, how they rotate, and how to prevent them from leaking into source control or CI logs.
- CI/CD pipeline controls: branch protection, signed commits, container image provenance, and least-privilege deployment identities.
- Shift-left culture: how to make security findings actionable for developers without slowing delivery cadence.
How do cloud-native controls change the secure SDLC?
Cloud platforms let you enforce security as code rather than as a manual gate. IAM policies, network security groups, and KMS key policies can all be version-controlled, reviewed, and tested like application code. This means interviewers will probe whether you can treat infrastructure policy as a first-class artifact in the SDLC — versioned, tested in CI, and validated against compliance frameworks before it reaches production. Expect questions on policy-as-code tools (OPA, Sentinel) and how they fit into pre-merge and pre-deploy stages.
Use the quiz below to test yourself on these areas. Each question mirrors the format and depth of real cloud security interview rounds.
Key facts
- Tarmac has 37 Cloud Security interview questions on this topic, 10 of them on this page, at difficulty 1–5 of 5.
- Tarmac tracked 1,251 job postings asking for Cloud Security in September 2026.
- Roles asking for Cloud Security advertise a median base salary of US$177,500, across 232 job postings as of September 2026.
- Tarmac last reviewed these Cloud Security interview questions on 19 October 2026.
At a glance
| Questions | 10 shown · 37 in the bank |
|---|---|
| Difficulty | 1–5 of 5 |
| Formats | Multiple choice, Ordering, Multiple answer, Fill in the blank, True / false, Design exercise, Short answer, Flashcard |
What you'll review
- threat modeling in design
- shift left practices
Practice questions
Try one before you open the answer. Pick an option and press Check; it's marked on the spot.
What is the purpose of threat modeling during system design?#
Options
Show answer
Threat modeling during system design is the practice of identifying potential threats to a system and planning mitigations before any code is written. It asks what could go wrong, such as data exposure or spoofed identities, so security controls are built in early rather than bolted on after an incident.
Threat modeling is a design-stage activity: the team examines data flows, trust boundaries, and entry points to ask what could go wrong (for example, spoofed identities or exposed data) and decides on controls before code is written. Scanning deployed images for CVEs is vulnerability management, measuring uptime is reliability monitoring, and threat modeling complements rather than replaces code review and penetration testing.
Put the threat modeling steps for a new cloud service design into the order they should be performed, first to last.#
Put these in order
Show answer
The correct order for threat modeling a cloud service design is to draw a data flow diagram with trust boundaries, identify threats against each element and flow, choose mitigations for those threats, and then verify the mitigations are implemented and tested. Each step depends on the output of the previous one.
Threat modeling works from the design outward. The team first draws a data flow diagram with trust boundaries, because that diagram defines the elements and flows that can be attacked. Next, they identify threats against those elements and flows, for example by applying STRIDE categories. Only after threats are identified can they choose mitigations for them. Last, they verify that each chosen mitigation is actually built and tested, since a mitigation that is never implemented does not reduce risk.
In a secure software development lifecycle, what is the main purpose of threat modeling during the design phase?#
Options
Show answer
Threat modeling in design identifies potential threats and plans mitigations before any code is written. Teams map data flows and trust boundaries, then decide on controls such as authentication and encryption early, when changes are cheap. It complements, but does not replace, testing such as penetration tests.
Threat modeling is performed while the system is being designed. Its purpose is to enumerate what could go wrong (for example, who the attackers are, which data flows cross trust boundaries, and what could be abused) and to decide on controls such as authentication, encryption, or input validation before implementation. Finding binary memory bugs is a job for code analysis and fuzzing, measuring performance is unrelated to security design, and penetration testing is a complementary validation activity that cannot substitute for design-time analysis.
During design-phase threat modeling of a cloud service, a team classifies threats using the STRIDE model applied to a data-flow diagram. Select ALL items that are categories in the STRIDE model.#
Options
Pick every one that applies.
Show answer
STRIDE's categories are Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. Spoofing, Tampering, and Information disclosure all belong to it. Lateral movement is a MITRE ATT&CK tactic, and cross-site scripting is a web vulnerability class, so neither is a STRIDE category.
STRIDE is a threat-classification mnemonic whose six categories are Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. Spoofing, Tampering, and Information disclosure are all STRIDE categories and are the correct selections. Lateral movement is a tactic in the MITRE ATT&CK framework, which is an adversary-behavior catalog used for detection and red teaming rather than design-time classification. Cross-site scripting is a specific web vulnerability class, not a top-level STRIDE category, so it is not a valid selection.
During threat modeling of a design using the STRIDE framework, an attacker who modifies a message while it travels between two services is committing _____. An attacker who sends requests while pretending to be a legitimate user with a different identity is committing _____. Name the STRIDE category for each.#
Show answer
During threat modeling of a design using the STRIDE framework, an attacker who modifies a message while it travels between two services is committing tampering. An attacker who sends requests while pretending to be a legitimate user with a different identity is committing spoofing. Name the STRIDE category for each.
STRIDE maps each threat to a property it violates: Tampering violates integrity, so altering a message in transit (for example, between two services without message signing or TLS integrity protection) is tampering. Spoofing violates authentication, so an attacker impersonating another user or principal to gain access is spoofing. Because the two described attacks violate integrity and authenticity respectively, the two blanks map to different STRIDE letters and each has a single standard name.
In the STRIDE threat-modeling framework, encrypting data at rest is the primary control for mitigating the Repudiation threat.#
Options
Show answer
Encryption at rest does not primarily mitigate STRIDE's Repudiation threat. Repudiation is the risk that an actor can deny performing an action, and it is addressed with audit logging, tamper-evident records, and digital signatures. Encryption at rest instead targets Information Disclosure, protecting the confidentiality of stored data.
The statement is false. Repudiation is the threat that a user or component can deny having performed an action, so its mitigations are audit logging, tamper-evident records, and non-repudiation mechanisms such as digital signatures. Encryption at rest addresses Information Disclosure, the confidentiality threat to stored data, not the ability to deny an action.
True or False: Adding static application security testing (SAST) to the CI pipeline is a shift-left practice that makes a pre-release penetration test unnecessary, because SAST covers every class of vulnerability that a penetration test would find.#
Options
Show answer
Adding SAST to CI does not replace pre-release penetration testing. Shift-left practices catch many flaws earlier, but static analysis cannot find runtime, configuration, or business-logic weaknesses, so independent testing before release remains necessary.
The statement is false. Shift-left practices such as running SAST in CI move security checks earlier so flaws are caught before merge, which is valuable. However, SAST analyzes source code statically and cannot detect runtime behavior, deployment and configuration errors (for example, permissive cloud storage policies or missing security headers), or business-logic flaws such as broken authorization across workflows. Those classes are typically found by dynamic testing and penetration testing, so shift-left complements rather than replaces later-stage validation.
You are designing a serverless image-processing service on AWS. Users authenticate through Amazon Cognito and request a pre-signed S3 PUT URL from an API Gateway endpoint. They upload a JPEG or PNG directly to an S3 bucket. An S3 event triggers a Lambda function that resizes the image, writes thumbnails to a second bucket, and stores metadata (owner ID, file name, dimensions, status) in DynamoDB. Users fetch their results through a second API Gateway route that returns time-limited pre-signed GET URLs. The Lambda role has access to both buckets and the DynamoDB table.#
Show answer
Components and boundaries: The browser and Cognito sit outside the trust boundary. API Gateway is the first trusted entry point, where the JWT is validated. Pre-signed URL issuance is a trusted Lambda or API component. The client uploads directly to the upload bucket, which crosses a boundary because the client is untrusted. The S3 event invokes the processor Lambda, which reads the upload and writes to the thumbnail bucket and DynamoDB. Retrieval goes back through API Gateway, which issues pre-signed GET URLs.
Enumeration: I apply STRIDE to each data flow. On the upload path, spoofing covers a forged or replayed pre-signed URL. Tampering covers a changed content type or an oversized file. Information disclosure covers a user writing to another user's prefix. Denial of service covers very large uploads or decompression bombs. On the retrieval path, I look for information disclosure from long-lived GET URLs and elevation through an owner ID taken from the request body rather than the token.
Mitigations: Pre-signed PUT URLs expire within minutes and include conditions on content length, content type, and a key prefix built from the Cognito subject. The owner ID is read from the verified token, never from the body. The processor validates and re-encodes images before use and scans uploads with malware detection. The Lambda role is limited to the upload prefix, the thumbnail prefix, and DynamoDB items under the caller's partition. Both buckets enable Block Public Access and SSE-KMS, and access logging is on.
Prioritization: Cross-user access and forged uploads rank highest because the impact is data exposure and the likelihood is high from any authenticated user. Decompression bombs and malware come next. I accept a short replay window on pre-signed URLs, bounded by expiry, and a few minutes of scanning latency, both documented as residual risks.
Verification and maintenance: IaC policy checks reject public bucket settings and wildcard IAM actions in the pipeline. Integration tests attempt cross-user GET and PUT, oversized uploads, and wrong content types, and they must fail. The threat model is revisited whenever a new trust boundary appears, such as sharing links or third-party calls.
This is an open design exercise, so there is no single key. The rubric defines what a strong answer must contain: trust boundaries and data flows, a named threat-enumeration method applied to the upload path, cloud-specific mitigations tied to specific threats, risk-based prioritization, and a plan to verify and maintain the model. The sample answer covers each criterion so the rubric can score it.
A threat-modeling review of a multi-tenant SaaS API hosted on AWS finds this flow: the client calls GET /invoices/{invoiceId} with a valid JWT. The handler authenticates the token, then loads the invoice by invoiceId from DynamoDB and returns it, without checking that the invoice's tenant matches the tenant claim in the caller's token. Any authenticated customer can read other tenants' invoices by changing invoiceId. (1) Name this vulnerability using the OWASP API Security Top 10 (2023) category name or its standard abbreviation. (2) In one or two sentences, state the design-level control that should be placed in the data-access path to prevent it.#
Show answer
(1) This is Broken Object Level Authorization (BOLA, OWASP API1:2023). Authentication succeeds, but the server never authorizes access to the specific object. (2) The control is a server-side ownership check in the data-access path: derive the tenant from the verified token claims (never from client input), and enforce it in the query itself (e.g., a DynamoDB key condition on tenant ID plus invoice ID, or a conditional check), returning 404 for objects outside the caller's tenant.
The flaw is that authentication is performed but object-level authorization is missing: the handler trusts a client-supplied identifier to select a record and never verifies that the record belongs to the caller. OWASP's API1:2023 category, Broken Object Level Authorization (BOLA), describes exactly this pattern, and IDOR is the older, related name. The correct design control is to enforce ownership in the data-access layer, deriving the tenant from the verified token rather than from request input, so that the query cannot return another tenant's record even if the identifier is guessed or changed.
In a cloud threat model, what is the 'confused deputy' problem, and how does it appear in cross-account IAM role design? Name the standard AWS trust-policy conditions used to mitigate it.#
Show answer
The confused deputy problem occurs when a privileged service or role (the deputy) is induced by a less-privileged party to use its own authority against a resource that party should not be able to reach, because the deputy cannot tell who truly asked. In cross-account IAM design, a third-party or other-account principal that is allowed to assume a role can trigger that role on behalf of a different customer. Mitigations: require an unguessable sts:ExternalId in the role's trust policy condition, and for service principals scope the trust with aws:SourceAccount and aws:SourceArn so only the intended resource can invoke the role.
The threat is an authority-misuse flaw, not a credential theft: the deputy holds legitimate permissions and is tricked into exercising them for the wrong caller. A threat model should therefore flag every trust-policy grant that lets a principal outside the owner's control reach a privileged role. The fix is to bind the trust decision to information the attacker cannot supply, which is what sts:ExternalId (a secret shared only with the legitimate customer) and the aws:SourceAccount/aws:SourceArn condition keys (which identify the calling account and resource) provide. Such conditions are the design-level controls a reviewer should verify, since the deputy's own code cannot distinguish the confused request.
Related interview questions
Job market
See cloud-security salaries and hiring demand from live job postings.
The other 27 questions
This page shows 10 and marks what you pick. That's as far as a page can go. A free account opens the other 27 and keeps every answer. What you miss comes back until it's right: after a day, then at longer gaps.
Free · the whole bank · 100 marked answers per 30 days · written feedback on the paid plan