razorpay DevOps Engineer Interview: Questions, Experience & Prep (2026)

Razorpay is one of India's largest fintech companies, powering payments for a significant share of Indian businesses. As of July 2026, Razorpay has 42 open DevOps Engineer roles, while the broader DevOps market in India shows 811 active openings tracked across companies.

Candidates report the interview process typically spans three to five rounds: a recruiter screening call, one or two technical rounds focused on hands-on infrastructure knowledge, a system design discussion, and a hiring manager conversation. End-to-end timing is typically two to four weeks, though it can vary by team.

The focus areas that come up most consistently are Kubernetes cluster operations, CI/CD pipeline design, observability and alerting, incident response, and fintech-specific concerns like secrets management and compliance awareness. Because Razorpay handles real-money transactions at scale, interviewers probe reliability and security thinking more heavily than at a typical SaaS company.

Salary bands from the knok job radar data:

Among Indian cities, Bangalore leads DevOps hiring with 187 openings tracked, followed by Delhi at 40, Pune at 37, Hyderabad at 28, Chennai at 13, and Mumbai at 11.

These questions come up frequently in Razorpay DevOps interviews, based on candidate reports and the nature of Razorpay's payment infrastructure:

1. Walk me through how you would design a highly available Kubernetes cluster for a payment processing system. What does your node and networking architecture look like?

1. How do you manage secrets in a fintech environment? What tools and practices do you use to make sure credentials are never exposed in code, logs, or environment variables?

1. Describe your CI/CD pipeline setup in a previous role. How did you handle rollbacks when a bad deployment reached production?

1. How would you set up monitoring and alerting for a critical payment API that must maintain high availability? Walk us through your tooling choices and how you decide what to alert on.

1. Tell us about a production incident you owned from detection to resolution. What did you detect first, how did you diagnose, and what changed afterward to prevent recurrence?

1. What is your approach to infrastructure as code? Walk us through a real Terraform or Pulumi implementation you built, including how you structured state and managed environment differences.

1. Razorpay sees sudden traffic spikes during sale events and festival seasons. How would you design auto-scaling to absorb a large, sudden surge without dropping transactions?

1. How do you approach disaster recovery for stateful workloads like databases? How do you think about recovery time and recovery point objectives when designing for a payments environment?

1. What compliance requirements have you worked with in a payments or regulated environment? How did those requirements change how your team ran DevOps?

1. Have you worked with a service mesh like Istio or Linkerd? What problem were you solving and what trade-offs did you run into?

1. How do you handle database schema migrations in a microservices setup without causing downtime for services that depend on that schema?

1. What steps have you taken in a previous role to reduce cloud infrastructure costs while keeping performance SLAs intact?

Q: Tell us about a production incident you owned from detection to resolution.

*Situation:* At my previous company, our payment callback service started dropping responses intermittently during peak hours. Customers were seeing failed transactions even though payments had actually gone through, which caused a spike in refund requests and support tickets.

*Task:* I was the on-call engineer that evening and owned the incident from the first alert through to the post-mortem.

*Action:* I pulled metrics from our Prometheus dashboards and saw error rates climbing on the callback service from one specific node. I cross-referenced with our log aggregation tool and found that node was hitting its file descriptor limit because of a connection leak introduced in a recent deployment. I cordoned that node, drained its pods onto healthy nodes, and restarted the affected service. I filed a high-priority ticket for the dev team about the connection leak and added a file descriptor utilization alert to our Alertmanager rules before signing off that night.

*Result:* Service returned to normal within roughly 15 minutes of diagnosis. The post-mortem confirmed the root cause, the dev team patched the leak in the next release, and the new alert caught a similar issue in a different service a few weeks later before it became an incident.

---

Q: Describe your CI/CD pipeline setup. How did you handle rollbacks when a deployment broke production?

*Situation:* My team ran a microservices platform on AWS using EKS, and we had slow, risky releases that required manual steps and caused regular late-night incidents for the on-call rotation.

*Task:* I was asked to own the CI/CD redesign to move us toward continuous deployment with reliable, fast rollbacks.

*Action:* I built a pipeline using GitHub Actions for build, lint, and test gates, with ArgoCD handling GitOps-based deployment to Kubernetes. For our most critical payment services, I implemented a blue-green deployment strategy: the new version was deployed alongside the current one and traffic only switched over after health checks passed. For rollback, ArgoCD history let us revert to the previous Git revision in under two minutes with no manual steps.

*Result:* Deployment frequency increased from roughly once a week to multiple times a day. The first time a bad build went out, the team rolled it back in under two minutes with zero customer impact. That single event built more confidence in the process than months of documentation would have.

---

Q: How would you design auto-scaling to handle a sudden traffic surge for a payment system?

*Situation:* At a previous role, our platform served e-commerce merchants and saw large traffic spikes during Diwali sales and end-of-month payment cycles that sometimes overwhelmed our infrastructure.

*Task:* I needed to design an auto-scaling architecture that could absorb sudden, large increases in transaction volume without dropping requests or degrading latency.

*Action:* I combined Kubernetes Horizontal Pod Autoscaler based on custom metrics (requests per second and queue depth, not just CPU) with Cluster Autoscaler for node-level scaling. For known high-traffic events, I added a scheduled pre-scaling job using a Kubernetes CronJob that ramped up replicas an hour before expected peak load, so we were not racing against scaling lag during the surge itself. I also worked with the database team to configure read replicas and PgBouncer for connection pooling, because we found the database layer saturated before the application layer did during traffic spikes.

*Result:* During the next major sale event, the platform scaled to meet peak load with no engineer intervention. Latency stayed within our agreed SLA targets throughout and we had no transaction drops attributable to infrastructure capacity.

Three frameworks cover most Razorpay DevOps interview questions effectively:

