Infosys DevOps Engineer interview questions

Ordering and retransmission are what TCP adds, and both of them cost time. Naming something that deliberately gives them up, and saying why, is what turns a textbook answer into a real one.

The arithmetic takes thirty seconds to learn and gets asked constantly. What it is really testing is whether you have ever had to size a VPC that could not be resized later.

Five stages, and which one you are stuck in tells you what to fix. A machine that reaches a GRUB prompt has a different problem from one that hangs waiting on a filesystem that no longer exists.

Two different resources produce the same errno, and the second one is invisible unless you know to look. One command distinguishes them.

A beginner question with a senior follow-up hiding in it. Once you know a hard link is a second name for an inode, log rotation and backup behaviour both stop being mysterious.

Everyone recites the four letters. The scoring answer walks each packet across the wire and knows the places the exchange silently dies.

A routine cloud operation with three layers that can quietly disagree. The strong answer is an ordered procedure you could run during business hours, without a reboot.

A one-line mistake that locks you out of the obvious fix. The fast recovery teaches more about the permission model than any man page will.

Every ops engineer schedules jobs; few can say which shell cron uses, where stdout lands, or why percent signs delete half a command. Those gaps are exactly what interviews test.

Everyone knows ulimit -n. The interview question is which process inherits which value, why limits.conf did nothing for your service, and how you size the ceiling honestly.

A reset at a suspiciously round number is a fingerprint, not a bug. Matching client keepalives to the lowest timer in the path is the fix; here is the full ladder of knobs.

Volatile by default on many distros, size-capped by silent policy, binary on disk. Know the storage modes, the vacuum knobs, and how journald feeds central logging.

Copy-on-write freezes a point-in-time view while the database keeps writing. Fat snapshots overflow into invalid backups and thin pools exhaust into frozen volumes: size both deliberately.

VRRP heartbeats, market data feeds, mDNS noise and cluster chatter all ride multicast, and all of it assumes a switched LAN. Why clouds drop it and what replaces it.

Multi-AZ is the answer and the reason matters more than the acronym. Each tier fails differently, and the database is the one where high availability means a failover with a real gap, not zero interruption.

Four levels, and the two that matter operationally are the subscription, where quotas and billing live, and the resource group, which is the unit you delete. Getting the boundaries wrong is expensive to unpick later.

Service principal with a client secret is the answer people give and the one that leaves a credential in a config file. Managed identity is the same object with the secret handled by the platform.

One is layer 4 and regional, one is layer 7 and regional, one is layer 7 and global. Answer on those two axes and the choice makes itself, including when you need two of them together.

Two questions settle most of it: how much of the machine do you want to own, and is the workload request-shaped or long-running. Fargate is a way of running containers rather than a competitor to ECS and EKS, which is the distinction people get wrong.

Two structural differences matter more than any service mapping: the VPC is global rather than regional, and permissions are granted to members on resources through a hierarchy rather than attached to identities.

The comparison table is easy to recite and explains nothing about the failure the difference actually causes. The ephemeral port range is the whole answer.

A design question with a clear answer at this scale, and the reasoning is what scores. The three options solve different problems and peering and Transit Gateway connect networks while PrivateLink exposes services.

Trace the route and return path before changing rules. First establish whether the failing connection uses IPv4, IPv6 or a private service endpoint.

A question that sounds introductory and turns on one distinction: what you stop operating, and what you start paying for instead. The answer is three mechanical differences and one economic one.

S3 access failures are rarely about the bucket policy alone. The caller, object ownership and network path determine which authorization checks apply. Start with the failed request and trace changes across those boundaries.

Database redundancy still needs reconnecting clients. Distinguish the deployment type, then measure how promotion and DNS changes affect application requests.

The services-and-enterprise interview staple. There is a defensible answer and it is not 'always re-platform': the decision is a function of change tolerance, deadline reality and what the workload is worth.

DNS failover is a blunt instrument with three delays stacked on top of each other: detection, propagation and client caching. Knowing their sizes tells you when DNS is the right layer at all.

