The interview. What they ask, what you answer, and what you do when you freeze.

“It's the way of working where the people who write the application and the people who keep it running work toward the same goal, instead of handing off responsibility. In practice it means delivery, infrastructure and monitoring are automated and versioned, so anyone on the team can deliver safely, and when something breaks you know right away what changed.”

What you don't say: “it's a culture.” It's true and it says nothing. Give an operational definition.

“In the morning I check what happened overnight — alerts, deployments, failed jobs. During the day there are three kinds of work: building automation, helping developers when something gets stuck in the pipeline, and dealing with what's broken. On top of that comes planned work — version upgrades, cleanup, cost reduction. When there's an incident, everything else stops.”

“It means the checks move as early as possible in the process. Tests, security analysis, configuration checks happen on every change, not in an audit at the end. The reason is simple: a problem caught in the editor costs minutes, the same problem caught in production costs days and, sometimes, customers.”

“Through four numbers you can measure: how often we deploy, how long it takes from commit to production, how often a deployment causes a problem, and how long it takes us to recover. Automation improves all four at once, and the last one is the one that matters to the customer. Counterintuitively, teams that deploy often are also the most stable ones — because they deploy small changes that are easy to understand and easy to revert.”

“DevOps is the way of working. SRE is a concrete implementation of it, focused on measured reliability: you define targets, you measure, and you have an error budget that decides whether the team ships more aggressively or stops to fix things. In practice, at most companies in Romania, the title is DevOps and the job covers both.”

“Not assuming. Most long incidents drag on not because the problem was hard, but because someone started from an assumption they never checked. The discipline of verifying before acting is what separates a ten-minute incident from a three-hour one.”

“With continuous delivery, any change that passed the tests is ready to ship, but someone presses the button. With continuous deployment there's no button — if everything passed, it reaches production on its own. The difference is one person, and the choice depends on how well you've covered the risk with automated tests and the ability to roll back quickly.”

“I pull the code, install the dependencies, check style and run static analysis, run the unit tests, build the artifact exactly once, scan it for vulnerabilities, push it to a registry, deploy it to the test environment, run the integration tests, wait for approval if needed, deploy to production and verify the deployment's status. The rule I stick to is that the artifact is built once and the same one goes through every environment — the only thing that differs is the configuration.”

“Because if you rebuild for every environment, what you test isn't what you ship. A dependency can resolve differently, a cache can be different, and you end up in the classic situation where it works in test and doesn't work in production. I build once, push to the registry, and deploy from there everywhere.”

“A workflow is a YAML file in .github/workflows, triggered by an event. It contains jobs; each job runs on a runner, on its own clean machine, and has steps. A step is either a command or a reusable action. Jobs run in parallel unless you say otherwise; with needs you put them in order.”

“Through artifacts — upload-artifact in one job, download-artifact in the other. It's a common trap for people coming from Jenkins, where stages share the same workspace. In Actions, each job starts on a fresh machine, so nothing is passed implicitly. Small values are passed through outputs.”

“On three levels: organization-level for what's shared, repository-level for what's specific, and environment-level for production — there I can also require human approval before the job starts. But if I'm going toward a cloud provider, I'd rather not have secrets at all and use OIDC.”

“Instead of keeping a permanent key in the repository's secrets, the workflow receives an identity token signed by GitHub, and the cloud provider accepts it based on a trust relationship configured once. The token lives for a few minutes and is tied to the repository and branch that requested it. There's nothing left to leak, nothing left to rotate. The detail that matters: the trust condition is written against identifiers that can't change, not against the repository name — the name can be renamed and taken over by someone else.”

“I pin them to the full commit hash, not to a tag, because a tag can be moved. Then I let Dependabot propose the updates, so I don't stay on an old version. And I give the workflow minimal permissions — read-only by default, and I add write access only where it's actually needed.”

“Because it runs with the repository's secrets, but in the context of a pull request that can come from anyone. If you check out the PR's code inside it and execute it, you've just given a stranger access to your secrets. It's only used for things that don't touch the PR's code — for example, adding labels or comments.”

