Microsoft Penetration Tester (Mid-Level) - Comprehensive Interview Preparation Guide

Direct answer

A secure continuous integration and continuous deployment (CI/CD) pipeline for cloud deployments earns trust the same way a supply chain does: every artifact that reaches production must be traceable to a specific, scanned, signed build, and every credential the pipeline uses must be short-lived and scoped to exactly the step that needs it. The design below covers each of the six requested elements: secret storage and injection, ephemeral runners with OpenID Connect (OIDC) tokens, artifact signing and verification, software composition analysis (SCA) and static application security testing (SAST) integration, approval gates, and least-privilege deployment permissions.

Structured elaboration

flowchart TB
    Dev["Developer push"] --> Runner["Ephemeral CI runner"]
    Runner --> SCA["SCA + SAST scan"]
    SCA -->|"pass"| Build["Build artifact"]
    Build --> Sign["Sign artifact + generate SBOM"]
    Sign --> Repo[("Immutable artifact repository")]
    Repo --> Gate{"Approval gate"}
    Gate -->|"approved"| Verify["CD verifies signature + SBOM"]
    Verify -->|"OIDC short-lived role"| Deploy["Deploy to production"]
    Runner -.->|"OIDC token, no static secret"| Vault[("Secrets manager")]

Secrets: storage and injection. Secrets live only in a managed secret store (AWS Secrets Manager, HashiCorp Vault, or an equivalent) and are pulled into the pipeline at the moment a step needs them, scoped to that step's identity, never written to a checked-in configuration file or a long-lived CI platform "secret variable" shared across every job. Each pipeline step's access to the secret store is itself authorized by that step's own short-lived identity, not a single shared pipeline-wide credential.

Ephemeral runners and OIDC tokens. Every build runs on a fresh, single-use runner (a container or virtual machine destroyed after the job) rather than a long-lived, persistent build agent, so a compromised runner cannot persist between jobs. The runner authenticates to the cloud provider using a federated OIDC token issued by the CI platform (GitHub Actions, GitLab CI) and exchanged for short-lived cloud credentials, the same architectural pattern as IAM Roles for Service Accounts (IRSA), eliminating any static, long-lived cloud access key from the pipeline configuration entirely.

Artifact signing and verification. Every build artifact is signed at build time (cosign/Sigstore, keyless signing tied to the CI identity where supported) and accompanied by a Software Bill of Materials (SBOM). The deployment step verifies both the signature and the SBOM before deploying; an artifact that reaches the deployment step without a valid signature from the expected build identity is rejected, closing the gap where an attacker who compromises the artifact repository (but not the signing key) could otherwise substitute a malicious build.

SCA and SAST integration. Static application security testing runs on every pull request against the application's own code, and software composition analysis runs against the dependency tree, both before a build is allowed to proceed to the signing step; findings above an agreed severity threshold block the pipeline rather than merely being logged, since a finding that only produces a warning is a finding nobody is forced to act on.

Approval gates. A human or a policy-based gate sits between the artifact repository and the production deployment step; for lower environments the gate may be fully automated (an SCA/SAST pass is sufficient), while production requires an explicit approval recorded against the specific artifact version, not a blanket "deploy is approved" toggle.

Least-privilege deployment permissions. The role the CD (continuous deployment) step assumes to actually deploy is scoped to only the resources that deployment touches (a specific set of services or infrastructure, not the whole account), and is distinct from the role used earlier in the pipeline for scanning or signing, so a compromised scanning step cannot itself deploy to production.

Worked example

A concrete artifact's path through the pipeline: a developer pushes a change; an ephemeral runner spins up, authenticates to the cloud account via an OIDC token scoped to the "build" role (permissions: read the SCA/SAST tool's license, write to the artifact repository, nothing else), runs SAST and SCA, and on a pass, builds the artifact and signs it with a keyless Sigstore signature tied to that specific CI run's identity, then generates and attaches an SBOM. The signed artifact and its SBOM land in an immutable repository (write-once, so a later attacker cannot silently replace it). A production deployment request triggers an approval gate; once approved, a separate CD job authenticates via a different OIDC-federated role (permissions: deploy to the production service, nothing else), verifies the artifact's signature against the expected signing identity and checks the SBOM for any newly-disclosed critical vulnerability since build time, and only then deploys.