Volume choice is IO-shape matching: burst buckets, provisioned IOPS and throughput designs behave very differently under mixed OLTP-plus-batch load. Average latency graphs hide the failure entirely.

Roles versus users looks like syntax trivia and is actually a secrets-management position. The follow-ups about instance profiles and IRSA separate practitioners from tutorial graduates.

Direct encryption hits a 4 KB wall and a shared throughput quota. Envelope encryption routes around both, and the key policy underneath is central to authorizing key use.

Cross-account access is easy to grant and easy to get wrong. External IDs, scoped roles and audit trails separate a controlled bridge from an open door any tenant can walk through.

Service control policies cap what anyone in a member account can do, no matter what their IAM admins wrote. The craft is choosing a handful of denials that age well.

Hybrid DNS fails in both directions independently. Outbound rules carry VPC queries to your data centre, inbound endpoints bring on-prem queries back here, and both halves need wiring.

Orchestration buys a visible state machine with declared retries; choreography buys independence and coupling debt. Money paths usually deserve the state machine.

Residency is not a checkbox on the primary datastore. Where bytes sit, who holds keys, and where logs, backups and analytics quietly replicate decide whether the deal signs.

Managed Kubernetes offers several responsibility models. Application availability remains yours even when the provider also manages nodes and networking, and the interview tests whether you know where that line sits.

Moving a Kubernetes service account changes its token subject. Separate pod mutation, federation trust and Key Vault authorization before adding permissions.

Four commands, and the interesting one is plan, because it is the only point where you see the three-way comparison Terraform is actually making before anything changes.

Everyone can say state maps config to reality. The follow-up that separates candidates is what else is in the file, and what that means for who may read it.

Everyone answers state locking. The follow-up is what happens when locking is not configured, and what you do with a stale lock at 2am, which is where the answer gets real.

A staple of services-company interviews, and the boring answer (provisioning versus configuration) is only half of it. The useful half is what happens when you push either tool past its model.

The question that finds out whether someone writes playbooks or writes shell scripts wrapped in YAML. Idempotence is a property of the module you chose, not of Ansible.

State layout needs an access boundary. Separate environment credentials and restrict who can assume them; a directory name cannot contain a mistaken apply.

The services-market question that decides who can actually run a migration. Import is the easy part; the hard parts are resource-for-resource fidelity and proving the first plan is empty.

Drift is a governance problem wearing a tooling costume. Detection is easy; the scored content is attribution (who changed it and why) and the policy decision that most teams avoid making.

Extract too early and you maintain a wrapper nobody thanks you for. Here is the extraction trigger, the semver contract that maps onto Terraform surfaces, and the parallel-release path for breaking changes.

Reading a plan is a skill separate from writing HCL. People trusted with production approves read the diff in a fixed order, and one of the checks is what the plan does not contain.

Everyone recites that depends_on forces ordering. The stronger half of the answer is the graph you never see: implicit edges from references, why file layout orders nothing, and what explicit edges cost.

HashiCorp calls provisioners a last resort and expects you to say why in concrete terms: tainted resources, invisible drift, SSH reachability. Then name what replaces each legitimate use.

sensitive = true stops the echo, not the storage. The complete answer walks the value through git, plan artifacts, state, and provider side effects, naming which mitigation closes which leak.

Three lifecycle arguments influence replacement and drift handling: create_before_destroy, prevent_destroy, and ignore_changes. Each earns its place through an incident story, and each has a failure mode that is worth naming before you reach for it.

The right answer depends on who owns the truth: the platform, the caller, or nobody. At scale there is a fourth option most candidates miss, where your image pipeline publishes values instead of Terraform hunting for them.

Vault's weakness is the single shared password, not the AES256 underneath. The senior answer covers rekey ceremonies on offboarding, encrypt_string for readable diffs, labelled vault-ids per environment, and shrinking what needs encrypting at all.

state rm, import, moved and removed blocks each treat a different wound. The commands are the easy part. What makes the operation safe is the backup, lock and plan ritual wrapped around touching production state.

Registries live or die on upgrade ergonomics, not on publishing features. Green example plans gate every tag, automation delivers upgrade PRs with plan output to consumers, and retirement is a census plus a date.

