Private corporate batches, live online cohorts and 1-on-1 mentoring in runtime threat detection from kernel and audit events — drivers, rules, tuning, enrichment and alert response — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches Falco as detection engineering rather than as a Helm install: how the driver captures events and what each option costs, how a rule condition is built from typed event fields, why the shipped rule set is a starting point, and how to express an exception without silently removing coverage. Sessions run against live clusters with generated benign and suspicious activity, and cover the operational surface most teams hit second — event drops on busy nodes, alert routing through Falcosidekick, plugin-based sources such as Kubernetes audit logs, and measuring which techniques you actually detect.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Falco that means a trainer who has run it in production — runtime threat detection from kernel and audit events — drivers, rules, tuning, enrichment and alert response — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Falco batchFalco is a runtime security tool that watches what processes actually do and raises an alert when the behaviour matches a rule. It taps the system call stream from the kernel — through a modern eBPF probe, a legacy eBPF probe or a kernel module — enriches each event with container, Kubernetes and process context, evaluates it against a rule set, and emits a structured alert. It is a graduated CNCF project and the reference open-source answer to the question of what is happening inside a running container right now.
The distinction that matters is when Falco operates. Image scanning tells you a container has a vulnerable package before it runs. Admission control tells you a manifest breaks policy before it is accepted. Falco only speaks once the workload is live, and it detects behaviour rather than configuration: a shell spawned inside a container, a write to a binary directory, an outbound connection from a process that has never made one, a read of a service account token, a container starting with elevated privileges. None of those are visible to a scanner, because none of them exist until runtime.
A Falco deployment is really three things. The driver determines how events are captured and is the main compatibility and performance decision. The rules — built from rule, macro and list definitions, matched against typed event fields — determine what is detected, and are where almost all the real engineering effort goes, because the default rule set is a starting point rather than a finished product. And the output layer, usually Falcosidekick, routes alerts onward to a SIEM, a chat channel, a webhook or a response engine, which is what turns a log line into something an on-call engineer will act on.
Containers removed most of the visibility that host-based security assumed. A workload appears, runs for eleven minutes and disappears, taking any local evidence with it, and its filesystem is a read-only image so traditional endpoint tooling has little to attach to. At the same time the workload count exploded, so the question moved from watching servers to detecting behaviour across a fleet of short-lived processes.
Runtime detection has also become a stated requirement. Container security guidance and the maturity models used in security reviews now ask specifically for runtime monitoring, not only image scanning, and the answer teams are expected to have is a behavioural detection layer on the cluster. Falco is the open-source option that most organisations reach for, and it is embedded inside several commercial platforms as well.
The skill gap is in tuning and operation rather than installation. A Helm chart puts Falco on every node in ten minutes; what follows is a stream of alerts that mostly describe normal behaviour in that specific environment, and the common outcome is that the alerts get muted and the deployment quietly stops mattering. Knowing how to write a rule that asserts something real, express exceptions without deleting coverage, keep event drops at zero on a busy node, and route alerts so someone acts on them is what separates a working detection layer from an installed one.
The detection gap that runtime tooling exists to close. What image scanning, admission control and runtime detection each catch, why container workloads defeat traditional host security, and Falco's architecture end to end — capture, enrich, evaluate, emit.
Topics: Build-time, admission-time and runtime controls compared · Why short-lived containers break host-based security assumptions · Falco architecture: driver, libs, rule engine, outputs · The syscall event stream and what it reveals · Falco compared with commercial runtime protection and with audit logging · What Falco detects and what it explicitly cannot · Installing Falco and triggering a first alert
How events are actually captured, which is the decision with the largest compatibility and performance consequences. Modern eBPF, legacy eBPF and the kernel module compared, deployment as a DaemonSet or a host service, and the configuration file that controls buffers, outputs and rule loading.
Topics: Modern eBPF, legacy eBPF and kernel module drivers compared · Kernel version, CO-RE and driver compatibility · Deploying on Kubernetes as a DaemonSet, and on plain hosts · Helm values that actually matter, and the defaults to change · falco.yaml: rule file ordering, buffers, output channels · Running Falco alongside a managed Kubernetes control plane · Verifying capture health before trusting any alert
Where detection actually happens. The rule object and its fields, macros and lists for reuse, condition syntax, priorities, and output templates. Then the discipline of writing a rule that states a hypothesis and produces an alert containing everything the responder needs.
Topics: Rule anatomy: condition, output, priority, tags · Macros and lists, and structuring a rule file for reuse · Condition operators, comparisons and set membership · Priorities and mapping them to real severity · Output templates and formatting fields into an actionable alert · Rule file ordering, appends and overrides · Validating rules and dry-running against captured events
The data a condition can reason about. Syscall, process, file, network and user field classes, container and Kubernetes metadata enrichment, and the plugin framework that lets Falco consume entirely different event sources such as Kubernetes audit logs and cloud provider audit trails.
Topics: Field classes: evt, proc, fd, user, group, container · Kubernetes metadata enrichment and how it is resolved · Filtering on image, namespace, label and service account · The plugin framework and event sources beyond syscalls · The Kubernetes audit log plugin and what it uniquely detects · Cloud audit trail plugins and their event fields · Combining syscall and audit-source rules in one deployment
The module that decides whether the deployment survives. Establishing a baseline of normal behaviour, expressing exceptions precisely, using rule overrides rather than deletions, and recording what every piece of tuning cost in coverage terms so the decision can be reviewed later.
Topics: Baselining normal behaviour before tuning anything · The exceptions field and precise, narrow exclusions · Overriding shipped rules instead of forking the rule set · Environment-specific allowlists and their expiry · Recording the coverage cost of every suppression · Managing rules as code: repository, review and CI validation · Regression testing rules against captured event data
An alert nobody receives is not a detection. Falcosidekick as the fan-out layer, routing by priority and rule to the right destination, integrating with a SIEM and with chat, and the response layer — automated actions with guardrails, and where a human decision must remain.
Topics: Output channels: stdout, file, gRPC, HTTP · Falcosidekick: outputs, routing and templating · Shipping to a SIEM and to log storage · Chat and paging integration with sensible severity mapping · Metrics and dashboards from alert streams · Automated response actions and the guardrails around destructive ones · Designing a response playbook per rule class
What breaks when it runs everywhere. Event drops and the buffer and filtering work that eliminates them, CPU and memory budgets per node, driver upgrades across a mixed kernel estate, and measuring coverage against real attacker techniques rather than counting rules.
Topics: Event drops: causes, detection and elimination · Buffer sizing, syscall filtering and reducing capture load · CPU and memory budgets on busy nodes · Upgrading Falco and drivers across mixed kernel versions · High-churn workloads and metadata resolution cost · Monitoring Falco itself with Prometheus · Mapping rules to MITRE ATT&CK and validating coverage by safe emulation · Reporting detection coverage honestly
We rebuild the agenda around the tools you actually run.
Request a custom agendaDeploy Falco with the modern eBPF probe and with the kernel module on the same node type, then compare compatibility, startup behaviour and measured overhead.
Write five rules from stated hypotheses, trigger each deliberately in a container, and rewrite the outputs until the alert alone tells a responder what to do.
Enable the Kubernetes audit log plugin and build detections for control-plane actions that never appear in the syscall stream.
Baseline a real cluster, cut alert volume by an order of magnitude using narrow exceptions, and record the coverage cost of every suppression.
Route alerts through Falcosidekick by priority to a SIEM, a chat channel and a webhook, then wire one guarded automated containment action.
Push a node to event drops and eliminate them, monitor Falco with Prometheus, then validate detection coverage by safely emulating three techniques.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Good discussion, helped us to understand different tools in SRE.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.