“I built my pipelines in Azure DevOps and in Jenkins, including a blue-green deployment. The model is the same — trigger, stages, artifact, approval, deploy — and it translates directly: what's agent in Jenkins is runs-on in Actions; what's stages become jobs, with the important difference that in Actions each job starts clean, so artifacts have to be passed explicitly. I've worked with Actions at the level of being able to read and modify a workflow; what I haven't done is roll them out across a whole organization, and that's something I'd learn along the way.”

Honest phrasing. Doesn't claim more than you can back up on the follow-up question, but doesn't throw away real experience either.

“First I check whether the failure is in the test or in the infrastructure — a network call with no timeout and no retry is the most common cause. If it's a flaky test, I isolate it and flag it, because a test nobody trusts anymore is worse than no test at all. I never let the intermittent failure just “pass,” because that trains the team to ignore red.”

“It's a system that keeps containers running across a group of machines. You describe the desired state — I want three instances of this application, with this configuration — and it constantly compares reality to what you asked for and corrects the difference. If a container dies, it restarts it. If a node dies, it moves the workload to another one. That's the whole thing; everything else is detail on top of that idea.”

“It's the smallest unit that Kubernetes schedules. Usually one container, but it can have several that share the same network address and the same volumes. Important: a pod is disposable. It doesn't get repaired, it gets replaced. It has an IP address that disappears with it, which is why traffic never goes directly to a pod, only to a Service.”

“The Deployment is what I write. It creates a ReplicaSet, which makes sure the requested number of pods exists. On every image change, the Deployment creates a new ReplicaSet and scales it up gradually while scaling the old one down — that's where the rolling update comes from. The old ReplicaSet stays around, empty, so I can roll back to it.”

“ClusterIP is the default and is only visible inside the cluster. NodePort opens the same port on every node. LoadBalancer requests a load balancer from the cloud provider. ExternalName is just a DNS alias. In practice I use ClusterIP everywhere with a single Ingress in front, because a LoadBalancer per service costs money and adds nothing.”

“The first command is kubectl get endpoints. If the list is empty, the Service isn't finding any pod — and nine times out of ten it's a mismatch between the pod's label and the service's selector, one extra letter somewhere. If the list has pods but it's still not working, then it's the port: targetPort has to be the port the application is actually listening on, not the one the service exposes.”

“The Service works at the network level and routes traffic to a set of pods. The Ingress works at the HTTP level: it routes by domain and by path, terminates TLS, and all the services come in through a single door. Ingress on its own does nothing — you need a controller installed that reads the rules and applies them.”

“Both bring configuration into the pod, as environment variables or as mounted files. The declared difference is that Secret is for sensitive data. The real difference is much smaller than it sounds: by default, a Secret is only encoded in base64, not encrypted. Anyone with read access to it reads it in plain text. That's why, for anything serious, you either turn on encryption in etcd or keep the secret outside — Vault, External Secrets Operator, Sealed Secrets.”

The line about base64 is one of the few that, said spontaneously, immediately shows you've actually worked with it.

“Deployment is for stateless applications: the pods are interchangeable, they have random names, they start and stop in any order. StatefulSet is for anything with an identity: stable, numbered names, its own disk that stays its own, ordered startup and shutdown. Databases, queues, anything with local data. The practical difference people often get tripped up on: if a node becomes unreachable, Deployment pods get recreated somewhere else right away, whereas a StatefulSet pod doesn't get recreated automatically — because the system can't be sure the old one actually died, and two instances with the same identity would corrupt the data.”

“Readiness means “I can receive traffic” — if it fails, the pod is taken out of service, but it doesn't restart. Liveness means “I'm alive” — if it fails, the container restarts. Startup is for applications that start up slowly, and it holds off the other two until startup finishes. The mistake I've seen is a liveness probe pointed at an endpoint that checks the database: the database has a ten-second hiccup, all the pods restart at once, and a slowdown turns into a total outage.”

“Request is how much you reserve, and it's what decides which node the pod lands on. Limit is the ceiling at runtime. The asymmetry matters: on CPU, if you go over the limit, you get throttled — the application keeps running, just badly, and it's hard to diagnose. On memory there's no throttling. You go over and you get killed — OOMKilled, exit code 137.”

