Manifest DevOps Engineer Interview: Questions & Prep (2026)

Manifest currently has 8 open DevOps Engineer roles, tracked by knok jobradar as of July 2026. DevOps hires at technology companies like Manifest typically work across cloud infrastructure, CI/CD automation, and site reliability engineering. Candidates report a process that includes a recruiter screening, one or two technical rounds, and a final discussion with the engineering lead or hiring manager. Round structure varies by team, so treat any format you read about as typical rather than guaranteed.

Salary ranges broadly in line with the wider DevOps market in India:

These figures come from knok jobradar data for July 2026 and reflect the broader Indian DevOps market. Actual offers at Manifest will depend on your experience, the specific team, and how well you negotiate.

Based on patterns candidates report for DevOps roles at product companies, expect a mix of hands-on technical questions and behavioral scenarios. Here are 12 questions to prepare for:

1. Walk us through a CI/CD pipeline you built end-to-end. What tools did you choose and why?
2. How do you handle a production outage? Walk us through your incident response step by step.
3. What is the difference between containerisation and virtualisation? When would you use Kubernetes over plain Docker?
4. How have you used Infrastructure as Code tools such as Terraform or Ansible in past projects?
5. Which cloud platform have you worked on most, and which services do you use for a typical microservices deployment?
6. How do you monitor application and infrastructure health? What kinds of alerts have you set up, and what have they caught?
7. How would you secure a Kubernetes cluster running in production?
8. Describe a time you improved deployment frequency or significantly reduced downtime for your team.
9. How do you manage secrets and sensitive configuration inside your CI/CD pipelines?
10. Tell us about a deployment you pushed that caused a production issue. What happened, and how did you resolve it?
11. What is your approach to writing runbooks and documentation for infrastructure you own?
12. How do you balance cost optimisation on cloud infrastructure with keeping reliability high?

Q: Tell us about a deployment you pushed that caused a production issue. What happened and how did you resolve it?

*Situation:* At my previous company, I pushed a Terraform change that updated a security group rule on our main application load balancer. The change was meant to tighten access, but it accidentally blocked traffic from our internal health-check service.

*Task:* I needed to identify the root cause quickly, restore service, and prevent the same mistake from happening again.

*Action:* I checked our cloud monitoring logs immediately and saw health-check failures spiking right after the apply. I reverted the Terraform change using a targeted plan and apply. Then I set up a staging VPC that mirrored our production networking layout so future changes could be tested before going live. I also introduced a pre-apply policy check to flag any rule that removed existing CIDR blocks from critical security groups.

*Result:* Service was fully restored. The staging environment caught similar issues before they could reach production in the weeks that followed. The team adopted the pre-apply policy check as a standard step in the release checklist.

---

Q: Describe a time you improved deployment frequency or significantly reduced downtime for your team.

*Situation:* Our team was doing manual deployments every two weeks. Each release required several engineers, took most of a working day, and often ended with at least one rollback.

*Task:* I was asked to own a CI/CD modernisation effort as part of a broader platform reliability initiative.

*Action:* I mapped every manual step in the existing release process and moved each one into a GitHub Actions pipeline. I added automated unit and integration test gates, a canary deployment stage on ECS, and an automatic rollback trigger tied to our error-rate alarm. I also ran short sessions with the development team so they could read pipeline failures without needing to call me each time.

*Result:* We moved from fortnightly releases to daily deployments within a quarter. Rollbacks dropped noticeably, and the team reported spending far less time on release coordination. The engineering lead cited this work in the next quarterly review.

---

Q: Walk us through a CI/CD pipeline you built end-to-end.

*Situation:* A startup I worked for had no automated deployment process. Every release involved SSH-ing into instances and running scripts by hand.

*Task:* I was the first DevOps hire, responsible for designing and implementing a repeatable, auditable pipeline from scratch.

*Action:* I chose GitHub Actions because the team was already using GitHub for version control. Each pull request triggered linting, unit tests, and a Docker image build. On merge to main, the pipeline pushed the image to ECR, updated a Terraform-managed ECS service using a blue/green strategy, and sent a Slack notification with the deployment summary. Secrets were stored in AWS Secrets Manager and injected at runtime, never written into environment files.

