Walmart Global Tech DevOps Engineer interview questions

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.

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.

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.

Patching is easy; surviving the rollout is the interview. Staged rings with health gates, what livepatching can and cannot buy you, and the rollback plan you write before starting.

X-Forwarded-For, PROXY protocol v1 and v2, and the trust boundaries between them. Get the layer wrong and your rate limiting, geo rules and audit trails all key off the balancer's address.

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.

Turns the standard autoscaling definition into the problem it actually causes. Almost every candidate can define an HPA; far fewer can say why theirs did not save them.

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.

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.

Spreading instances across availability zones is not the same as surviving an AZ failure. What makes the difference is being able to name the four coupling points that quietly re-unify a blast radius you thought you had split.

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.

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.

A busy date key can throttle while table capacity remains available. Check the actual key distribution and throttling reason before adding capacity or shards.

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.

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.

Account-per-team is the right instinct, but hand-rolled account setup drifts within a month. Vending turns governance into a pipeline with an SLA instead of a ticket queue.

Guaranteed capacity and discounted capacity are different products. Peak season needs both, arranged in layers and verified with a game day before the traffic arrives.

Data transfer is charged in several unrelated ways and reported as one line, so the first job is decomposition. Most surprises are cross-zone chatter between services that never needed to be on different nodes.

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

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.

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.

Stack boundaries follow blast radius and change frequency, not the org chart. The monorepo only pays for itself while a machine can answer, from a commit, exactly which roots need planning.

Static INI files die somewhere near two hundred hosts. Point inventory plugins at the systems that already know the truth, derive groups from tags with constructed inventory, and plan for stale hosts before they page you.

Idempotence describes one run; convergence describes the fleet across time. Scheduled check-mode sweeps with diff reporting, alerts above a learned baseline, and a hard rule that incident hotfixes become pull requests the same day.

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.

Provider upgrades are a scheduled platform product: automatic version inventory, a canary stack inside days, automation that fans out pinned bumps with plan output attached. Estates without this routine get upgraded by deprecation deadlines.

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.

The scheduler is behaving correctly, which is the part that confuses people. It optimises placement at admission time and never revisits, so a cluster drifts out of balance by design.

A specific configuration trap with a clean explanation. Both controllers act on the same signal from opposite directions, which can produce unstable feedback depending on their policies and workload.

PDB governs voluntary disruptions only and does not gate rolling updates at all. Describing it as 'it keeps N pods alive' states the part it does not do, since it constrains voluntary eviction and not the machine that fails.

Three propagation mechanisms live inside this one question and only one of them is automatic. Instant reload is the common assumption and the kubelet has never offered it.

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.

Anti-affinity is binary and falls over at scale; topologySpreadConstraints give you numeric skew control across labeled domains. The subtle parts are eligibility filtering before the skew math, and the fact that Kubernetes never rebalances anything for you.

Upgrades look like rolling restarts right up to the morning the CNI stops talking to the new kubelet. The scored answer is ordering, skew policy, and addon sequencing, not courage under pressure.

The classic five-second stall is rarely CoreDNS being slow; it is UDP, conntrack races and ndots expansion. The diagnosis ladder and the NodeLocal DNSCache fix separate operators from readers of architecture blogs.

Three API servers behind one health-checked endpoint, etcd on its own quorum, leader election everywhere else. The scored part is naming what degrades quietly before anything alerts.

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.

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.

A registry grows because every commit mints digests nobody pulls again. Reference-aware retention keeps rollback targets and audit chains while expiring the debris.

A billion-row backfill is a deployable, throttled, resumable job with checkpoints and verification gates. Ad-hoc scripts against prod are how it becomes an incident.

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.

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.

Anyone can divide bad requests by total. This answer shows the aggregation mistakes that quietly corrupt SLO dashboards, the rate-versus-increase traps that make budgets lie, and when subqueries cost too much.

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

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.

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.

Comms is a role, not a chore bolted onto the incident commander. Audience-specific cadences, a committed next-update time in every message, and plain language that support can actually repeat.

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.

Intermittent DNS is the most-reported and least-understood Kubernetes failure. There are three well-known causes and each leaves a different fingerprint.

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.

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

One disk metric explaining a whole cluster's weirdness is the point of this question. Restarting etcd first turns a slow cluster into a down one, because a restarted member has to catch up before it can vote.

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.

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

The backup is doing its job and the database is paying for it. Attribution first, then enforcement that actually binds on modern kernels, because priority support depends on the active kernel and IO scheduler.

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.

