Chapter 39: Interview and Certification Preparation

39.1 Why.

Welcome to Chapter 39.

I am Ravindra Bagale.

Raju had no engineering degree. He had a wish for a badge that would make a stranger trust him, and a fear of a conversation where he would have to speak without notes. Guru-ji set the badge aside. "An interview is a spoken lab. A certification, when it is real, is an exam run by some other organization, on a date, with a scope you can read. This course is neither an employer nor an exam board. I will not hand you a certificate. I will not tell you that a pass is guaranteed. I will ask you questions you can already answer from the work you did, out loud, in plain sentences."

Suppose we are Infosys and a client wants a person who can explain evidence, not a person who can recite a product brochure. Suppose we are Paytm, PayFast, or BHIM UPI and the panel wants to hear how a payment-shaped service stays least privileged. Suppose we are Swiggy or Zomato and the question is a dinner-rush failure. Suppose we are Amazon or Netflix and the question is a pipeline identity or a rollback. Suppose we are WhatsApp-shaped systems and the question is logs that must not swallow a secret. In all of those rooms the winning habit is the same. You name the control, the failure, and the guard. You do not invent a number. You do not claim a title you were not awarded. You do not offer to demonstrate an attack on anyone.

39.2 What.

How to practice aloud. Sit with a timer. Read the question once. Speak for ninety seconds. Stop. Check that you named a control, an owner or a piece of evidence, and a boundary. If you named a brand and forgot the objective, start again. If you drifted into steps that would harm a system, stop and answer the defensive version. Record yourself once. The stumble you hate is the stumble a panel will trust more than a memorized poem, provided the facts are true. Use your Chapter 38 repository as the prop. "In my lab I did this" beats "at a famous company I would." You did the lab. You did not run their network.

Questions you can answer from this course. Speak your own words. The paragraphs under each question are a model, not a script to fake. If your lab differed, say what you actually did.

What is DevSecOps, without a slogan. It is the habit of building, shipping, and running software so that security controls are in the same path as delivery, with owners and evidence. Developers, security people, and operators share the outcome. Chapter 2's point still stands: speed, risk, and stability are one conversation. You are not done when a tool is installed. You are done when a bad change fails a gate you can show, and when a real page becomes a decision.

Name the four delivery numbers without pretending you invented them. Deployment frequency, lead time for changes, change failure rate, and time to restore. The formulas and the bands are in Chapter 2. In an interview you say that, and then you say how you would use a movement in one of them. If frequency rose because a gate was set to warn-only, you would not call the team healthier. Chapter 35 is the management layer: false-positive hours, debt with an expiry, one decision.

What is a false positive, and why should a lead care. A false positive is a finding that is not a real exposure, confirmed by someone who looked. The danger is the hours and the shrug. If developers learn that red marks are noise, a true mark dies with them. You separate "not a bug," "not reachable," and "real debt we are postponing." Only the first is a false positive. You would rather block on a short list than warn on a flood.

How do you talk about security debt. A known exposure or a missing control, with severity, reachability, owner, expiry, and the harm if you are wrong. You pay high-interest rows first. You do not hide them inside a false-positive rate. You do not accept them in chat with no date. If the expiry passes, the lab deploy stops until someone renews the exception in writing or fixes the row.

Walk a threat model for a tiny status service. Two boxes, one read arrow, synthetic orders. You worry about a route you did not mean to ship, a log line that might keep a secret later, a dependency you cannot find, and a deploy identity that can do more than roll the digest. You would add authorization before you add private data, not after. That is Chapter 38. You can draw it on paper in the room.

How do you review code for security without performing. You look for secrets, unexpected entry points, trust in caller input, and errors that leak internals. You ask for a test or a gate that keeps the fix from rotting. You do not ask the candidate across from you to produce an exploit, and you do not produce one to look clever. A review comment should tell the author what to change in their own repository.

What belongs in pipeline security. The identity of the runner, the difference between a pull-request token and a deploy token, pinned dependencies, a scan that can fail the job, a signature or a digest, and logs of what ran. A helper that executes inside that environment is a privileged tool, even if its marketing says it only draws a coverage badge. You pin it, you limit the environment it can see, and you can remove it.

SAST, SCA, a registry, and policy-as-code. Why the categories matter more than the logos. SAST reads the code for dangerous patterns. SCA matches dependencies to advisories. A registry is where digests live and where overwrite should be hard. Policy-as-code turns "we do not allow that shape" into a check you can review in git. You select by the objective, the data that must leave your account, the failure mode, and the exit plan. Chapter 37's replacement drill is a fair interview story: two tools, one objective, revoke the old token.