Follow a Deployment change through the API server, controllers, scheduler and kubelet. Each handoff gives you a different place to investigate when a pod never starts.

A pod is a shared network and storage boundary that happens to contain containers. Once you can say what the containers inside one share, sidecars and init containers stop needing separate explanations.

A Service moves connections and an Ingress reads requests. The gap between those two sentences is hostname routing, path routing and TLS, and it is also why an Ingress object alone does nothing.

A namespace scopes names, permissions and quotas. It does not scope the kernel or the network by default, and the gap between what people assume it isolates and what it does is where the trouble starts.

A ReplicaSet keeps a count. A Deployment manages a sequence of ReplicaSets, and that is the entire difference: it is what turns a change into a rollout you can pause and undo.

Build instructions depend on earlier inputs, so changing source can invalidate a dependency installation placed after it. Ordering the Dockerfile by how often things change is the whole optimisation, and multi-stage is how the compiler stops shipping to production.

It is Kubernetes with an opinion, and the opinion that catches everyone is that containers do not run as root. A manifest that works on vanilla Kubernetes and fails here usually fails for exactly that reason.

The pair everyone configures and few can explain. QoS hints at eviction risk, but usage versus requests and Pod priority determine node-pressure ranking, and CPU and memory behave completely differently when you exceed them.

A practical question with a precise answer, and the size is not the real cost. Pull time on every node, registry storage, and attack surface all scale with it.

Default-deny egress breaks name resolution before it breaks anything else, and every connection times out confusingly. The practitioners are the ones who test with positive AND negative probes and know their CNI's fine print.

Explain per-node eligibility and update behaviour, then verify that a Ready collector is actually delivering logs.

Quotas are admission-time contracts counted in requests, not measured usage. That single sentence explains most quota outages, most quota confusion, and the reason LimitRange must sit beside every quota.

Pull auth resolves on the node before any container exists. Ordering the credential chain and reading 401 against 403 against 429 in the events turns this into a minutes-long diagnosis; without it the only move left is rotating secrets blind.

Exec into a distroless image and you get nothing, because there is nothing to exec into. Ephemeral containers inject tooling into a running pod without restarting it, and the security caveats are what interviewers really listen for.

Two artifacts hide under 'Kubernetes backup' and they recover different things. The misses are what decides whether a restore works: volume bytes, encryption keys, and everything that never lived in etcd at all.

Best-effort objects, one-hour TTL, deduplicated by count, invisible unless shipped out. Events narrate scheduling and lifecycle decisions; treating them as durable records is the expensive mistake.

Two-phase deletion, a controller that purges content, finalizers holding the door. Stuck CRD instances, dead webhooks and GitOps recreates are the real story; standards prevent the ticket.

The opener in most DevOps interviews, and the one most people answer as a list of nouns. What earns the follow-up is saying what each stage is allowed to fail for and how long it takes.

Pipeline as code moved the build definition into the repository, where it is reviewed and versioned with the thing it builds. Declarative is the default answer, and knowing when scripted still earns its place is the follow-up.

Jenkins is mostly plugins, they have a dependency graph nobody drew, and the controller is a single point of failure for every team. The answer is a rehearsal against a copy of production, not a maintenance window and hope.

Stages, jobs, steps, and a pool that supplies the machine. The piece that decides most real designs is the agent pool, because Microsoft-hosted agents cannot reach a private network and most enterprise deployments need to.

Compare proxy, hosted and group repositories. Trace a tested artifact into production, and understand when a cache can keep builds running during an upstream outage.

Git merges by comparing both branches against their common ancestor. A conflict means both sides changed the same region, and the resolution nobody checks is the one that compiles and is semantically wrong.

Follow commit identities through a rebase, recover a collaborator’s work with an explicit boundary, and explain the limits of force-with-lease and revert.

Calculate the pipeline critical path, separate runner queues from execution, and improve feedback time without hiding flaky or skipped checks.

Testing is a pipeline design problem in this role, not a QA one. The constraint is the question: you cannot run everything on every commit, so what you choose to defer is the answer.

