Cresta DevOps Engineer Interview: Questions & Prep (2026)

Cresta builds real-time AI software for contact centre agents, helping them respond faster and more accurately during live customer calls. The company currently has 111 open roles, and its DevOps engineering positions sit at the heart of cloud infrastructure, Kubernetes operations, and ML model delivery pipelines.

The DevOps market in India is active. Knok jobradar tracked 811 DevOps Engineer roles as of July 2026, with Bangalore leading at 187 openings, followed by Delhi (40), Pune (37), Hyderabad (28), Chennai (13), and Mumbai (11). Salary bands from the same data:

Cresta's interview process typically spans a recruiter call, a technical screen, a hands-on infrastructure or coding round, and one or more behavioural conversations. Candidates report that interviewers care more about how you reason through real production problems than whether you can recite every kubectl flag from memory.

These questions come up repeatedly in Cresta DevOps interviews, based on publicly reported candidate experiences and the nature of Cresta's product stack.

1. Walk me through how you would design a CI/CD pipeline for an AI model serving application.
2. How do you manage secrets and credentials in a Kubernetes-based production environment?
3. Cresta serves real-time inference to contact centre agents. How do you deploy updates without causing downtime or latency spikes?
4. Describe your approach to cloud cost optimisation. What levers have you actually pulled?
5. How do you monitor a microservices architecture? What does your alerting strategy look like?
6. Tell me about a production incident you personally owned. How did you debug and resolve it?
7. How would you implement a canary or blue-green deployment strategy for a high-traffic SaaS product?
8. How do you enforce security and compliance in your infrastructure-as-code workflows?
9. Cresta's contact centre platform experiences traffic spikes that are hard to predict. How do you approach capacity planning for this kind of workload?
10. How have you worked with ML or product engineering teams to improve deployment or release workflows?
11. Describe a time you automated a manual operational task. What did you choose to automate first, and why?
12. A new deployment breaks production. Walk me through your rollback strategy and what you do next.

Use the STAR structure: Situation, Task, Action, Result. Keep each section concise. The examples below are templates, so replace company and tool names with your own.

---

Q: Walk me through how you would design a CI/CD pipeline for an AI model serving application.

*Situation:* At a previous SaaS role, our team was deploying ML models by manually copying artifacts to servers, which created inconsistent environments between staging and production and slowed down releases.

*Task:* I was asked to build a repeatable, automated pipeline that could handle both application code and model artifact promotion safely.

*Action:* I designed a multi-stage pipeline in GitHub Actions. Every pull request triggered linting, unit tests, and a container security scan in parallel. For model artifacts, I added a validation step that checked accuracy metrics against a held-out dataset before any artifact was promoted. I containerised the model server with Docker and wrote Helm charts for Kubernetes deployments. I introduced canary releases so a new model version received a small slice of live traffic before full rollout, with automatic rollback if error rates crossed a defined threshold.

*Result:* Staging-to-production parity issues were eliminated. Rollback events dropped noticeably, and the engineering team gained confidence shipping model updates more frequently.

---

Q: Tell me about a production incident you personally owned. How did you debug and resolve it?

*Situation:* Our contact centre application started showing high response latency spikes during peak business hours, directly affecting live agent sessions.

*Task:* I was the on-call engineer and needed to identify the root cause and restore normal performance quickly.

*Action:* I started by checking Grafana dashboards and followed slow traces through Jaeger to isolate which service was the bottleneck. I found that a downstream microservice was exhausting its database connection pool during peak load, causing queries to queue. I applied an immediate configuration change to increase the pool size and added a Kubernetes HPA rule to scale the service horizontally when CPU and queue depth crossed defined thresholds. I then opened an incident document and looped in the relevant engineers.

*Result:* Response latency returned to normal shortly after applying the fix. I followed up with a post-mortem, added a dashboard alert for connection pool saturation, and updated runbooks so the next on-call engineer would catch this pattern much faster.

---

Q: Describe a time you automated a manual operational task.

*Situation:* Our team was manually rotating IAM credentials on a quarterly schedule. The process was time-consuming and prone to human error, including cases where rotations were missed or applied to the wrong environment.

*Task:* I was asked to eliminate manual rotation entirely and ensure every rotation event was auditable.

