TCS DevOps Engineer interview questions

The oldest question in systems interviewing and still the best, because it is unbounded: the interviewer stops you when you run out of depth, and where you stop is the score.

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

The scripting round in disguise. The constraint is the question: it exists to see whether you stream or whether you load, and everything else is about whether the script is safe to run twice.

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 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.

The answer that lands is about one epoll loop per core, not config snippets. Master versus worker duties, the arithmetic of worker_connections, and the limits people forget to raise.

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.

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.

Asked in almost every cloud screen, and most candidates recite the table without ever naming the failure it causes. The ephemeral port range is the whole answer.

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

The junior-filter question that still separates candidates who understand the model from those who memorised a definition. The answer is three mechanical differences and one economic one.

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

The cheapest storage class is rarely the cheapest answer. Retrieval pricing, minimum durations and per-transition fees decide whether a lifecycle rule saves money or manufactures waste.

Ask whether Multi-AZ means a DB instance or a DB cluster. One has a non-readable standby; the other has two readers. That distinction decides whether the proposal can relieve the primary.

Fleet-wide replacement is a traffic-shaping problem: bake once, wave through in controlled batches, watch the alarms, and keep the exit open. In-place patching is the alternative and usually the regret.

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.

Gateway endpoints avoid NAT processing for supported traffic. Interface endpoints have hourly and processing fees; cost savings depend on traffic, while access restrictions need explicit policies.

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.

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.

The private endpoint can be healthy while an office resolver still returns the public address. Trace the lookup from the failing client before changing access rules.

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.

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.

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.

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.

Promote the same code version, then generate and approve a separate saved plan against each environment's state and inputs. Pin, apply each reviewed artifact in sequence, and let the gates rise as you approach production. Environment branches quietly undo all of it.

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.

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.

Everyone can recite the three. The scoring answer is what each failure causes, and why a badly configured liveness probe is more dangerous than none at all.

PDB governs voluntary disruptions only and does not gate rolling updates at all. Candidates who say 'it keeps N pods alive' have just described the part it does not do.

Three propagation mechanisms live inside this one question and only one of them is automatic. Most candidates promise instant reloads; the kubelet has never promised that to anyone.

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. Candidates who can order the credential chain and read 401 versus 403 versus 429 in events diagnose this in minutes; the rest rotate secrets blind.

Tenancy is a dial from policy-based soft isolation to hard cluster boundaries with a virtual-control-plane middle ground. The scored answer picks by blast radius requirements and names what each model still leaves shared.

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.

Kind precedence orders manifests, hooks jump the queue with their own weights and delete policies, and --atomic plus --wait turn hope into rollback. Split charts along blast radius, not folder aesthetics.

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 fetch and pull half is a warm-up. The rebase half is where candidates either show they understand that rebasing rewrites commits or reveal that they have only ever followed instructions.

A question about developer experience as much as engineering. Measure before optimising, and notice that the trust problem and the duration problem may have different causes.

Most candidates narrate the YAML. The scoring starts underneath: who schedules what, where artifacts live between jobs, and why disposable runners rewrite how you think about caching and trust.

A vocabulary check with a trap inside it. Strict semantic versions bind libraries and SDKs; continuously deployed services play a different game, and pretending otherwise signals inexperience.

Long-lived branches pile up merge debt until integration becomes a gamble. There is a named technique that ships a three-month refactor in releasable increments, and its final step is deletion.

Queueing during release week is rarely bad luck. Diagnosis takes a minute once you know the three failure shapes, and the durable fix treats agents as cattle with labels and lifespans.

Cost per merge beats cost per minute. Attribute spend by pipeline, attack caches and matrix sprawl first, and know what self-hosted runners really cost.

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.

Day-one telemetry is cheap and retrofitting it costs an incident. The answer that scores names the linking layer (trace IDs in logs, exemplars on metrics) that turns three tools into one story.

Dashboard sprawl is an operating-model problem wearing a tooling costume. The scored answer moves definitions into git, attaches ownership metadata to every panel, and deletes without ceremony.

The roles question is really a delegation test: can you split commanding the incident from fixing it? Name the roles, the comms cadence, and the handoff discipline that keeps 3am coherent.

Usable runbooks live one click from the alert, front-load symptom-to-action pairs, and stay alive because CI and drills force the issue rather than anyone hoping.

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.

One surface cannot serve the responder and the review. Tier dashboards by the question each audience asks, and make every tile answer in five seconds or link one click deeper.