Follow scheduling eligibility, job isolation and artifact transfer, then diagnose a queued job whose available runners cannot satisfy its requirements.

One Application declaring others sounds like trivia until you need to rebuild a cluster in an afternoon or hand a team a bounded slice of the platform. Here is when the pattern earns its keep, and when ApplicationSet should replace it.

Distinguish executor capacity, placement and provisioning failures, then size an agent pool from measured resource use and cleanup behaviour.

Same commit, different dependency trees: the vocabulary answer is lockfiles, the practitioner answer includes frozen installs, integrity hashes and pinned toolchains.

Staging is a snowflake maintained by accretion. Rank drift sources by risk, shrink them mechanically with parity by construction, and stop calling staging the last line of defence.

Hooks must finish in seconds or developers bypass them, and a bypassed hook protects nothing. Budget feedback latency numerically and split checks by authority and hermeticity.

Central pipeline logic fails two ways: forked copies that drift, or a platform team queue every change must wait behind. Versioned templates with pinned consumers and declared hooks avoid both.

Prometheus asks your service for numbers on a schedule rather than waiting to be told. That one design choice explains service discovery, exporters, staleness and why short-lived jobs are the awkward case.

All three can search logs. What differs is who operates the cluster and how the bill is shaped, and the bill is what kills these projects, not the querying.

The instinct is to delete old logs. That is backwards: the waste lives in what you ingest, not how long you keep it. This answer walks the levers in the order that actually pays.

OpenTelemetry is an API and a wire protocol, not a product. Candidates who promise instant multi-vendor bliss have never run the collector in production or negotiated with a vendor who knows it.

The pull model is the famous part and explains none of the operational pain. The storage engine is where Prometheus hurts in production: crash recovery, cold queries, disk death.

The data-path question separates people who have sized a cluster from people who installed one. Shard sizing, refresh versus flush, and each ILM phase carry one specific failure mode apiece.

Metrics describe the server's experience; synthetics describe the user's. The strong answer designs a few money-path journeys from real geographies, pages only on persistent failure, and budgets for script rot.

Forty healthy islands equal one blind estate. Compare the consolidation patterns honestly, keep alerting local, curate what crosses the WAN, and make the global view read-only and cheap.

Routing rots because orgs change faster than configs. The senior answer treats ownership as data resolved from a catalog at fire time, with drift detection on the routing itself.

Rotation length decides focus versus fatigue, handoff quality decides whether Tuesday inherits Monday's mess, and follow-the-sun only works when every region holds real authority.

Attribution is an incentive-design problem: own-team labels at ingest, unit pricing per signal, monthly showback before any chargeback, sanctioned levers so teams can actually respond.

Monitoring dies silently: stuck alert queues, full TSDBs, collectors killed inside the same blast radius. Layer independent checks and a heartbeat so absence of signal pages louder than any red dashboard.

Status codes describe an HTTP failure category. Locate the component that emitted the response, then use its logs to distinguish connection, capacity and application failures.

A common scenario question, and the one where a list of commands most often stands in for an argument about what each one eliminates. Empty logs is the clue, not the obstacle.

The pods are Running, the dashboard is green, and users get errors. The gap between Running and receiving traffic is where this question lives, and it has a precise answer.

A deceptively deep question, because there are at least six places a version can get stuck and they span the pipeline, the cluster and the edge. Work the path in order.

Tests the mitigate-before-diagnose reflex under time pressure, plus whether you know the two ways a disk can be full and the trap that makes freed space not come back.

Automation can renew a certificate without deploying it correctly. Check the served leaf and chain, the client trust store and the exact verification failure.

Low utilisation with terrible tail latency is not a contradiction. It is the CFS quota doing exactly what it was configured to do. Most candidates have never read nr_throttled.

Established traffic keeps working while new connections die at random, which is exactly why this one confuses people. The table is full of flows that will not be needed again for days.

Repeated action items are a measurable defect with a mechanical cause. Answering 'culture' without a mechanism describes the symptom back rather than fixing it.

Emergency mode after a storage change is usually one line in fstab. The order of operations is what decides the outcome here, along with whether the recovery preserves data-mount dependencies rather than booting past them.