How would you troubleshoot a failure that might be the pipeline, the cloud, or the process. One timeline. Last healthy minute. First broken proof. One lever. If the symptom does not move, put the lever back. You correlate deploy ids, cloud denies, and process logs on one clock. You do not grant a broad role to make a deny go away. Cloudflare's public outage on 2 July 2019 is a clean story if they ask for a real event: a rule went global, CPU explained the user errors, a kill switch restored service, and the later guard was staged change plus a better test. You do not recite exploit detail. There is none you need.

What do you do in the first half hour of an incident you own. You name one lead, you preserve logs, you stop an ongoing bad deploy, you isolate what you can prove, and you speak to the people who must act. You do not wipe the machine to feel tidy. Chapter 23 and Chapter 36 agree. You measure alert-to-decision, because Target's public breach, confirmed on 19 December 2013, is the cautionary tale of signals that did not become a fast decision. You will not embellish that event with techniques you did not study as defenses.

How do containers and cloud identity show up in an answer. The process runs as a normal user. The image is a digest. The deploy role can roll that workload and cannot rewrite the audit trail or read every bucket. Secrets come from a short-lived path, not from a layer in the image. You can say that without naming a console button. If you do not remember a button, say so. Inventing a menu is worse than a pause.

What is a useful security metric for a manager who hates vanity. Time from a serious alert to a recorded decision. Age of the oldest reachable high finding. Hours spent on findings that were not risk. Escape: issues that reached the running system after a gate had a chance. Any one of those can change a sprint. A blended maturity decimal cannot. If they ask for a framework name, you may say that models such as OWASP SAMM exist as vocabularies, and that this course did not award you a level against them.

Tell me about a drill, not a breach you caused. You use Chapter 38. An advisory name, a search of your bill of materials, a rebuild if needed, a health check, a note with times. Log4Shell, disclosed on 10 December 2021, is the public reason the drill exists. Your lab is the only place you ran it. If they ask you to exploit a logging flaw on a whiteboard, you decline and offer the inventory-and-patch story instead. A panel that insists on a payload is telling you something about the room. You still do not provide one.

What will you not claim. You will not claim you held an on-call seat you did not hold. You will not claim you passed an exam you did not sit. You will not claim this course certified you. You will not claim a job offer is likely, guaranteed, or owed. Studying these chapters does not promise employment at Infosys, Amazon, Netflix, Swiggy, Paytm, or anywhere else. It promises that you can practice the work on systems you own.

Certifications, said honestly. Some exams exist and are run by other organizations. Examples you may hear named in job posts include CompTIA Security+, the ISC2 CISSP, the CSSLP, and cloud or platform exams such as a provider's security specialty or a Kubernetes administrator exam. Their outlines change. Their pass marks are theirs. A credential proves that you met that issuer's rules on that date, if you actually earned it. It does not prove judgment. It does not replace a threat model you can draw. Offensive exams and lab ranges that teach intrusion are outside this course. Nothing here prepares you to attack, and nothing here is an endorsement that you should sit such an exam. If you later choose a defensive exam, read its official guide, practice only on legal labs, and treat a fail as information. People fail real exams. A guarantee would be a lie. Anyone who sells you a "DevSecOps certificate" as a side effect of reading these chapters is not speaking for this course. There is no such award. Do not print one.

A teaching sample: a ninety-second shape. "I built a localhost status service with fake orders. I wrote a one-page threat model, reviewed it for extra routes and noisy logs, scanned the repo, and deployed by digest as a non-root user. I keep Chapter 2's formulas for delivery and a debt row with an expiry for security. In a drill I treated a public advisory as a search of my bill of materials, rebuilt if needed, and wrote down the clock. I can replace a scanner without losing the objective. I do not have a certification from this course, and I would not test a system I do not own."

That answer is enough. Stretching it with brand names you have not used is how candidates start to invent.

39.3 How.