STAR for behavioral questions (incident response, process improvements, team decisions): Open with the Situation briefly, state your Task, then spend the most time on Actions with specific technical detail, and close with a concrete Result. Candidates typically rush through the Action step. That is where the interviewer is evaluating your depth, so slow down and name the tools, commands, and decisions you actually made rather than summarizing at a high level.

Design-then-trade-off for system design questions: Before sketching any architecture, clarify requirements: availability target, expected scale, latency SLA, and budget constraints. Then describe your design component by component, and for each major choice, name the alternative you considered and why you picked what you did. Razorpay interviewers typically care less about a single 'right answer' and more about how you reason through constraints. Reliability and data integrity trade-offs come up in nearly every system design round at a payments company.

Problem-first for tool questions: When an interviewer asks about a specific tool (Terraform, Istio, Prometheus), lead with the problem you were solving before you describe the tool. 'We had config drift across three environments that caused a payment service outage, which is why I introduced Terraform with separate state per environment' is far more compelling than a list of features. The problem gives your answer context; the tool is just your solution.

Candidates who do well in Razorpay DevOps interviews tend to show a few consistent signals:

Ownership under pressure. Payment failures have immediate financial impact. Interviewers want to see that when something breaks, you move toward the problem rather than escalating it away. Be ready to describe an incident in granular detail, including exactly what you personally did rather than what 'the team' did.

Security-first thinking. Razorpay operates in a regulated payments environment. Interviewers notice when a candidate mentions secrets vaults, least-privilege IAM policies, Kubernetes network policies, and audit logging without being prompted. You do not need to be a security specialist, but treating security as a natural part of infrastructure design signals the right mindset for fintech.

Comfort with scale. Candidates who can speak to designing for horizontal scale, whether through stateless services, queue-based decoupling, read replicas, or connection pooling, tend to be taken more seriously than those whose experience is limited to smaller deployments.

Pragmatic tool choices. Interviewers at Razorpay look for judgement, not tool collection. Candidates who reach for the simplest tool that solves the problem, and can explain why, tend to do better than those who propose complex architectures for straightforward requirements. Over-engineering without justification is one of the clearest red flags reported.

Clear communication of trade-offs. DevOps decisions at scale always involve trade-offs between cost, reliability, speed, and complexity. Candidates who can articulate trade-offs clearly show that they have actually implemented these systems and dealt with their real consequences, not just read about them.

A focused preparation approach for the Razorpay DevOps interview process:

Week one: Kubernetes depth. Review pod scheduling (node affinity, taints, and tolerations), resource requests and limits, Horizontal Pod Autoscaler configuration using custom metrics, persistent volumes for stateful workloads, and Kubernetes network policies. Practice explaining each concept out loud, not just reading about it. Shallow Kubernetes knowledge is one of the fastest ways to get screened out in Razorpay technical rounds, based on candidate reports.

Week two: CI/CD and GitOps. Pick one pipeline you have built, or study a reference architecture, and be ready to walk through it end to end: source control triggers, build and test gates, deployment strategy (blue-green, canary, or rolling), and rollback mechanism. If you have ArgoCD or Flux experience, review how GitOps reconciliation works. If not, read through the core GitOps concepts before the interview.

System design prep: payment gateway focus. Practice a scenario where a service receives payment events, processes them reliably, and delivers callbacks to merchants. Work through the failure modes: what happens if the callback endpoint is down? How do you guarantee at-least-once delivery without duplicating charges? These scenarios come up at Razorpay more than generic distributed system problems.

Security and compliance basics. Review how HashiCorp Vault or AWS Secrets Manager works for dynamic secret injection. Know how to write a basic Kubernetes network policy. Read a brief overview of what PCI-DSS broadly requires from an infrastructure standpoint. High-level awareness is valued in fintech DevOps interviews, even if you have not worked in payments before.

Behavioral story prep. Prepare two or three strong STAR stories covering an incident you resolved, a process improvement you drove, and a technical disagreement you navigated. Practice delivering each in three to four minutes with specific technical detail rather than high-level summaries.

While you are deep in preparation, knok checks 150+ job sites nightly, applies to DevOps roles that match your resume, and messages HR on your behalf, so applications keep going out while you focus on acing the interviews.

Mistakes that come up most often in Razorpay DevOps interviews, based on candidate feedback:

Listing tools without context. Saying 'I know Kubernetes, Terraform, and Prometheus' without connecting each to a problem you solved reads as shallow experience. Always anchor a tool to a specific use case and the outcome it produced.

Vague incident responses. Saying 'we had a production issue and the team fixed it' tells an interviewer nothing useful. They want the timeline, your specific diagnostic steps, the root cause you identified, and what changed afterward to prevent recurrence. Vague incident answers are one of the most commonly cited reasons candidates do not progress past the technical round.

Skipping security in design questions. Candidates who design infrastructure without mentioning IAM roles, network segmentation, or secrets handling tend to be marked down in fintech interviews. Security awareness is a baseline expectation for a DevOps engineer at a payment company, not a specialist skill.

Over-engineering. Proposing a complex multi-region active-active architecture for a straightforward availability question suggests poor judgement about when complexity is justified. Start with a simple design and add complexity only when the interviewer introduces constraints that require it.

Jumping into design without clarifying requirements. Walking into a system design question and immediately drawing an architecture is a common mistake. Interviewers at Razorpay typically expect you to spend a few minutes clarifying availability requirements, expected load, and constraints before designing anything.

Using 'we' instead of 'I' in behavioral rounds. Behavioral questions are asking about your individual contribution. Defaulting to 'we did this' makes it hard for an interviewer to assess what you specifically brought to a situation. Use 'I' to describe your actions, even when the work involved a larger team.