Everyone reaches for reinstall. The disciplined path is one journal file, four failure signatures, and an explicit decision about whether this host deserves surgery at all.

Same-node good, cross-node bad is not a random clue, it is nearly a diagnosis. One short decision tree separates overlay reachability, encapsulation blocks, MTU and policy.

The reflex is rollback and it is usually right. Shared state, changed credentials and unavailable old artifacts can make an undo incomplete or unsafe. Verify those dependencies before choosing the recovery.

An unchanged pipeline can fail because of environment state, external inputs or a latent artifact defect. Failures that start on an expiry boundary narrow the field to two suspects fast.

This one separates people who read journals from people who restart harder. The exit code and signal systemd already recorded usually name the disease.

Nothing errors because dropping unmatched lines is documented behaviour. Counting the tagged failures converts an invisible leak into a number, and numbers have owners.

Load balancing makes a per-host fault look like a flaky library. The exact rejection string tells you which way the offending clock leans before you log into anything.

The box looks CPU-starved but the CPUs are starving themselves. Reading the reclaim loop correctly separates people who have sat on the console from people who have read about it.

A public registry throttles by source IP and your whole fleet shares one. Why fifty nodes count as a single anonymous user, and authentication and caching changes that reduce upstream demand.

Gradual drift produces no errors on the host that has it, only weirdness everywhere else. Sweep first, histogram second, repair third: the distribution shape names the culprit before you log into anything.

Every client fails at once, which rules out pods and points at shared PKI. Know which certificates share one expiry clock, and a controlled recovery that preserves cluster state.

Exit codes said green while the warehouse went hollow. Where detection should have sat, why retries could not help, and the backfill discipline finance will actually accept.

Every SDK fetches its credentials from a link-local metadata endpoint with a modest request budget. Enough containers refreshing at once and the endpoint starts refusing, which the SDK reports as an auth problem.

Measuring the whole codebase gives a team an unpayable debt and a gate they turn off. Measuring only the lines changed in this pull request gives them a gate they can pass today.

The honest answer splits traffic containment from access control. Flat yes or no loses points here; the condition under which segmentation stops being theatre is what the interviewer wants.

Threat modelling dies as a document ritual and lives as a design-stage habit. The answer that scores: tier reviews by blast radius, short sessions on RFCs, findings filed where engineers already work.

Push approval is a weak factor and fatigue is its predictable failure mode. Stop the campaign with number matching and rate limits; end the attack class with passkeys, device gating and a hardened helpdesk.

One directory as source of truth, conventionally named groups, apps mapping groups to roles in code. Protocol choice matters less than mapping discipline and a joiner-mover-leaver wire that actually removes access.

A pentest report is evidence, not a backlog. Triage by exploitability and blast radius, reproduce before you believe, commit to deadlines you can defend, and publish the burn-down so the dates are yours.

Labels without consequences die quietly. Attach classification to enforced defaults in Terraform modules, propagate tags to every copy of the data, and give engineers twenty worked examples instead of a taxonomy lecture.

Stateless does not mean there is no state. It means the state is not in the instance, which is what lets you kill any instance at any time. Every scaling and deployment property people want depends on that one thing.

The default answer is 'horizontal' because interviews reward it. The correct answer names the constraint that makes distribution expensive and knows when one big machine is the engineering choice.

CAP is not a menu of two letters per system. The scored answer knows what the theorem claims (narrowly), what most engineers misquote, and what a split-brain costs when both halves accept writes.

This is a machine identity problem wearing a secrets costume. Candidates who start at encryption miss that authentication of the caller and delivery mechanics are the real design space.

Vendor limits are a shared budget your own teams will fight over. Broker the capacity, degrade by priority lane, and never let feature code see vendor HTTP semantics.

A catalogue nobody updates is worse than no catalogue, because people trust it once and get burned. Derive everything you can from systems that are already true, and make the rest a gate rather than a request.

The tool emits recommendations; the programme is everything around it. Interviewers use this question to see whether you can turn a dashboard into landed changes without breaking production or trust.

Over-requested CPU and memory can prevent efficient node packing. Cutting them safely is a measurement problem with a reliability trap sitting in the middle of it.