Trade-offs and pitfalls

• Ephemeral runners remove a persistence risk but add cold-start cost. A fresh runner per job means no cached dependencies or warmed state carrying over, which can meaningfully slow down build times; this is usually worth the security trade-off for anything touching production credentials, but a team building purely internal, low-risk tooling might reasonably accept a longer-lived runner pool with compensating controls instead.
• Signature verification is only as strong as the identity it is tied to. Keyless signing tied to a CI identity is only meaningful if the CI platform's own OIDC issuer and the trust boundary around who can trigger a workflow are themselves tightly controlled; a pipeline that lets any contributor trigger a signing-capable workflow from a forked pull request undermines the whole chain.
• Blocking SAST/SCA findings at every severity threshold causes gate fatigue. Teams that block on every low-severity finding eventually get an exception request culture that erodes the gate's credibility; blocking on critical and high severity, with a tracked, time-boxed exception path for anything lower, keeps the gate meaningful.
• A single shared deployment role for every environment defeats the least-privilege goal even if OIDC federation is otherwise done correctly. The role used to deploy to staging must not be the same role, or a superset of the same permissions, used to deploy to production.

Direct answer

When a security or compliance team has the authority to block work and uses it, the goal isn't to overpower them, it's to give them a way to say yes that they would defend to their own leadership. That means understanding the actual concern, proposing controls that address it directly, and building a record that makes the eventual approval easy to justify upward, rather than skipping the concern to hit a deadline.

Structured elaboration

1. Understand the veto, not just the outcome

Ask what specifically drives the block: a known threat pattern, a regulatory obligation, a past incident. A block framed as 'this is too risky' usually decomposes into something concrete once you ask what evidence would change their mind.

2. Propose compensating controls, not blanket reassurance

Bring specific mitigations that map to the stated concern: scoped access, monitoring, a rollback plan, data masking, a smaller blast radius. 'Trust me' rarely moves a team whose job is to not just trust people; a control they can point to in an audit does.

3. Phase the ask so risk and trust build together

Instead of asking for full approval up front, propose a smaller, monitored first step, then expand once it holds up. This gives the blocking team evidence rather than a promise, and it gives you a faster initial yes.

4. When you need executives to sponsor it, not just the compliance team to approve it

Sometimes getting to yes isn't about convincing the blocking team at all, it's about persuading senior executives, without formal authority over them, to sponsor a security or compliance investment that trades short-term revenue for long-term risk reduction. That's a different move: build the case in terms an executive already weighs (the cost of the exposure versus the cost and timeline of the fix), find a credible sponsor who already has their ear, and time the ask to a moment they're already thinking about risk, such as a renewal, an audit, or a near-miss. State the trade-off plainly rather than downplaying either the revenue impact or the risk.

5. When the conflict runs the other direction

The pressure isn't always compliance blocking a launch. Sometimes compliance demands collecting more data for audit purposes, and that request conflicts with the team's own privacy commitments to users. Handle this the same way: scope exactly what the audit requirement needs, then look for a way to satisfy it without violating the privacy commitment, such as aggregating instead of storing per-user data, sampling instead of full capture, or purpose-limited access with automatic expiry. If a genuine conflict remains after that, escalate it as a policy conflict for someone empowered to decide between the two obligations, rather than either side unilaterally overriding the other.

Worked example

A security team initially blocks a new integration on a financial product, citing customer-data exposure risk. Working sessions with security and the app owner map the specific risk to two things: a broad data scope and no kill switch. The team proposes scoped test accounts, data masking, and a remote kill switch, then agrees to a phased rollout: verify the low-risk paths first, escalate to the higher-risk ones only after the first phase holds up under monitoring. Security signs off on the phased plan. Separately, when the same team later wants to expand data collection to satisfy a new audit requirement, they find that a sampled, time-limited collection window satisfies the auditors just as well as full, indefinite collection, so the privacy commitment to users doesn't have to give.

Trade-offs and pitfalls