*Result:* The team went from deployments that consumed most of an afternoon to a fully automated pipeline that completed well within the hour. Onboarding new developers became easier because the pipeline was documented as code and straightforward to follow.

For technical 'how does X work' questions: Start with the concept in one or two plain sentences. Give a concrete example from your own work. Finish by naming one trade-off or limitation. This structure shows you understand both the theory and the real-world messiness.

For behavioral 'tell me about a time' questions: Use the STAR structure: Situation (set the context briefly), Task (what you were specifically responsible for), Action (what you personally did, not what the team did), Result (what actually happened, with a concrete outcome where possible). Keep Situation and Task short. Spend most of your time on Action.

For 'how would you approach' design questions: State your default choice and the reason for it, then immediately acknowledge what would make you choose differently. For example: 'I would default to Terraform because our team already knows it, but if the project were heavily GCP-centric I would consider Pulumi or Deployment Manager instead.' This signals engineering maturity.

For debugging or incident questions: Walk through your thinking out loud. Interviewers at DevOps-focused companies typically care more about your debugging process than whether you land on the right answer immediately. Narrate: observe the symptom, form a hypothesis, isolate the variable, test, then iterate.

Hands-on depth, not just tool names. Listing Kubernetes on your resume is table stakes. Interviewers will probe whether you have actually debugged a crashlooping pod, set resource limits, or managed RBAC. Be ready to go several levels deep on anything you claim.

Ownership mindset. DevOps roles at product companies reward engineers who treat the pipeline and infrastructure as their own product. Answers that show you spotted a reliability gap proactively, fixed it, and documented the fix land better than answers where you only reacted to assigned tickets.

Clear communication under pressure. Incident-response questions are partly a communication test. Interviewers want to see that you stay structured when things go wrong and that you can explain what is happening to a non-technical stakeholder without jargon.

Security awareness baked in. Candidates report that DevOps interviews at product companies frequently include at least one question on secrets management, IAM least-privilege, or network security. Do not treat security as an afterthought in your answers.

Collaboration with developers. Pure infrastructure siloes are out. Show that you have worked closely with dev teams: reviewing Dockerfiles, helping with local environment setup, or joining sprint rituals. This signals cultural fit as much as technical fit.

Two weeks before:
Review the core tools most commonly listed in DevOps job descriptions: Docker, Kubernetes, Terraform, and your primary cloud platform. If you have not used any of these recently, spin up a small personal project. Deploying a simple application end-to-end on a free-tier cloud account is one of the best ways to refresh hands-on muscle memory.

One week before:
Write out STAR answers for the most likely behavioral questions. Focus on three scenarios: a production incident you resolved, a process you improved, and a time you disagreed with a technical decision. Practice saying these out loud, not just writing them. Spoken answers often feel different from written ones.

Three to four days before:
Research Manifest specifically. Look at the job description carefully and map your experience to the listed requirements. If the JD mentions a specific tool (Helm, ArgoCD, Prometheus), make sure you can discuss it with real examples, not just definitions.

The day before:
Review your resume as if you are the interviewer. For every tool and project listed, prepare a one-minute explanation covering what problem it solved, what you built, and what you would do differently now. Prepare questions to ask the interviewer about the team's current infrastructure challenges and on-call culture.

Claiming tools you cannot go deep on. If your resume says 'Kubernetes', be ready for questions about pod scheduling, resource quotas, or network policies. Interviewers quickly spot a shallow listing. Only claim tools you can discuss in real detail.

Giving vague outcomes. 'We improved reliability' is weak. 'Rollbacks dropped and the team moved to daily deployments' is strong. Even without exact numbers, describe the direction and the magnitude clearly.

Skipping the 'why'. Explaining what you did is not enough. Interviewers want to know why you chose Terraform over Pulumi, or ECS over EKS. The reasoning demonstrates engineering judgement, not just execution.

Missing the lessons-learned angle. When asked about failures or mistakes, candidates who only describe what went wrong miss the real opportunity. The reflection on what changed afterward is usually what the interviewer is listening for most carefully.

Not asking questions. Arriving with no questions signals low interest. Ask about the team's biggest infrastructure pain point, how on-call is structured, or what a typical sprint looks like for the DevOps team. Good questions often leave a stronger impression than any single answer.