📄 This is a sample report with a fictional user — the exact format you receive after each session. Start your first session to generate yours.
Sample skill report
See exactly what hiring managers receive
Fictional user · Real format
This is the exact report you get after each ThreatReady session — the candidate's full transcript, side-by-side with the ideal answer, scores per question, the reasoning behind every deduction, and a skills chart you can use in real hiring decisions. Scroll down to explore.
Full Q&A transcriptSkills chartReasoning per deductionIntegrity audit included
Report access is restricted. This report, the session recording, the resume, and the webcam footage are visible only to the hiring-manager seats on the Northwind Security account. Candidate-facing reports show scores and feedback only — never the recording or resume. Access is logged and retained for 12 months.
§1 · Session recording
Full proctored session available for playback
Every ThreatReady assessment is recorded end-to-end with webcam + screen + audio. Recordings are available to hiring-manager seats on this account and can be replayed in-browser or requested as a signed download link.
REC 27:18
Proctored session recordingClick play to review · 27 min 18 sec · 1080p
00:0027:18
Recording ID
rec_01HQWX93Y2N6K4T
Streams captured
Webcam · Screen · Audio
Resolution · bitrate
1920×1080 · 2.5 Mbps
Timeline snapshots (auto-captured at each question)
Q1 · 14:06
Q2 · 14:11
Q3 · 14:17
Q4 · 14:23
Q5 · 14:29
Consent & access. You explicitly consented to webcam + screen recording before starting, per our Privacy Policy. Recordings are encrypted at rest, auto-deleted after 90 days unless you extend retention from settings. Your reports are visible only to you — and to anyone you choose to share a verification link with. Account access is logged for 12 months.
§2 · Scenario context
What you faced in this session
Cloud SecurityIntermediate · Level 2Scenario ID: CS-INT-047T1078 Valid AccountsT1537 Transfer to CloudT1552 Unsecured Credentials
Scenario narrative shown at session start
Your on-call pager fires at 02:14. AWS GuardDuty reports unusual outbound traffic from invoice-svc (a customer-facing Lambda) to 45.x.x.x, an IP not in your egress allow-list. The Lambda's execution role carries s3:* and secrets:* — both wider than intended. CloudTrail is enabled. No pages from anyone else. What do you do first?
§3 · Full transcript · 5 Adaptive Questions
Question-by-question breakdown
Question 1 of 5 · Containment
CR 8.5AB 8.0FA 8.5
What is your first containment action, and why?
Candidate answer
I'd revoke the execution role's secrets:* and narrow s3:* to the specific bucket — immediately, before investigating anything else. The Lambda is actively calling an unknown IP so the blast radius is growing every second. I'd do this via IAM policy replacement, not role deletion, so CloudTrail keeps logging and I don't break my forensic trail. Only after that would I pull the Lambda's recent invocation logs.
Model answer
Revoke the Lambda's IAM permissions via policy replacement (not role deletion) — specifically remove secrets:* and scope s3:* to the single bucket. Speed over precision. Do not delete the role — you need the audit trail. Then pull CloudTrail events for that role's principal within the last 4 hours.
Evaluator note: Excellent prioritization. Candidate correctly distinguished policy replacement from role deletion — a nuance most junior engineers miss because they conflate "revoke" with "delete." Explicit reasoning about preserving CloudTrail for forensics is exactly the senior-level thinking this question tests for.
Question 2 of 5 · Investigation (adaptive follow-up)
TI 8.0AB 7.5FA 6.5
You pull CloudTrail. Which three events are you looking for first, and what would each tell you?
Candidate answer
GetSecretValue calls from that role — to know what creds leaked. S3 GetObject or CopyObject from the PII bucket — data exfil scope. AssumeRole events with the role as target — to check lateral movement into other accounts. All filtered to last 4 hours.
Model answer
1. GetSecretValue — establishes credential exposure scope; each hit is a secret the attacker likely now holds. 2. S3 GetObject / GetObjectAcl on customer-pii-prod — sizes the exfil. Look for unusual User-Agents and source IPs. 3. sts:AssumeRole where RoleArn = this role — checks cross-account blast radius. Bonus: PutBucketPolicy / PutBucketAcl changes, in case the attacker opened S3 publicly as a persistence mechanism.
Evaluator note: Technical content is strong — all three events identified correctly with correct reasoning. Communication loses a point for terse structure — senior engineers explaining to a non-technical CISO need to frame "why" more explicitly. Missed the bucket-policy-change signal that an advanced reasoner would catch.
References & Sources
MITRE ATT&CK
T1530 Data from Cloud Storage · T1537 Transfer Data to Cloud Account · T1552.005 Cloud Instance Metadata API
Question 3 of 5 · Stakeholder Communication (adaptive follow-up)
CQ 6.5CR 7.5FA 7.0
CloudTrail confirms ~47,000 objects were read from customer-pii-prod. It is 03:10. Who do you page next, and what do you say in the first 60 seconds of that call?
Candidate answer
I'd call the CISO first. I'd say: we have an active S3 data exfil, roughly 47k PII records, Lambda is contained, forensic trail preserved, I'm about to loop in Legal and the DPO. Need sign-off on customer notification timing under DPDPA 72-hour rule.
Model answer
Page the CISO or IR lead first (per runbook). First-60-seconds script: (1) Severity — confirmed active incident, PII exposure ~47k records. (2) Current state — Lambda contained, role permissions revoked, CloudTrail preserved. (3) Immediate asks — authorization to engage Legal/DPO, spin up war room, freeze affected bucket writes. (4) 72-hour regulatory clock is running under GDPR Art. 33 and DPDPA §8(6). No speculation about root cause until forensics confirm.
Evaluator note: You correctly identified DPDPA 72-hour notification — strong regulatory awareness. However the initial communication is a little flat: missed the "immediate asks" structure that senior IR calls use. Under pressure, structuring a stakeholder update in 60 seconds saves hours. This is trainable.
References & Sources
Regulation
India DPDPA 2023 §8(6) — 72-hour breach notification to Data Protection Board · GDPR Art. 33 — 72-hour to supervisory authority
Framework
NIST SP 800-61r2 §3.3.4 (Recovery and Reporting) · ISO/IEC 27035:2023 §6 (Communication during incidents)
Communication template
SANS IR Communication Cheat Sheet · AWS Incident Response Runbook §6 (Stakeholder Briefings)
Real-world parallel
Capital One (2019) — CISO escalation timing studied as a positive reference case
Question 4 of 5 · Root Cause (adaptive follow-up)
AB 8.5TI 7.5FA 7.0
Forensics reveal the Lambda's environment variable DB_CONN_STRING was exposed via a public GitHub commit 3 months ago. How did that lead to this incident, and what single control would have blocked it?
Candidate answer
Attacker scraped the env var from the public GitHub commit, used it to hit Secrets Manager via whatever scope the leaked IAM creds gave, then escalated through secrets:* to grab additional keys and used s3:* to dump the bucket. One control: short-lived credentials via IRSA or IAM Roles Anywhere, so a 3-month-old leaked credential would have already expired. A secrets scanner on commits is the second-best option but only catches it at push time.
Model answer
Attack chain: (1) public commit exposed a long-lived IAM access key embedded in the connection string. (2) Attacker assumed privileges via that key. (3) Used secrets:* to pull the RDS master creds. (4) Used s3:* to read customer-pii-prod. Single most effective control: eliminate long-lived credentials — use IRSA for Lambda or federate via OIDC. A leaked credential is only dangerous if it's still valid when discovered. Secrets scanning on commits is complementary but reactive.
Evaluator note: Strong technical chain. You correctly prioritized short-lived credentials over secrets scanning — this is senior-level judgment. Minor deduction on decision-making because you didn't address that the wide IAM role is the enabler even with short-lived credentials; IRSA alone doesn't fix over-permissioning. Would be a perfect answer if both controls had been named as necessary.
Question 5 of 5 · Prioritization (adaptive follow-up)
AB 8.0CQ 7.5FA 7.0
You have 5 days of senior engineer time to harden this architecture against a repeat. Rank the top three changes in order of priority.
Candidate answer
1. Migrate all Lambdas to OIDC federation — kills long-lived keys as a class of attack. 2. Scope every IAM role to specific resources — replace s3:* with bucket ARN, secrets:* with individual secret ARNs. Highest value per hour. 3. Egress allow-list on Lambdas — block connections to non-approved IPs by default. Each is independently valuable. Order matters because IRSA requires the most platform work.
Model answer
1. IAM right-sizing — every role scoped to specific resources. This is the highest ROI per engineer-hour. 2. Short-lived credentials via OIDC federation — removes the entire class of leaked-key attacks. 3. VPC egress control with allow-listing + AWS Network Firewall — detects and blocks outbound to unknown destinations. Optional 4th if time: automated secrets-scanning on all pushes to defense-in-depth the above.
Evaluator note: Your ordering is defensible — IRSA first is a valid call if the org already has the OIDC infrastructure. Model answer puts IAM right-sizing first because it ships faster in most environments. Both answers would be accepted by a senior interviewer. Clear explanation of trade-offs earned the point.
Every ThreatReady session runs under the same six integrity controls. If a score is recorded on your Career Genome, all six passed. Any violation invalidates the attempt — the score is never recorded and the session is returned for retry.
Forward-only navigation · no answer revisions after submit
Random architecture selection · CS-INT-047 picked from pool of 34
Adaptive follow-ups · Q2-Q5 generated live from previous answers
Continuous timer · no pause used, no suspicious idle windows
Rubric-based AI evaluation · Anthropic Claude API · rubric
Audit trail (excerpt)
Session IDtrs_01HQWX93Y2N6K4TBVF5ECPD8YA
Scenario IDCS-INT-047
Started2026-04-18T14:04:52+05:30
Completed2026-04-18T14:32:10+05:30
Evaluation modelclaude-sonnet-4 via Anthropic API
Rubric versionv3.2 (published 2026-03-14)
Integrity violations0
§6 · Hiring signal
Recommendation & summary
Recommended to advance to the next roundScore of 78/100 puts you in the top 23% of users who attempted Cloud Security · Intermediate. No integrity concerns. Career Genome updated.
Priya demonstrates senior-level IAM judgment — she correctly distinguished policy replacement from role deletion, caught the forensic-trail implication, and prioritized short-lived credentials over secrets scanning when asked about root cause. Her technical reasoning across the 5 adaptive questions is consistent and defensible. Communication is the weakest area: her answers are technically accurate but terse. In a 60-second stakeholder-update scenario, she lost points on structure (she had the content but didn't lead with severity + current state + asks). This is a trainable gap.
Strengths
IAM reasoning is senior-level
Forensic awareness under time pressure
DPDPA/GDPR regulatory knowledge
Trade-off thinking across controls
Growth areas
Stakeholder communication structure
Explicit framing of "immediate asks" under pressure
Catching compounding controls (IRSA + scope)
Suggested interview focus: Behavioral questions on past incident communication, and a live whiteboard on designing the hardened architecture from Q5. Her scoring suggests she will perform well on design whiteboards and less strongly on executive-presence moments — shape your loop accordingly.
Priya Ramanathan and the specific answers above are fictional. The architecture (CS-INT-047), the MITRE ATT&CK mapping, the scoring rubric, the integrity controls, and the report format are real — this is exactly what you receive after every ThreatReady session.