Severity inflation and silent underdeclaration are both incentive problems, not wording problems. Anchor levels to impact and obligations, pre-write example scenarios, and make declaring severe safe.

The most-asked scenario question in DevOps interviews, and the one where candidates most often list commands instead of reasoning. Empty logs is the clue, not the obstacle.

The gentlest scheduling question there is, and it still separates people who read the events from people who guess. Check whether the pod has a node before choosing between scheduling and startup diagnosis.

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.

An idle database with a starved application is the tell. The connections are held, not used. More database capacity does not release leaked connections.

Emergency mode after a storage change is usually one line in fstab. What interviewers score is your order of operations and whether your recovery preserves data-mount dependencies.

One saturated core on a proxy is rarely about raw traffic volume. It is a parallelism failure with three usual suspects, and the per-thread view names the culprit in minutes.

A hang suggests missing progress; a refusal suggests an explicit error. Packet evidence distinguishes firewall behavior from routing failures and closed listeners. Then rule counters, not eyeballs, finger the guilty line.

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.

The reflex is rollback and it is usually right. There is exactly one class of failure where undo makes things worse, and knowing it is the entire interview.

An unchanged pipeline failing in one environment means the environment moved, not the code. 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.

Duplicate-IP claims need evidence, and one command provides it. Then the real skill: telling a genuine two-owner clash apart from ARP flux, because the fixes could not be more different.

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.

Everyone endorses least privilege; few can describe how they would measure over-permission across a fleet. The scoring answer names the evidence source, the tiered remediation, and the break-glass hatch that makes it survivable.

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.

Experienced answers are ordered and verifiable: minimal base, benchmark applied as code, identity and exposure next, then continuous proof it stayed that way. Checklists recited out of order are the tell.

VPN grants a network, ZTNA brokers an application. The strong answer covers the engineer-specific protocols nobody mentions, device posture for contractors, and the break-glass path when the IdP is down.

Miners prove unauthorized workload execution, not a particular intrusion sequence. Parallel identity and network containment, backup control-plane protection, rebuild-don't-clean, and restore points older than patient zero.

Champions programmes die as mailing lists with a name. Survivors protect the time, pay in career currency, keep the job description tiny, and measure outcomes rather than attendance.

Discover, scan, deduplicate, prioritise with context, route with SLA clocks, verify, measure. Most programmes rot at dedup and ownership: five scanners produce five conflicting queues nobody trusts.

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.

Most tagging initiatives are spring cleans that rot within two quarters. The durable answer treats the schema like an API contract enforced where resources are born, and knows which lever actually wins.

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 incident answer needs your actual decisions, the evidence behind them and the effect on users. A wrong turn belongs in the story only if it happened.

A question that punishes both extremes. A trivial mistake reads as evasion, a catastrophic one told carelessly reads as reckless, and the interviewer is really asking what you do in the twenty minutes after you realise.

This question scores negotiation shape, not stubbornness. Interviewers want the candidate who re-scoped reality honestly, and they are screening out both the pushover and the person who just says no.

A services-industry staple that ends more managerial rounds than any technical question. The scored signal is whether you can say 'yes, with these guardrails' or 'no, and here is the Monday alternative' without either sounding like a refusal or a pushover.

The obvious failure is rescuing them before the deadline. This answer scores on diagnosis, direct-but-kind feedback, and letting the junior own a real slice end to end.

A slipped cutover, a security finding, a committed date dying. The scored skill is bad news delivered early by you, structured as facts, impact, options and one recommendation.

New leads fail by hoarding work or dumping it. Interviewers want your decision rules for handing things over, what you deliberately keep, and how you avoid becoming the bottleneck.

Urgency inflation is the default state of platform teams. Interviewers score whether you replace shouting with a shared queue, verified impact, and tradeoffs the requesters can see.

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.

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 question that reveals whether someone knows what load average actually counts on Linux. It is not a CPU metric, and that single fact resolves the whole thing.

The classic ephemeral port exhaustion question. Most candidates know the phrase TIME_WAIT; far fewer know which side accumulates it and why the popular fix is dangerous.

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.

The two-syscall duet behind every process on the box. The follow-ups live in what survives the transition, and candidates who skip that fail the next question.

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.

The answer is yes, and then the real question starts. Asymmetric routing and silent drops punish anyone who treats the routing tables as one flat list.