Accenture DevOps Engineer interview questions

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.

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.

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.

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

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.

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.

Two authentications happen in every SSH session, and the one usually left out is the server proving itself to you. Knowing who proves what, and where your agent socket ends up, is the scored material.

Enterprise loops pair these topics because they test L2 literacy plus vendor coordination together. The scored insight is that LACP spreads flows, not packets, and needs the switch to agree.

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.

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.

The question that separates console users from people who have debugged a permissions failure across accounts. Evaluation order is deterministic and knowing it makes AccessDenied readable.

Most candidates can sell serverless. The question asks you to argue against it, which needs a real understanding of the execution model rather than the marketing.

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.

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.

Large object uploads are a reliability design problem, not a bandwidth one. Parts, retries and the completion call decide whether a flaky link costs one chunk or the whole night.

Sessions, locks and pub/sub are three very different contracts with the same server. Knowing which guarantees each one lacks is the difference between a cache and an outage.

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.

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.

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.

Allow-listing egress starts free with security groups and ends with TLS-breaking appliances. Each rung costs latency, money and political capital, and knowing where to stop is the actual test.

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.

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.

It copies a small Python program to the target over SSH, runs it, and deletes it. Once that is clear, the agentless claim, the performance characteristics and the idempotency requirement all stop being separate topics.

The Terraform question that actually filters. Everyone knows both meta-arguments exist; the answer is about how state addresses resources, and why an index is a fragile key.

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.

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 table is half the answer. The other half is who holds credentials, who repairs a stuck lock at night, and why the boring option usually wins until RBAC demands grow teeth.

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.

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.

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.

A VM virtualises hardware and boots its own kernel. A container is a process on the host kernel with its view of the world restricted. Everything else, including the security answer, follows from that one difference.

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.

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.

Three states, three completely different causes, and one command that tells you which you are looking at. The state name says whether the problem is the scheduler, the registry or your own process.

Selectors match object labels; owner references record controller relationships. Keeping those mechanisms separate explains how a Service can select the wrong pods without owning them.

Both solve the same surface problem and they disagree about how. Compare what each mechanism makes hard, and notices that the GitOps tool you use changes the calculus.

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.

Pod-level SIGTERM handling and node-level shutdown coordination are different mechanisms, and conflating them is the trap. The kubelet can only drain pods on power-off if it participates in systemd's shutdown sequence.

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.

Exit codes, the previous-container log, and a little-known file at /dev/termination-log that carries a container's last words into kubectl output. Scale triage starts with classification, not with opening pods.

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.

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.

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.

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

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

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

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.

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.

Application redeployment and module downgrades both require current-state checks. The asymmetry that forces expand-contract discipline and plan-reviewed upgrades instead of promote-and-rollback pipelines.

Metrics quantify impact, traces expose instrumented request paths, and logs describe individual events. Follow a slow checkout across all three while accounting for missing evidence.

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.

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.

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.

Spending the budget is arithmetic; enforcing consequences is politics plus automation. The answer that lands names trigger thresholds, the deploy gate that blocks releases, and the dated escape valve.

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.

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.

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.

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.

Three places, and which one depends on how the thing was started. Knowing which logs the runtime collects and which the application writes itself, and that journald may not persist across reboots, saves the first twenty minutes.

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.

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.

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

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

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.

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.

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.

Stop the source before tuning anything: kill the runner, revoke its credentials, shed test-shaped traffic at the edge, protect checkout. Forensics and guardrails only after customers stop feeling it.

Running pods already have their images, so a credential expiry is invisible until something needs to start. That gap is why this always surfaces during an unrelated incident, at the worst moment.

Four scanners, four different things they see, and one rule that decides whether any of them help: a finding that arrives at the release gate is an argument, and the same finding on a pull request is a ten-minute fix.

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.

Easy to define and easy to fail. The scoring half is where each gate sits, what it does to build time, and the honest admission of what the whole set misses.

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.

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.

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 migration question, and the trap is answering with a target architecture. What is being scored is sequencing: how you get there without a rewrite and without a release freeze.

Size stored sessions from expiry and creation rates, then decide how quickly logout must take effect and what failover may forget.

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.

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.

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.

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.

Central teams optimise well and get ignored; federated teams own outcomes and drown in tooling. The mature answer is a hub-and-spoke split by decision type, and the interview tests whether you can say exactly who decides what.

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.

Registration coverage tells you a script ran. It says nothing about whether an engineer has ever found the portal worth opening.

A generated template is a copy, not a link. Drift is not a discipline failure, it is the predictable result of the mechanism you chose.

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.

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

Every capability a platform accepts is a permanent operational commitment. Teams that cannot say no end up operating six things badly instead of two things well.

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.

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.

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.

Facilitate a disputed design by stopping personal attacks, separating testable assumptions from priorities and assigning a decision owner.

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.

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

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

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

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

Assess a signed vendor choice against the actual requirements and contract, then support a bounded implementation or raise material new evidence through its owners.

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.

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 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 green plan is evidence, not proof. Build the pyramid: lint in seconds, policy on every PR, real-cloud verification only where shared modules and money justify the burn.

The single most common Kubernetes interview question, and the one where a vague answer is most obvious. Every stage you name is a place the interviewer can ask you to debug.

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

Almost always a finalizer, and the fast fix is the one that loses data. The safe answer explains what the finalizer is protecting against before removing it.