Rafat Rahman September 17, 2026 · Transfotech Academy
Meet the DevSecOps and DevOps instructor behind Transfotech Academy’s bootcamp, and why students rotate through every role instead of watching a demo.
It’s 2:47 a.m.
Somewhere in a data center that isn’t his, a graph just bent the wrong way. Response times that were sitting comfortably at 300 milliseconds have tripled. Nobody pushed a bad button on purpose. Somebody just deployed something that looked fine in every test, and now it isn’t fine at all.
Rafat Rahman’s phone is buzzing on the nightstand.
This is not a story from a textbook. It’s the kind of night that happens to real DevOps and DevSecOps engineers, on real systems, more often than most people outside the industry ever hear about. And it’s the reason Transfotech Academy’s DevSecOps Mastery bootcamp has an instructor who teaches DevSecOps the way he does.
The DevOps Job Nobody Warns You About
Before Rafat was teaching DevSecOps, he was one more engineer in a chain of engineers, moving through Bank of America, JPMorgan Chase, and GEICO, doing the kind of platform engineering and cloud security work that keeps money moving safely between banks, cards, and customers. Now he splits his time between Microsoft and the U.S. Department of Defense. On paper, that’s ten-plus years of steadily rising titles across DevOps, cloud security, and platform engineering.
What the titles don’t say is what the job actually feels like from the inside.
Picture three separate rooms in the same office. In one room, a developer is trying to ship a feature by Friday. In the next room, a security engineer is holding up that same feature because a CI/CD pipeline scan flagged something. In the third room, a site reliability engineer, or SRE, is staring at a dashboard at 3 a.m., trying to figure out why the app just got slow, with no idea that the first two rooms are connected to the fire they’re currently fighting.
That’s the old shape of the industry, the DevOps world before DevSecOps closed the gap between it. Three rooms, three job titles, and a wall between each of them thick enough that nobody in one room really understands what the other two are dealing with. The developer thinks the security team is just slowing things down. The security team thinks the developer is careless. And the SRE getting paged at 3 a.m. is stuck holding a problem that was actually created two rooms ago, by someone who’s already asleep.
Rafat worked in all three of those rooms over the course of his DevOps and cloud security career. Not as a visitor, as a resident.
Where DevOps Breaks and DevSecOps Steps In
Here’s where it gets uncomfortable, and here’s where most people’s understanding of “cybersecurity” or “DevOps” runs out.
The real fights in this field don’t happen between a company and a hacker. They happen between the people who are supposed to be on the same team. A shift-left security scan, the kind of automated check DevSecOps builds directly into a CI/CD pipeline instead of bolting on at the end, finds something two days before a launch, and now someone has to decide, right now, under pressure, whether to block the release or let it through and hope for the best. That decision gets made by a person, in a room, with a clock running.
And it isn’t always a security problem. Sometimes it’s operational, the kind of incident an SRE lives for and dreads in equal measure. A Kubernetes deployment goes out that passed every test, and forty minutes later the app is crawling for real customers, and now the question isn’t “was this coded safely,” it’s “do we roll it back right now or do we try to patch it live while people are actively using the thing that’s broken.” Those two situations feel completely different to live through, even though from the outside they might both sound like “something went wrong.” One is a slow-burn discovery. The other is a live fire with an audience.
This is the part Rafat has said, in his own words to his students, is the thing nobody tells you when you’re starting out: the job isn’t really about knowing the tools. Anyone can learn Terraform or Kubernetes from a video. The job is about being the person who has to make a call between two bad options, fast, while other people are watching and waiting on you.
He’s been that person. Repeatedly. Across a payments-adjacent banking career and now inside two of the highest-scrutiny environments a DevOps or cloud security engineer can work in, a global tech company and a federal defense agency. That’s not a resume line. That’s a person who has personally sat with the exact kind of decision his DevSecOps bootcamp students will eventually have to make on their own, in a job, without a professor standing behind them.
Why He Teaches DevSecOps by Rotating Every Role
So when Rafat sat down to help build the DevSecOps Mastery program at Transfotech Academy, he didn’t design a course where students watch him do the hard part.
He built one where students live the friction themselves.
Every student in the bootcamp works on the same simulated system for all sixteen weeks, a mock payments application called PayCore, similar in spirit to the software behind a real online checkout. And every student rotates through all three rooms, and a fourth. One week they’re the developer writing the code. The next, they’re the security engineer reviewing someone else’s code for danger inside a CI/CD pipeline. Later, they’re the SRE watching the dashboards after launch, using tools like Prometheus and Grafana to catch trouble before it becomes an outage. Along the way, they also work hands-on with the same infrastructure-as-code and container tooling real DevOps and DevSecOps engineers use daily, including Terraform, Docker, and Kubernetes. At the very end, in the capstone, they live through two full incidents exactly like the ones Rafat has lived through: one is a security flaw that slipped past a gate somebody configured too loosely, and one is an operational failure, a deployment that quietly makes everything three times slower, and they have to decide, under a ticking clock, whether to roll it back or fix it live.
That structure isn’t decoration. It’s the whole point. A person who has only ever coded, and never had to be the one blocking someone else’s code, doesn’t understand why that block happens or what it costs. A person who has only ever been the security reviewer doesn’t feel what it’s like to get paged at 3 a.m. for a problem they didn’t create. Rotating through all four roles, developer, release engineer, security engineer, and SRE, is how you build the kind of instinct that can’t be taught from a slide. You have to have stood in each room to understand why the other rooms behave the way they do.
That’s the real gap this DevSecOps bootcamp is trying to close. Not a knowledge gap. An empathy gap between DevOps roles that most companies never bother to close, and pay handsomely for the rare person who’s already closed it themselves.
Rafat closed it the hard way, over a decade, one page at a time. His students get to close it in sixteen weeks, on a system built to break in the exact same ways his real systems did.
DevSecOps FAQ
What is DevSecOps, in plain terms?
It’s a way of building software where security isn’t a separate team that checks your work at the end. Instead, security checks happen automatically, all the way through the CI/CD pipeline, every time code is written, tested, and shipped. Instead of three separate rooms passing work to each other, it’s one team sharing the same responsibility the whole way through.
How is DevSecOps different from regular DevOps?
DevOps is about building and releasing software quickly and reliably. DevSecOps takes that same fast pipeline and builds security checks directly into it, a practice often called shift-left security, instead of bolting security on as a final review right before launch. The difference shows up under pressure: in the older DevOps model, a security problem found late can block an entire release. In DevSecOps, most of those problems are caught early enough that they never become a last-minute crisis.
Do I need a coding background to get into DevOps or DevSecOps?
It helps, but it isn’t a hard requirement everywhere. People coming from QA, IT support, or general sysadmin work often already touch pieces of this pipeline without realizing it. What matters more is being comfortable learning tools hands-on and being willing to sit with a problem instead of walking away from it.
What tools do DevSecOps and cloud security professionals actually use day to day?
Common ones include Terraform for building cloud infrastructure with code instead of manual clicking, Docker and Kubernetes for packaging and running applications consistently, and scanning tools like Snyk or Trivy that check code and containers for known weaknesses before anything goes live. None of these are learned in isolation in a good DevSecOps bootcamp. They’re learned in the order a real release actually happens.
What kind of salary can a DevSecOps or cloud security career lead to, by job title?
Pay varies by role, seniority, location, and which data source you trust, so treat the ranges below as US market context, not a promise tied to any individual. They reflect the roles this kind of training points toward, from entry-level up through senior.
| Job title | Typical US salary range (2026) |
|---|---|
| Junior / Entry-level DevSecOps Engineer | $85,000 – $110,000 |
| DevOps Engineer | $95,000 – $140,000 |
| Release Engineer | $100,000 – $145,000 |
| Cloud Security Engineer | $105,000 – $155,000 |
| Site Reliability Engineer (SRE) | $110,000 – $160,000 |
| Security Engineer | $110,000 – $165,000 |
| Platform Engineer | $120,000 – $170,000 |
| Senior DevSecOps / Cloud Security Engineer | $150,000 – $210,000+ |
Across the field as a whole, that spans roughly $95,000 to $210,000, entry to senior. Source: ZipRecruiter national 25th-75th percentile data, Salary.com, and Glassdoor, pulled September 2026. Totals run higher at large tech, aerospace and defense, and financial services employers once bonus and equity are counted, and lower at smaller companies or lower cost-of-living regions.
Is DevSecOps training something I can learn while working full-time?
That’s how most people in this field actually learn it: live, twice a week, alongside a current job, rather than in a full-time bootcamp format. The idea is to build the skill in real time, not memorize it in a vacuum.
What’s the hardest part people underestimate about DevOps and DevSecOps work?
Almost never the tools themselves. It’s the judgment calls, deciding whether to block a release, whether to roll back or hotfix a live problem, when to accept a small risk versus when to stop everything. That’s the part that only comes from actually being put in the room and having to decide.