• Working around a block quietly (shipping a smaller version without telling the blocking team) buys short-term speed and damages the relationship you will need next time; always close the loop even when you find a narrower path.
• Compensating controls that never get revisited become permanent scaffolding; agree upfront on when the phased approach graduates to full trust, not just how it starts.
• On the upward-influence path, leading with fear rather than a clear trade-off tends to get budget approved once and then quietly deprioritized later, because the executive never actually weighed the cost against the risk. Naming the trade-off explicitly is what makes the commitment durable.
• Overriding a genuine policy conflict (audit needs versus privacy commitments) unilaterally, instead of escalating it, tends to resurface as a bigger trust problem with users or regulators later than the original block would have cost in time.

Direct answer: Insecure deserialization happens when an application reconstructs an object from untrusted byte data using a mechanism that can be tricked into instantiating arbitrary classes or invoking arbitrary methods as a side effect, letting an attacker achieve remote code execution or bypass application logic without the application's own code ever intentionally calling anything malicious.

How it leads to RCE or a logic bypass. Deserialization mechanisms like Java's native serialization, Python's pickle, and PHP's unserialize() are designed to reconstruct arbitrary object graphs, which means they can call constructors, setters, and "magic methods" (__reduce__ in Python, readObject() in Java, __wakeup() in PHP) automatically during the reconstruction process - a data format that CAN execute code by definition can be steered into executing the WRONG code by an attacker who controls the byte stream. Even without full RCE, tampering with a serialized object's fields (an admin flag, a price, a permission level) before it's deserialized back can bypass application logic that assumed the object was only ever produced by the application's own trusted serialization step.

Language-specific risks: Java native serialization is exploited via "gadget chains" - sequences of otherwise-legitimate classes already present on the classpath (from common libraries) whose methods, when chained together during deserialization, achieve code execution the developer never intended. Python's pickle explicitly supports arbitrary callable invocation via __reduce__ by design, which is why the Python documentation itself warns never to unpickle untrusted data. PHP's unserialize() similarly invokes magic methods on class reconstruction, and PHP-specific "POP chain" (property-oriented programming) techniques chain together classes already loaded by the application to the same effect.

Where deserialization typically occurs, often less obviously than a dedicated "deserialize" API call: session storage (a serialized session object read back on every request), inter-service message queues (one service serializes an object, another deserializes it), cookies used to persist client state, and RPC/remote object protocols.

Secure design patterns and mitigations:

1. Prefer data-only formats (JSON, Protocol Buffers) with no code-execution surface at all, wherever the use case allows - this is the strongest fix, since it removes the vulnerability class structurally rather than trying to use a code-capable format safely.
2. If a code-capable format must be used, apply strict type allowlisting so only explicitly-trusted classes can be instantiated during deserialization, never accepting "whatever class the byte stream names."
3. Runtime mitigations: sandboxing/isolating the deserialization step, and monitoring for deserialization exceptions or unexpected class-instantiation patterns as a detection signal.

A small, concrete trace of the mechanism, executed. Real gadget chains are hard to show in full (they typically chain several existing classes together), but the core mechanism - that reconstructing an object can trigger an arbitrary call, not just populate fields - is easy to demonstrate directly and I ran this:

class CacheWarmer:
    def __reduce__(self):
        # pickle calls __reduce__ automatically while RECONSTRUCTING the
        # object, and __reduce__ is free to name any callable with any
        # arguments - a real gadget reuses a class already on the classpath
        # for a legitimate reason, choosing which already-present callable
        # to invoke rather than injecting new code.
        return (print, ("[gadget fired] code ran during deserialization",))

malicious_bytes = pickle.dumps(CacheWarmer())  # 86 bytes on the current default pickle protocol, looks like ordinary data
pickle.loads(malicious_bytes)  # the victim app just wants to load a cached object

Running this prints [gadget fired] code ran during deserialization at the pickle.loads() line itself, before the victim application's own code ever runs anything - confirming the call happened as a side effect of reconstruction, not because the application explicitly invoked print. A real Java gadget chain follows the identical shape with readObject() instead of __reduce__, and a PHP POP (property-oriented programming) chain follows it with __wakeup()/__destruct(): an attacker who cannot inject new code can still reach a dangerous outcome (a real attack typically ends at something like a file write, a command execution primitive, or a class constructor with a serious side effect) by choosing which already-loaded class's magic method fires next, then which method THAT one calls, walking through classes already present in the application rather than introducing any new code of its own - "chain" refers to that sequence of hops through existing code, each one legitimate in isolation.