Bandwidth graphs look healthy and the partner swears they are fine. The wall is ports, not bits: the available source-port budget depends on the gateway and its address allocation.

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.

Stateful firewalls keep established flows alive after their rule vanishes, so cleanup day passes every check and lag appears days later. Flow logs name the hour; inventories prevent the repeat.

A health endpoint that returns 200 because the process is running tells you the process is running. Interviewers want to hear where you draw the line between a check that pages and a check that removes traffic.

One partition has one consumer, by design. If the key distribution sends a third of the traffic to one partition, the parallelism you bought is unavailable to the work that needs it.

Naming the replacement is the floor of this question. What scores is the audit-then-warn-then-enforce sequence and an honest answer about the vendor chart you cannot fix.

Warn forever becomes wallpaper; block on day one gets the gate switched off. The durable answer is a severity-and-fixability matrix plus suppressions that expire.

A WAF matches patterns in HTTP and stops there. Know exactly which classes it catches, which it cannot see, and what closes the gap, because block-dashboard confidence is how breaches happen anyway.

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.

The dangerous question is not whether the vendor is secure but what the integration can touch once connected. Scope of granted access, data flow, offboarding, then tier the vendor and match effort to tier.

Adoption is a product problem: templates with tested safe defaults, guardrails that start in audit mode, and metrics on paved-road share. Remove reasons to leave the road rather than writing memos.

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 classic napkin-math question. The number in the prompt is the question. Drawing the architecture before doing the arithmetic produces a design the physics forbids, and the arithmetic takes a minute.

The catalog is the easy half. The scored half is stampede dynamics: one hot key expiring can multiply origin load by a thousand in a second, and there are three distinct fixes.

Cron is the most-deployed scheduler on earth and the worst-behaved at scale. The scored content is everything crontab cannot do: exactly-once firing, thundering herds, and what happens when the scheduler itself dies.

Flags sit on the request path of everything, so a slow flag service is a site-wide outage waiting to happen. Local snapshots, propagation numbers and audit trails are where this design is decided, because they determine what happens when the flag service itself is unavailable.

Dual-writing from application code is the answer that fails quietly six months in. Change data capture, per-entity ordering, and a reindex you could run on a Tuesday are what interviewers score.

This is a platform-organization question disguised as infrastructure. Score comes from separating enforcement from ownership and explaining what stops the gateway becoming a smart ESB.

Cron fires at wall-clock times; a scheduler reasons about data intervals and blocked frontiers. The scored details are per-partition idempotency and catch-up semantics.

Most migrations are safe and a handful can take the site down by holding a lock for eight seconds. Build the tooling to tell those apart automatically, because a review culture cannot do it two hundred times a month.

A question about method, not about tactics. Candidates who open with a list of levers lose to candidates who open with one question about the bill itself.

A shared cluster produces one bill and no answer. Attribution is a measurement problem first and a cultural one second, and the number that changes behaviour is not the one finance asked for.

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 discount is real and so is the option you are selling. The question is what your usage looks like in year three, and the honest answer for most teams is that they do not know.

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.

A budget miss can coexist with lower cost per request. Separate demand, usage intensity and price effects before assigning an efficiency target.

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

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

Each team is behaving rationally. The cost of migrating is theirs, immediate and certain; the benefit is later and uncertain. That asymmetry does not resolve by being explained again.

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

Before blaming the model, check whether it is being fed the same thing it was trained on. Most of the gap is a pipeline difference, and pipeline differences are a platform problem with a platform fix.

Nobody is waiting, which changes every constraint. Latency stops mattering, throughput per dollar becomes the only metric, and the design converges on something that looks like a data pipeline rather than a service.

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.

Use shared evidence and an agreed experiment to resolve a cross-team production problem, while containing impact and escalating time-sensitive risk.

Delegate a technical outcome with authority, capacity and acceptance criteria, while preserving the decisions and commitments assigned to the lead.

Explain a reliability objection through the failing mechanism, a feasible alternative and an explicit decision about the remaining service risk.

Build a first-ninety-day plan from service risk and observed work, with safe shadowing, tested runbooks and one measurable operating improvement.

Decide whether to continue a migration using remaining costs and current benefits, then deliberately operate or unwind the partial state.

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

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.

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

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.

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.

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.

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.

The Indian e-commerce interview question, and autoscaling is the wrong first answer. A 10x spike arriving in seconds outruns any scaling loop, so the design has to absorb rather than scale.