“The scheduler has nowhere to put it. Most often there aren't enough free resources for what it's requesting, but it could also be a taint on the nodes with no matching toleration on the pod, a node selector that doesn't match, or a volume that can't attach in that zone. kubectl describe pod writes the exact reason in the events, at the bottom.”

“The container starts, dies, and Kubernetes restarts it with longer and longer pauses. The first command is kubectl logs --previous, to see why the previous instance died, not the one that just started. Then the exit code: 137 means it was force-killed, usually memory; 1 or 2 is usually an application error or a missing config or secret.”

“The container is running, but the readiness probe isn't passing. Either the application is started and not ready yet, or the probe is configured wrong — wrong path, wrong port, or too short a timeout for how long startup takes. I check what the probe says in describe and try the endpoint from inside the pod.”

“Rolling update with maxUnavailable: 0 and maxSurge: 1 — meaning I bring up a new pod before taking down an old one, so capacity never drops. I need a correct readiness probe, otherwise traffic goes into pods that aren't started yet, and graceful shutdown in the application, so in-flight requests finish. And in the pipeline I always put a kubectl rollout status with a timeout, because otherwise the update command returns success immediately and the deployment looks successful even if no new pod ever started.”

“Nothing bad is happening, and that's exactly the danger. If the new pods don't pass the readiness probe, the update simply stops: the old ones keep serving traffic, the new ones sit there not ready. There's no automatic rollback. I check with kubectl rollout status, look at the events and the new pod's logs, and if there's nothing to fix on the spot, I run kubectl rollout undo.”

“Horizontally, with Horizontal Pod Autoscaler, on CPU or on a custom metric, with node autoscaling underneath so there's somewhere for it to fit. It only works if the application is stateless. The trap is scaling on CPU for a service that isn't CPU-bound — if the bottleneck is the number of database connections or the length of a queue, scaling on CPU either doesn't trigger, or it triggers and makes things worse. There, you scale on the real metric.”

“No. It's a logical division — names, resource quotas, permissions. But network traffic flows freely between namespaces unless you set a NetworkPolicy, and some things are cluster-level anyway. This confusion is common and leads to clusters where the test environment can talk to production.”

“A virtual machine has its own kernel and its own operating system, so it boots in minutes and takes up gigabytes. A container is an ordinary process on the host machine, isolated through kernel mechanisms, sharing the kernel with everything else. It starts in milliseconds and takes up as much as the application. The practical consequence: isolation is weaker than with a virtual machine, which is why you don't put workloads with very different trust levels into the same cluster.”

“The image is the template — read-only, immutable layers. The container is the image started up, with a writable layer on top. From one image you can start a hundred containers. What you write inside the container disappears when you stop it, which is why data goes on a volume and logs go to standard output.”

“I order the instructions from the ones that change rarely to the ones that change often. I copy the dependency file first and install them, and only then copy the code — that way the dependency layer stays cached and doesn't get reinstalled on every code change. The opposite, meaning COPY . . before installing, invalidates everything on every commit, and it's the most common mistake.”

“In a first stage I use a large image, with a compiler and tools, and build the application. In the second stage I start from a minimal image and copy over only the output from the first one. It's a double win: the final image is tens of times smaller, and I don't ship compilers and tools into production, which are, in effect, attack surface.”

“A minimal base image, ideally distroless, pinned to a version, not to latest. Running as a non-privileged user, not root. Read-only filesystem where possible. No secrets at build time — if one made it into a layer, it stays recoverable even if you delete it in a later layer. And automated scanning in the pipeline, with Trivy or equivalent.”

“Because it's not a version, it's a pointer that moves. Two identical deploys can end up running different images, and when something breaks you can no longer tell what was running an hour ago. I use the tag with the commit hash: it's unique, immutable, and tells me exactly what code is inside.”

“To standard output, never to a file inside the container. The file disappears along with the container, fills up the node's disk, and nobody sees it. On standard output, the platform picks it up and it ends up where it needs to.”

“Disk space. df -h. It's trivial and it's the most common cause — a full disk stops almost everything, and often in ways that seem unrelated: the database stops writing, logs stop, processes hang. It takes a second and rules out the most likely culprit. After that I check whether the process is running, whether it's listening on the port, what the log says, and what changed recently.”