Detection signals in logs/crash traces: unexpected ClassNotFoundException/InvalidClassException-style errors (an attacker probing with class names that don't exist on the classpath), unusually large serialized payloads, or a spike in deserialization exceptions correlated with requests from a single source.

Trade-offs and pitfalls: type allowlisting has to be maintained as the application's legitimate object model evolves, and a too-broad allowlist (allowing a class merely because it's "already used somewhere in the app") can still admit a usable gadget if that class happens to have a dangerous side effect in its constructor or setters - the allowlist needs review, not just existence.

Overview
As a penetration tester, every technical finding must include reproducible evidence so engineers can verify and remediate. Below are common evidence types, preferred formats, required metadata, and how to reference them in the finding.

Annotated screenshots

• Formats: PNG (lossless), or PDF for multi-page.
• Metadata: timestamp (UTC), tester ID, target hostname/IP, browser/OS, action description.
• Reference: “See screenshot S-01.png (timestamp 2026-02-15T14:22:31Z). Steps 3–5 in the finding correspond to annotations A–C.”

PCAP files

• Formats: .pcap or .pcapng (Wireshark-compatible).
• Metadata: capture start/end timestamps, capture filter, tester ID, capture host IP/MAC, interface.
• Reference: “See capture P-01.pcapng. Filtered view: “http.request and ip.addr==10.0.0.5”. Packet #345 shows injected payload.”

Server/application logs

• Formats: raw .log or .txt; rotated/archive as .gz if large.
• Metadata: log time range (UTC), log source (server name, service), log level, tester ID, correlation IDs.
• Reference: “See logs/server-app-2026-02-15.log (lines 1024–1040). Correlate with timestamp 2026-02-15T14:22:31Z.”

HTTP request/response dumps

• Formats: .http, .txt, or Burp/Proxy export (.burp, .xml); include full headers and bodies.
• Metadata: timestamp, tester ID, target URL, method, status code.
• Reference: “See HTTP dump H-01.http — request at 2026-02-15T14:22:31Z; response code 500 with stack trace.”

Proof-of-Concept (PoC) scripts

• Formats: .py, .sh, .js, or dockerized container for environment parity.
• Metadata: runtime/requirements (Python 3.9), exact command to run, tester ID, safe flags, expected outcome, target IP/URI placeholders.
• Reference: “Run: python poc_rce.py --target 10.0.0.5 --port 8080. Output saved to poc_output.txt.”

Configuration snippets

• Formats: .conf, .yaml, .txt, or exported config from device.
• Metadata: source device, config path, timestamp, redacted secrets note.
• Reference: “See config C-01.yaml — lines 12–18 show weak cipher enabled.”

General best practices

• Use UTC timestamps and ISO 8601.
• Include a short README listing files, purpose, and reproduction steps.
• Redact sensitive secrets but note redactions and how to obtain full context if authorized.
• Package evidence with consistent IDs (S-01, P-01, H-01) and reference those IDs in the finding steps so engineers can follow and reproduce.

Remediation Acceptance Form — Residual Risk Acknowledgement

1. Summary of Acceptance

• Engagement ID:
• Test type (e.g., external/internal/web app):
• Report reference & date:
• Finding(s) accepted (IDs/severity):
• Date of acceptance:

2. Required Fields

• Business Owner Name & Title:
• System / Asset Owner:
• Asset / Application Name & Identifier:
• Description of residual risk (concise):
• Compensating controls in place:
• Planned mitigation timeline (if any):
• Duration of acceptance (review date):
• Risk rating (final agreed severity):
• Comments / rationale for acceptance:

3. Signatories (roles)

• Business Owner (acceptance)
• System/Technical Owner (acknowledgement)
• Information Security (Reviewer — e.g., CISO or Security Manager)
• Penetration Tester (tester attesting accuracy of findings)
• Compliance / Legal (for high severity) — see below
• Risk Management / CRO (for enterprise risk sign-off)

4. Guidance (minimum text)
By signing I acknowledge that I accept the residual security risk described above for the listed asset. I understand the potential impact, likelihood, and that this acceptance transfers responsibility to my business unit. Acceptance does not invalidate any regulatory obligations; I will revisit this decision if threat or control posture changes.