1. List the lab artifacts you really have: threat page, pipeline notes, debt row, drill note.
2. Remove any sentence in your resume notes that claims a certificate this course does not issue.
3. Remove any sentence that implies you were employed by a company you were not employed by.
4. Pick six questions from Part 2. Write the control each one asks for in the margin.
5. Speak the first answer for ninety seconds without looking.
6. Replay it. Mark one place you said a brand instead of an objective.
7. Speak it again with the objective first.
8. Do the same for a failure-analysis answer, using one lever and a clock.
9. Do the same for a tool-selection answer, including how you would replace the tool.
10. Explain false-positive load and security debt in words a product owner could hear.
11. Point at Chapter 2 when a formula is required. Do not rewrite the formula from memory if you are unsure. Say where it lives.
12. Practice declining, politely, a request for exploit steps. Offer detection, inventory, or rollback instead.
13. Read one issuer's public exam outline if you are curious. Note that curiosity is not enrollment and not a pass.
14. Write "no guarantee" next to any exam you are considering, so your notes stay honest.
15. Practice the ninety-second capstone shape until it fits in the time.
16. Ask a friend to interrupt you with "which system did you actually touch." Answer with the lab.
17. If you do not know, say you do not know, then say what you would check. Do not fill the gap with a story.
18. Review Chapter 34's boundary: a test needs a fixture, not a victim. Say that if they ask about "hacking skills."
19. Collect questions you could not answer. Map each one to a chapter. Study there. Do not collect payloads.
20. Sleep. A tired recital of logos is not preparation.
21. On the day, speak slowly. Name evidence. Stop when the question is answered.
22. Afterward, write what you said that was weaker than your lab. Fix the lab note, not your mythology.
23. Never send a follow-up that offers to scan the company's production to prove yourself.
24. Keep the lab repository. It is the portfolio. A fake certificate file is not.
25. Stop. Do not use interview practice as a reason to touch Swiggy, Paytm, Amazon, BHIM UPI, WhatsApp, Zomato, Netflix, Infosys, PayFast, or any system you do not own.

39.4 A real public incident.

Name. SolarWinds Orion supply-chain compromise, disclosed in December 2020.

Date. FireEye published a public statement on 13 December 2020 describing a supply-chain compromise delivered through updates to SolarWinds Orion. SolarWinds disclosed the issue to investors in a Form 8-K filed on 14 December 2020.

Source. FireEye's 13 December 2020 statement and SolarWinds' 14 December 2020 Form 8-K. This chapter does not describe the implanted code or how it was built.

What happened. Organizations installed what they believed were ordinary, signed updates of a widely used management product. Public reporting established that some of those updates had been trojanized through the vendor's build process. Customers who did nothing wrong in the narrow sense of "we patched" still received a harmful build. The interview lesson is about what you can say under pressure without pretending you investigated the world. You can say that trust in a signed update is only as strong as the build that produced it. You can say you would want provenance, a bill of materials, and a way to know which digest you ran. You can say you would rotate credentials that a management tool could have reached, on systems you own, and that you would separate a monitoring tool's identity from crown-jewel data. You can say detection and inventory, not heroics. You cannot say you would have personally caught it because you hold a badge. Many capable teams were affected. A certificate would not have been a shield, and the absence of a certificate was not the cause. If a panel asks "how would you hack that build system," you do not answer with a method. You answer with the controls: locked-down build identities, reviewed changes, reproducible artifacts, and alerts on a build process that reaches somewhere it should not. Those are Chapter 13 and Chapter 37, spoken calmly.

How to stop.

1. On systems you operate, identify whether you ran the affected product versions named in the vendor's advisory, using inventory rather than rumor.
2. Isolate management systems that were in scope and preserve logs.
3. Rotate credentials those systems could use.
4. Rebuild trust in the update path from a clean source the vendor and your own review agree on.
5. Tell your own stakeholders what you found, including a clear "not present" if the inventory supports it.

How to prevent it again.

1. Treat build systems and update channels as production.
2. Prefer artifacts you can tie back to a reviewed change and a digest.
3. Limit what a monitoring or admin tool can reach.
4. Practice saying this in an interview without adding imagined intrusion detail.
5. Do not go looking for trojanized updates on networks that are not yours.
6. Do not claim a certification would have prevented a supply-chain failure. No one honest can promise that.

This is for learning only, and only inside a system you are allowed to test.

39.5 A simple picture.

A spoken answer has three parts: the control, the evidence from your own lab, and the boundary. A badge is not in the picture. This course does not print one.

39.6 A short animation.

A badge-shaped outline appears, then fades. The three words remain: control, evidence, boundary.

39.7 Conclusion.

Raju spoke for ninety seconds about a localhost service, a debt row, and a drill note. He did not mention a certificate. Guru-ji looked almost pleased. "That is the end of this road. You can choose with numbers, troubleshoot with one lever, swap a tool without losing the objective, ship a toy honestly, and say so without a costume. None of that guarantees a job or an exam result. It is still the work. Go do it on systems you are allowed to touch."

• Speak from the lab you did. Ninety seconds is enough if the control is real.
• Point to Chapter 2 for formulas. Point to your notes for evidence.
• Certifications are other people's exams. This course awards none and guarantees none.
• SolarWinds, disclosed 13 and 14 December 2020, is the lesson that a trusted update still needs a build you can defend in words.
• Own lab only.

END OF CHAPTER 39 MASTER CLASS