Most of your rows are read rarely and cost the same as the ones read constantly. Tiering pays for itself only when access patterns are honest, which is why the audit comes before the architecture.

The licence fee is visible and the engineering time is not, so omitting internal effort can make building look artificially cheap. The fix is pricing internal effort honestly, including its maintenance tail.

An upfront purchase, a refund and two currencies can produce several valid totals. Work out which total finance needs, then prove every adjustment from the source rows.

The instinct is to build a portal. The ticket mix decides whether a portal helps at all, and most teams never count it.

Refuse every exception and teams leave the platform without telling you. Grant them freely and you are patching nine stacks. The detail that decides it is whether the exception has an expiry date.

The expensive part of these incidents is almost never the fix. It is the twenty minutes spent deciding whose incident it is.

Complaints measure volume and confidence, not cost. The loudest team is usually the one most comfortable complaining, which is not the same as the one losing the most time.

Support demand grows with teams multiplied by surface area, and headcount does not. The only durable lever is removing the reason people ask.

Operational load is not a discipline problem. It is the interest payment on everything the team shipped without an owner, and it compounds.

Code is one of three inputs now. Data and the trained model are the other two, and they version differently, break differently and cannot be tested the way code is.

A training job is an hours-long computation with no user watching. Whether an interruption costs four minutes or four days is decided entirely by checkpoint cadence and restart semantics designed before the run.

The first question, the one people prepare least, and the only one where you choose what the rest of the interview is about. Two minutes, ending on something you want to be asked about.

A screening question that filters out people who have read about the field rather than looked at it. The answer that fails is a list of tools; the one that works describes who you serve and what you are on the hook for.

The question is really whether you learn deliberately or absorb whatever passes by. One specific thing learned recently, with why you picked it and what you did with it, beats any list of newsletters.

Explain a technical disagreement you lost, how you supported the chosen implementation and which evidence would justify reopening the decision.

Turn a deadline dispute into a reviewable plan with capacity arithmetic, dependencies, scope choices and a clear acceptance boundary.

Assess a late deployment through change scope, recovery evidence and support coverage, then make a concrete release or deferral recommendation.

Investigate on-call workload with responder feedback and paging evidence, then verify that relief and alert changes preserve service coverage.

Explain mentoring through an observed blocker, a bounded owned task, useful feedback and evidence that the engineer can apply the learning independently.

Correct mistaken incident attribution with evidence, protect the response from a false diagnosis and follow through on the shared record.

Communicate a threatened delivery or recovery commitment with known facts, uncertainty, a recommendation and the decision needed before options expire.

Resolve competing urgent requests using consequences, deadlines, uncertainty and real capacity, with explicit decisions about deferred work.

Retire an internal tool through verified user needs, compatibility evidence and an owned cutover, while treating its maintainer as a source of context rather than a barrier.

Handle a slipping dependency through a tested interface, honest integration status and an early decision about scope, resources or the external commitment.

Define the shared operating requirements before standardizing delivery, then test representative migrations and keep supported exceptions explicit.

The question that separates people who have debugged a hung rollout from people who have read about one. The interesting half is not the signal, it is PID 1.

Both run pods, so the answer sounds obvious until an interviewer asks what happens when you delete one. The guarantees are narrower and more specific than most candidates think.

A staple of every networking round, and the follow-up is always about TLS termination. Knowing which layer sees what decides most of the answer.

The oldest question in systems interviewing and still the best, because it is unbounded: every layer you can describe is another layer you could debug.

The classic ephemeral port exhaustion question. TIME_WAIT is a familiar phrase and the useful facts are narrower: which side accumulates it, and why the popular fix is dangerous.

Service types choose how an application is exposed. Follow the actual traffic path: cloud controllers can target nodes or pods, and internal exposure differs from public exposure.

Most of what looks like used memory on a healthy Linux box is page cache doing its job. Knowing which column to read, and why df and du disagree, is half of Linux triage.

Interviewers use this to sort memorised trivia from people who have chased a slow lookup. Three roles, one bit, and the caching rules most candidates repeat incorrectly.