5. High-Severity Acceptance — required approvals
For any acceptance of findings rated High or Critical:

• Mandatory review and written approval from Information Security leadership (CISO/Security Director)
• Legal review to assess regulatory/liability implications
• Compliance approval (e.g., GDPR/PCI owner) where applicable
• Formal risk acceptance recorded in enterprise risk register and approved by Risk Committee or CRO

Signature blocks: name, role, signature, date, contact.

Approach (brief)
I’d automate nightly authenticated scans using the Nessus API (example), poll for completion, retrieve results, deduplicate findings, and push new/updated tickets to Jira via its API. Key concerns: strong auth, secrets handling, retry/backoff for rate limits, idempotency for dedupe.

High-level steps

1. Scheduler: run nightly via cron or CI pipeline.
2. Authenticate: obtain API token (username/password → token) and store in vault.
3. Launch scan: POST to /scans with credentialized policy and target list.
4. Poll with exponential backoff for scan status; handle 429 and 5xx.
5. Retrieve report: export CSV/JSON when complete.
6. Parse & normalize findings (canonical keys: asset, vuln_id, first_seen, severity).
7. Deduplicate: compare against recent findings store (DB or ticket tags) — only create/update tickets for changed items.
8. Push to ticketing: POST to Jira; include risk, evidence, remediation, references.
9. Logging/alerts: on failures or excessive diff counts, notify Slack/email.

Auth & secrets

• Use Vault/Secrets Manager; short-lived Nessus tokens.
• Refresh tokens when nearing expiry.

Error handling & rate limits

• Retry with exponential backoff (base 2s, max 60s), jitter.
• For 429 read Retry-After header; pause that scanner endpoint pool.
• Circuit-breaker: after N consecutive failures alert and stop attempts.

Mini Python sketch

# requests-based pseudocode
token = get_token_from_vault()
headers = {"X-Cookie": f"token={token}"}
resp = requests.post(f"{NESSUS_URL}/scans", json=payload, headers=headers, timeout=30)
# poll with backoff and handle 429/5xx

Why this works

• Authenticated scans find credential-only issues. Deduping prevents ticket noise and tracks remediation. Backoff and secrets best-practices ensure reliability and security.

Direct answer

For 5,000-20,000 endpoints with a constrained instrumentation budget, prioritize telemetry that reveals persistence (something an attacker installs to survive a reboot) and lateral movement (something an attacker uses to reach a second system) over broad, low-signal logging, since these two behaviors are where nearly every real intrusion becomes detectable regardless of the initial access vector, and they are catchable with a small, well-chosen set of sources rather than "log everything."

Structured elaboration

Windows endpoints, ranked by signal-to-noise:

1. Process creation with full command line (via Sysmon Event ID 1 or native Event ID 4688 with command-line auditing enabled), the single highest-value source: persistence installers (schtasks.exe, reg.exe writing a Run key) and lateral-movement tools (psexec.exe, wmic.exe) both show up here directly.
2. Authentication events (4624/4625, with LogonType), since lateral movement is fundamentally a credential-use problem, and a Type 3 (network) or Type 10 (RemoteInteractive/RDP) logon from an unexpected source is a core lateral-movement signal.
3. Scheduled task creation (Event ID 4698) and service installation (Event ID 7045), the two most common Windows persistence mechanisms, and both are low-volume, high-signal events on most endpoints.

Linux servers, ranked by signal-to-noise:

1. Process execution auditing (auditd execve rules), the Linux equivalent of Windows process-creation logging.
2. SSH authentication logs (/var/log/auth.log or /var/log/secure), the primary lateral-movement vector on Linux fleets.
3. Cron and systemd timer/service changes, the primary Linux persistence mechanisms, paralleling scheduled tasks and services on Windows.

Domain controllers, highest priority of all: authentication and directory-change events (successful/failed logons, group membership changes, especially additions to privileged groups, and Kerberos ticket-related events), since a domain controller sees identity activity for the ENTIRE domain, making it the single highest-leverage instrumentation point in a Windows-centric estate; a resource-constrained rollout that could only instrument one tier first would reasonably choose domain controllers.