*Action:* I wrote a Python script using the AWS SDK to rotate credentials automatically and store updated secrets in AWS Secrets Manager. I packaged this as a scheduled AWS Lambda function with SNS alerts for any failure. I also wrote Terraform to manage the Lambda, its IAM role, and the SNS topic so the whole setup was version-controlled and reviewable via pull request.

*Result:* Credential rotation became fully automated with a complete audit trail for every event. The team reclaimed the hours previously blocked for this task each quarter, and missed rotations became a non-issue.

STAR (Situation, Task, Action, Result) works for any behavioural question. Keep the Situation brief (one or two sentences), spend most of your time on Action, and make the Result concrete even if you cannot quantify it precisely.

Situation-Complication-Resolution is better for incident or debugging stories. Lead with the normal state, explain what broke and why it mattered, then walk through how you fixed it. Cresta interviewers often probe deeper with 'what did you check first?' so be ready to walk through your actual thought process step by step.

Constraints-Components-Trade-offs works well for system design questions. Start by confirming what matters most (latency, cost, availability), sketch the main components and data flow, then explain the trade-offs you consciously accepted. Interviewers at product-led AI companies typically want to hear you talk about trade-offs, not just describe an ideal architecture.

The 'so what' close: end every answer by connecting the result back to business impact. 'Deployment time went down' is weaker than 'deployment time went down, so the team could ship model improvements to agents without waiting for a weekly release window.'

Ownership over tickets. Cresta interviewers typically want to see that you drove an outcome, not just completed a task. Use 'I' when describing decisions you made, even when working in a team context.

Comfort with AI/ML workloads. Cresta's core product is ML-driven, so expect questions about model artifact management, inference infrastructure, and how DevOps workflows differ for ML compared to traditional application deployments.

Observability as a first-class concern. Candidates who mention monitoring, alerting, and tracing as part of their design (not as an afterthought) stand out. Have a clear point of view on what 'good' observability looks like for a real-time SaaS product.

Security by default. Infrastructure-as-code, least-privilege IAM, secrets management, and supply-chain security (container scanning, dependency audits) come up often. Be ready to explain how you have baked security into pipelines rather than bolted it on.

Collaboration across teams. DevOps at a product company like Cresta means working closely with ML engineers, product engineers, and sometimes customer-facing teams. Interviewers look for evidence that you can align on deployment contracts and on-call responsibilities without friction.

Week 1: Core technical review.
Revise Kubernetes concepts: pods, deployments, services, HPA, resource limits, and namespaces. Review your chosen CI/CD tool (GitHub Actions, GitLab CI, or similar) and be ready to sketch a pipeline in a shared document or on a whiteboard. Revisit Terraform or Pulumi basics and be comfortable discussing state management and remote backends.

Week 2: Cresta-specific preparation.
Read Cresta's engineering blog and any public talks or podcasts featuring their engineering team. Note the tools and patterns they mention. Think about how ML model lifecycle management differs from standard application deployment, and prepare at least one story from your own experience that connects to this.

Days before the interview.
Prepare three to five STAR stories covering: a production incident, a pipeline or automation project, a cross-team collaboration, and a situation where you had to make a trade-off under pressure. Practice saying them aloud so they feel natural rather than rehearsed.

On the day.
For any system design question, confirm constraints before drawing components. Ask clarifying questions: 'Is the primary concern latency or cost?' Thinking out loud signals the reasoning interviewers are actually evaluating, not just the final answer.

Describing what the team did instead of what you did. Saying 'we built' is fine for context, but interviewers want to know your specific contribution and decision-making. Switch to 'I' when explaining choices.

Skipping observability in system design answers. Candidates who design a pipeline or infrastructure without mentioning metrics, logs, or alerts often lose points even when the architecture is otherwise solid. Build observability into your answer from the start.

Over-engineering the answer. Cresta interviewers typically want pragmatic solutions. Proposing a complex multi-cluster service mesh for a straightforward deployment question can signal poor judgment about when complexity is actually warranted.

Generic answers to company-specific questions. Questions about real-time AI inference or contact centre workloads are invitations to show you understand Cresta's domain. Tie your answer to the constraints of real-time, low-latency ML serving rather than giving a textbook response.

Not asking thoughtful questions at the end. Questions about on-call rotation, incident retrospectives, and how DevOps and engineering teams share ownership of reliability show genuine interest and role-fit. Candidates who skip this step often leave a weaker impression than their technical answers deserve.