Infosys DevOps Engineer Interview Questions
DevOps engineers at Infosys often run the cloud platforms behind a client's online store or telecom customer services, where many squads release daily, sale days bring sudden traffic, and several companies share one on-call. Prepare to discuss rebuilding a client's confidence after a failed release, shared on-call across suppliers, scaling for a known peak, zero-downtime deployments, tracing across many services and cloud quotas. What to show here: platforms many teams can release to daily, ready for peaks. Each question below has what the interviewer is checking, an answer frame and a sample spoken answer to adapt.
How Infosys hires, in its own words, and its questions for every job →
1. Tell me about a time an automated release you had built failed on a client's platform and shook their confidence in automation. How did you win it back?
- Describe the failure and its effect.
- Explain how you found the cause and what you changed.
- Share how you showed the client the improvement.
- Give the result.
“A pipeline I built deployed a broken build of a retail client's search service, because a step that ran the smoke tests had been marked optional during an earlier rush and nobody noticed it was failing. The client's head of engineering asked whether we should go back to manual releases. I owned the mistake in the review. I made the smoke tests mandatory, added a check that fails the pipeline if any gate is skipped, and showed the client a dashboard of every gate on every release. Over the next weeks the record spoke for itself. The result was your result.”
Weak answers blame the person who marked the step optional, or answer the client with reassurance instead of changes.
2. Describe a time you set up on-call for a client platform where your team, the client's engineers and another supplier all owned parts of the system. How did you make it work?
- Describe the platform and who owned what.
- Explain how you mapped services to owners and escalation paths.
- Share the shared tools and rules you agreed.
- Give the result.
“On a telecom client's platform, the app was built by another supplier, the APIs by my team and the network integration by the client. Alerts went to a shared inbox and nobody was sure who should act. I built a simple service catalogue listing every service, its owner, and who to call at each level. Alerts were routed by service, and each company kept its own rota. We agreed one incident channel, one incident lead per incident regardless of company, and a joint review afterwards. It took a few rounds to get the catalogue right. The result was your result.”
Weak answers describe one team taking every alert, or three companies with three separate incident processes.
3. A retail client's biggest sale starts at midnight, and traffic will rise many times over within minutes. How do you prepare the platform so scaling is not left to chance?
- Load test to the expected peak and beyond, weeks before.
- Pre-scale before the start rather than relying on reactive scaling.
- Check downstream limits: databases, caches, third-party services.
- Prepare protections, dashboards and a rollback plan for the night.
“Reactive autoscaling is too slow for a jump that happens in minutes, so I would scale the platform up before midnight based on load tests run weeks earlier at higher than the expected peak. The tests usually show the real limit is not the web tier but a database connection pool, a cache or an external service with a call limit, so those get fixed or raised first. I would set a code freeze, prepare a queue at checkout that degrades gracefully, and rehearse turning off non-essential features. On the night, a shared dashboard and a clear owner for each decision matter more than any single tool.”
Weak answers trust autoscaling to handle the jump, or load test only the front end.
4. A telecom client's customer API runs on Kubernetes and is released several times a day. How do you make each deployment invisible to customers, including when the database schema changes?
- Roll out new pods gradually with readiness checks before they take traffic.
- Drain connections from old pods instead of killing them.
- Make every schema change compatible with the previous code version.
- Watch error rates during rollout and roll back automatically.
“I would use a rolling deployment where new pods start, pass a readiness check that tests real dependencies, and only then receive traffic. Old pods get a stop signal and time to finish in-flight requests before they exit. The hard part is the database. Each schema change must work with both the old and new code, so a column is added first, code that writes both is released, data is backfilled, and only later is the old column removed. Nothing is renamed in one step. The rollout watches error rates and latency and rolls back on its own if they rise.”
Weak answers stop all old pods before starting new ones, or apply a breaking schema change in the same release.
5. A client's store is made of many services owned by different squads, and when a shopper reports a slow checkout nobody can tell which service caused it. Design the observability that answers this.
- Pass one correlation id through every request from the browser to the database.
- Use distributed tracing so each request shows its path and timings.
- Standardise logs and metrics across squads.
- Build views per journey, such as checkout, not only per service.
“The key is one id that follows a shopper's request through every service. The browser creates it, each service passes it on and includes it in every log line. On top of that I would add distributed tracing, so a single checkout shows as a tree of calls with the time spent in each, and the slow one stands out. All squads use the same log format and the same metric names for latency and errors, enforced by a shared library. Then I would build dashboards by journey, such as checkout, that show every service involved, so the question is answered by looking, not by asking each team.”
Weak answers collect logs from each service separately with no way to connect them for one request.
6. Several suppliers and client teams deploy to one cloud platform. How do you manage secrets such as database passwords and API keys so nobody has to share them by chat and rotation is painless?
- Keep secrets in a managed vault, never in code or pipelines as plain text.
- Grant access per service and per team, by identity.
- Inject secrets at run time and rotate them automatically.
- Audit access and scan repositories for leaks.
“Secrets live in a managed vault, and nowhere else. No secret goes into a repository, a pipeline variable in plain text or a chat message. Each service gets an identity, and the vault grants it only the secrets it needs. At run time the platform injects the secret into the container, so engineers never see production values. Rotation is automated, with the database or provider and the vault updated together, and services reload without a restart where possible. Every read is logged. I would also add a scanner to every repository that blocks a commit containing something that looks like a key.”
Weak answers store secrets in environment files in the repository, or share one admin credential across teams.
7. An hour before a sale starts, the platform tries to scale up and hits a quota limit on the cloud account. New servers will not start. What do you do?
- Raise the quota request at once, through the fastest channel available.
- Free capacity: stop non-essential workloads and shift resources.
- Prepare to protect checkout with queues and feature switches.
- Tell the client early and add quota checks to future peak plans.
“I would raise the quota increase immediately through the provider's fastest support route, because that clock starts as soon as I ask. At the same time I would free capacity we already have: scale down test environments, batch jobs and internal tools running in the same account, and move that room to the store. Then I would prepare the fallbacks, such as the checkout queue and switches for non-essential features, in case the quota does not arrive in time. I would tell the client's team now, not after midnight. Afterwards, quota checks go into the checklist for every peak.”
Weak answers wait for the quota request and hope, or keep the client in the dark until something breaks.
8. Why do you want to run platforms for client companies at Infosys?
- Say what you enjoy in platform and operations work.
- Tie it to client platforms with daily releases and sale peaks.
- Link to your experience.
- Say what you want to learn.
“I like building platforms that other engineers can release to safely, many times a day, without asking me. At Infosys that platform belongs to a client, such as a retailer or a telecom operator, and it faces real customers and real peaks like sale days, which is where good preparation shows. I have run a cloud platform for a store through a peak season and enjoyed the planning, the rehearsals and the calm on the night. I want to learn how to do that across different clients and to work well with their own engineers and other suppliers.”
Weak answers list cloud services they know and say nothing about the teams and customers they serve.
No figures on this page: pay depends on the level, the city and the offer in front of you. When the offer comes, the free salary negotiation script helps with that part.
The questions above are the prep. On the real call, ClapAssist helps with the ones you did not practice.
ClapAssist is an AI interview assistant for Mac and Windows. It listens to the interview on your computer and shows you what to say, in short lines you can read while you talk. Your live interview audio and screen are never stored. Your resume and notes are saved to your account so the app fills them in on any computer. It is hidden from screen share on every plan, including Free; only you can see it.