Core network devices: NetFlow or connection-log data at internal segment boundaries and the perimeter, focused on connections to sensitive internal segments (server/DC networks) rather than full packet capture everywhere, since flow-level metadata is dramatically cheaper to collect at scale than payload inspection while still revealing lateral-movement connection patterns (an endpoint suddenly connecting to many other endpoints, or to a domain controller on an unusual port).

Worked example

For an organization instrumenting from zero with this exact budget constraint, a defensible sequenced rollout: Phase 1 (highest signal-to-noise), domain controller authentication/directory-change logging and Windows process-creation-with-command-line on servers (higher-value targets, fewer hosts, faster to fully cover); Phase 2, extend process-creation logging to standard workstations and add SSH/auditd on Linux servers; Phase 3, add core network device flow logging at internal segment boundaries. This ordering deliberately defers full workstation-fleet coverage (the largest host count, and so the most instrumentation effort) behind the smaller, higher-leverage server and DC tiers, on the reasoning that a resource-constrained rollout gets more detection value per engineering-hour spent on 50 servers and 4 domain controllers than on the first 5,000 of 20,000 workstations.

Trade-offs and pitfalls

• Command-line logging is the highest-value single addition and the most commonly skipped one: process-creation events WITHOUT the command line (just the process name) miss the vast majority of the signal, since powershell.exe alone is unremarkable but powershell.exe -enc <base64> is not; if only one enhancement can be made to a minimal baseline, enabling command-line auditing is usually it.
• Common mistake: treating "endpoint count" as the only scaling constraint and ignoring that domain controllers and core network devices, while few in number, carry disproportionate detection value; a budget allocated purely proportional to host count under-invests in exactly the highest-leverage points.
• Common mistake: enabling full packet capture at network chokepoints under a "more is better" instinct; at this scale, full packet capture is usually not viable within a genuinely minimal instrumentation budget, and flow/connection metadata captures the lateral-movement signal (who connected to whom, how often, on what port) at a small fraction of the cost.
• This minimal baseline is deliberately NOT comprehensive: it is the highest-signal-per-unit-of-effort starting point, not a replacement for the fuller telemetry-sourcing coverage (cloud, identity-provider, DNS, and so on) an organization should build toward as budget allows.

Overview — high-level difference
A penetration test is a focused assessment that looks for exploitable vulnerabilities in-scope systems; a red team engagement simulates an adversary end-to-end, combining technical attacks, social engineering, and persistence to achieve strategic objectives.

Objectives

• Pen test: find, exploit, and report vulnerabilities (confidentiality/integrity of assets).
• Red team: emulate realistic attacker goals (data exfiltration, domain compromise) and test detection/response.

Scope & duration

• Pen test: narrow scope (specific apps, IP ranges), short (days–2 weeks).
• Red team: broad, goal-oriented scope including physical/social elements, longer (weeks–months).

Allowed / prohibited activities

• Pen test: aggressive exploitation allowed but usually non-destructive; no social engineering unless agreed.
• Red team: social engineering, covert persistence often allowed if pre-approved; destructive actions and safety-critical disruption prohibited.

Evidence & reporting

• Pen test: vulnerability list, proof-of-concept exploits, remediation steps.
• Red team: narrative attack timeline, indicators of compromise, screenshots/logs, exfiltrated sample data, blue-team detection gaps.

Blue-team interaction

• Pen test: limited, often cooperative for remediation.
• Red team: may be unannounced to test detection; debrief and purple-team session post-engagement.

Success criteria

• Pen test: number/severity of findings and remediation guidance.
• Red team: achievement of objectives, time-to-detection, time-to-containment, and gaps in controls.

Example: a pen test finds SQLi in an app; a red team uses that as one vector among phishing + credential stuffing to obtain domain admin and remain undetected for days.

Approach (brief)
I enumerate services by chaining public-facing discovery (DNS, ingress, API docs) into internal discovery (service registries, K8s API, container images, cloud metadata, repo configs), automating with scripts and standard tools to find endpoints, credentials, and misconfigurations.

Sources & Techniques