“ss -ltnp — shows the listening ports, with the process. lsof -i :443 does the same thing a different way. If nothing is listening, the problem is in the application or the service, not the network, and I go into journalctl -u.”

“du -sh /* | sort -h, and I work down directory by directory. But first I check something that catches a lot of people out: a deleted file that a process still has open doesn't free up the space. lsof | grep deleted shows it, and it's fixed by restarting the process, not by deleting something else.”

“-e stops the script at the first failed command. -u errors out on an undefined variable, which catches typos before they do damage. -o pipefail makes a pipeline fail if any element in it fails, not just the last one. Without them, a script that fails halfway through keeps going and can leave the system in a worse state than if you hadn't run it at all.”

“Because without it, curl returns a success code even on a 500 response — it successfully downloaded the error page. With -f it fails on HTTP error codes, so set -e actually stops the script. I also add --max-time, otherwise a call can hang indefinitely inside a cron job.”

“That running it twice gives the same result as running it once. It matters because in operations you never have a guarantee that something ran exactly once — a retry, a job started twice, someone clicking again. A script that appends a line to a config file every time it runs is a ticking bomb.”

“flock on a file. It's one line and it completely solves the problem of cron jobs overlapping when one run takes longer than the interval.”

“It means infrastructure is described in files kept in Git, not created by hand in the console. You gain three things: you can rebuild the environment identically, you can see in the history who changed what and why, and you can review a change before it happens. The fundamental difference from a script is that Terraform is declarative — you describe what you want to exist, not the steps.”

“It's the record of what Terraform created and how it maps to the real resources. Without it, Terraform can't know what to change and what to delete. Three rules: it lives remotely, not on a laptop, so the whole team works off the same one; it has locking, otherwise two simultaneous runs corrupt it; and it contains sensitive values in plain text, so it's treated as a secret.”

“When someone changes something directly from the console, reality no longer matches the code. terraform plan shows it as a diff. What I do in practice is remove the cause: write access only from the pipeline, people get read access. If drift is already there, I either bring it into the code or let Terraform correct it — but that decision gets made consciously, not through a rushed apply.”

“The rule I hold myself to is that I don't run apply without reading the plan all the way through, and I look first at anything marked “destroy” or “replace”. A seemingly harmless rename can mean, in the plan, destroying and recreating a resource. On resources with data I set prevent_destroy, so the system refuses even if the person makes a mistake.”

“Yes — Terraform on AWS and Azure, in parallel, at RapidBid, plus Google Cloud at DISH, on GKE and Cloud SQL. What I took away is that the difference is smaller than it looks from outside: the providers change, the service names and the authentication method change, but the plan–apply flow, the state discipline and the way you split things into modules stay the same. The services map almost one to one.”

“The biggest win, almost always, comes from resources requested far above what's actually used — you pay for the reservation, not the consumption. After that: test environments shut down at night and on weekends, disks and IP addresses left orphaned after deletions, traffic between availability zones that costs money and can often be avoided. And tagging resources, without which you can't even tell who's spending what.”

“The four golden signals: latency, traffic, errors, saturation. For latency I look at p95 and p99, not the average — the average hides exactly the affected users. You can have an average of 200 milliseconds and a percentage of users waiting eight seconds, and those are the ones who call in.”

“SLI is what you measure — for example, the percentage of requests under 300 milliseconds. SLO is the internal target on that indicator. SLA is the contractual promise to the customer, always more relaxed than the SLO, so there's margin. The SLO gives you the error budget: how much you're allowed to get wrong. If there's still budget left, the team ships aggressively; if it's used up, they stop and fix things. The measurement makes the decision, not whoever talks loudest in the meeting.”

“I alert on symptom, not on cause — the error rate, not CPU at 90%, which can be perfectly normal. Every alert that goes off at night has to require immediate human action; if it can wait until morning, it's a ticket, not an alert. And every alert has a runbook. When you get forty alerts a day and thirty-nine of them need nothing, you miss the fortieth.”

“First I restore, then I look for the cause. I confirm that I'm taking ownership of the incident, so two people aren't working the same thing. I check what changed recently — a deploy, a config change, a certificate — because that's where the cause is in most cases. If it's a recent deploy, I roll back to the previous version without digging further; I do the diagnosis after people have the service back. And I communicate proactively, at intervals, so nobody has to interrupt the team to ask how it's going.”

This is your home turf. Tie it immediately to Metro: “this is exactly the order I used for years in production control.”

“It's the post-incident analysis where you look for the cause in the system, not in the person. If a wrong command was able to wipe out production, the problem isn't the person who typed it, it's that the system accepted it without confirmation and without a way back. It matters for a very practical reason: if names show up in the analysis, next time people hide incidents, and you lose exactly the information you need.”

“MTTR is the average time to restore, MTBF is the average time between failures. In distributed systems, something is always failing — you can't push MTBF to infinity. What you can control is how fast you recover. That's why you invest in fast recovery, in small deploys, and in the ability to roll back a change in a few minutes, not in the promise that nothing will ever fail again.”

Use the Metro story from chapter 4.2. Don't improvise a different one — this one is rehearsed and holds up under questioning, because it's yours.

This question isn't looking for the mistake, it's looking for whether you're able to admit it. A candidate who says “I don't remember ever making a mistake” disqualifies themselves. Structure: what I did, what broke, what I did right away, what I changed so it couldn't happen again. The emphasis falls on the last part — that's where maturity shows.

What's being tested is whether you can disagree without turning it into conflict. The structure that works: what the disagreement was, what my argument was, what their argument was, how it got decided, and what I did after it was decided differently than I wanted. The last part is what's being evaluated. “I said what I thought, it was decided differently, I supported the decision, and I put a safeguard in place for the risk I was worried about” is a very good answer.

“By impact on the customer, not by who asked loudest. If something affects production, it takes absolute priority and everything else waits — and I tell the others it's waiting, I don't let them think I'm working on it. My years in production control taught me that communicating what you're not doing is just as important as doing.”

Answer concretely, not with “I read a lot.” What exactly, how often, and the last thing you learned and actually used. One concrete example is worth ten general statements.

“I write down what I do, so nobody depends on me being present on a chat channel. I document what I broke and what I fixed. And I flag early when something is taking longer than I estimated — a delay said in time is information, said late it's a problem.”

Don't invent a spectacular career plan. “Still on infrastructure and reliability, with more depth in Kubernetes and automation, on a team where I can also pass on what I know. I don't have management ambitions.” It's short, credible, and doesn't expose you.

“Because I miss what I had there: a team, a larger scale, and serious procedures. On my own I've done every role and learned a lot, but I work alone. I want to go back to an environment where the systems are large and I can specialize instead of covering everything.”

Answer briefly and factually, with no criticism of them at all. Don't blame anyone, don't tell the internal backstory, don't explain it three times. One sentence about what happened, one about what you did next. Anything you add beyond that works against you.

“I worked independently during that time. I built and kept my own systems running — infrastructure, automations, integrations. It wasn't a break from work, it was a different kind of work. What I missed was the team and the scale, and that's why I'm coming back.”

“I don't think I am. The operations, incidents, and large-systems side I have solid from the earlier years. The modern-tooling side — Kubernetes, infrastructure as code, pipelines — I have, and I want to go deeper into it. I'm interested in this role, not a management one, and technical work doesn't bore me.”

The hidden question is: “will you leave quickly?” or “will you be hard to manage?” The answer needs to put exactly those two at ease.

Ask first: “Do you have a range allocated for the role? I'd rather we start from there, so neither of us wastes time.” If they insist you give a number first, give a range, not a figure, and add “depending on the full package.” Don't apologize for the number and don't explain why you need it — personal reasons have no place in a negotiation.

It's a good question and rarely asked, and an honest answer impresses. “I've operated Kubernetes, but I've written fewer manifests than I'd like. And I haven't taken a whole organization onto GitHub Actions. Both are a few weeks of actual work away, and I've made that kind of transition before, when I moved onto Google Cloud.” Name exactly two things, not ten, and don't pick something essential to the job.

Tell the truth, briefly, no names. “Yes, I have a few others in discussion, but none finalized.” It's not a threat and it's not a weakness — it's normal information, and it positions you as an in-demand professional.