• Public API docs / Swagger/OpenAPI: crawl docs, download specs (curl), convert to endpoints (swagger-cli, oapi-codegen) and fuzz (wfuzz/Burp).
• Ingress controllers / Load balancers: nmap, curl, host header fuzzing, probe virtual-hosts (gobuster/ffuf), check TLS SNI.
• DNS & subdomain enumeration: amass, subfinder, dig, crt.sh; enumerate service names (api-, svc.).
• Service discovery (Consul/etcd): query exposed endpoints (curl/consul CLI, etcdctl) and enumerate KV/catalog if unauthenticated.
• Kubernetes API: kubectl (kubectl get svc,endpoints,pods --all-namespaces), kubectl proxy to query APIs, kube-hunter, check for open API server (& unauthenticated /exec).
• Container registries: regctl/crane/docker CLI to list images/tags; scan images for secrets (trivy, truffleHog).
• Cloud metadata endpoints: curl 169.254.169.254 for AWS/GCP/Azure to detect exposed metadata access.
• Repository configs: search IaC and k8s manifests in public repos (github search, gh api), run gitrob/truffleHog to find credentials.

Automation / Commands

• DNS/Subdomain: amass enum -d example.com; subfinder -d example.com
• HTTP discovery: ffuf -w wordlist.txt -u https://target/FUZZ
• K8s: kubectl --kubeconfig=k cfg; kubectl get all --all-namespaces -o wide
• Consul/etcd: curl http://consul:8500/v1/catalog/services ; ETCDCTL_API=3 etcdctl --endpoints=...
• Metadata: curl -sS http://169.254.169.254/latest/meta-data/
• Repo scanning: gh repo search, git clone + truffleHog --regex
• End-to-end: custom Python/Bash to aggregate results; store in CSV/JSON for Burp/OWASP ZAP import.

Why these matter
Combining public and internal sources uncovers hidden endpoints, misconfigurations, exposed secrets, and pivot paths. Automation scales enumeration and feeds deeper testing (fuzzing, auth bypass, SSRF to metadata).

Direct answer

Threat modeling a new cloud deployment means walking the attack surface that is specific to cloud infrastructure rather than reusing an on-premises checklist: the instance metadata service, server-side request forgery (SSRF), overly broad identity and access management (IAM) roles, publicly exposed storage, and event sources feeding serverless functions are the five vectors that show up in most real cloud breaches, and they frequently chain together rather than occurring alone.

Structured elaboration

Worked example

A realistic chained exploit, using three of the five vectors together: an image-processing feature accepts a URL and fetches it server-side to generate a thumbnail (an SSRF-prone design). An attacker submits http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name> as the "image" URL. The server-side fetch obeys it, retrieving the temporary credentials for the instance's IAM role and returning them (or a derived error) in the response. If that role happens to hold s3:* on all buckets, a genuinely common misconfiguration born from teams choosing convenience over the effort of scoping each role individually, the attacker now has full read/write access to every bucket in the account, not just the one the image service was meant to touch. Three separate mitigations each independently break this chain: egress-filtering the server-side fetch (breaks the SSRF step), enforcing IMDSv2 (breaks the metadata-retrieval step even if the SSRF succeeds), and scoping the role to the one bucket the service needs (limits the impact even if both prior steps succeed).

Trade-offs and pitfalls

• Defense-in-depth is the point, not redundancy for its own sake. In the worked example, no single mitigation is sufficient on its own; IMDSv2 alone does not stop the SSRF, and a scoped role alone does not stop the metadata retrieval. Treating any one of these five vectors as "handled" because one mitigation was applied is the most common gap.
• IMDSv2 enforcement is not automatically retroactive. Existing instances launched before an organization enforces http_tokens = "required" remain on the old default unless explicitly updated; a fleet-wide audit and remediation pass is needed, not just a policy for new launches.
• Egress filtering for SSRF has a real engineering cost. A strict allow-list breaks legitimate integrations that fetch from a wide range of external domains (webhooks, partner APIs), so teams often under-invest here relative to the metadata and IAM mitigations, which are comparatively cheap to enforce as account-wide defaults.
• Serverless event-source validation is easy to skip because the event looks structured. A JSON event payload from a trusted-looking source (the cloud provider's own event system) still carries attacker-influenced fields whenever the trigger itself accepts external input, such as an uploaded file's name; validating "the event came from the real event source" is not the same as validating that the content the event carries is safe.