DevOps Engineer interview questionsInfrastructure as code review — a refactor that deletes the database round

Purpose

Casts the candidate as the reviewer of someone else's change, which is how this job most often meets infrastructure code, and leaves them to decide what to read first.

Purpose

The first read of infrastructure as code. The discriminator is whether the candidate reads the plan line by line, finds two destroys among sixteen changes, and explains them from how the tool identifies a resource — rather than approving the diff, which reads as a tidy refactor.

Signals to score

• Finds the two destroys among sixteen changes instead of stopping at the summary or at the tag noise
• Explains why they are there: the resources moved to new addresses, and with no `moved` blocks the tool plans one resource to delete and an unrelated one to create
• Says what the delete costs with this configuration: no final snapshot, no deletion protection, and automated backups removed with the instance
• Notices that the storage change the description promises appears nowhere as an update, which shows the plan is not the change the author meant
• Reads the bastion rule's removal as drift — a rule in the account that is not in code — rather than as part of this change
• Checks one tag-only update to confirm it is only tags, then sets the rest aside
• Objects to a provider major version upgrade in the same pull request as a refactor, because nothing unexpected in the plan can then be attributed
• Asks what the create does while the old instance still holds the identifier `orders`
• Asks whether the posted plan is from the latest commit, and which state and account it ran against

Follow-up questions

• What does the summary line tell you, and what does it hide?
• The description says storage goes to 200 GB. Where is that in the plan?
• Applied as it is, what could you restore the orders data from?
• Is the bastion change part of this pull request?
• Why does it matter that the provider upgrade came along?

Purpose

The candidate writes code — `moved` blocks and a check over the plan's JSON — and makes release decisions about a stateful resource. Someone who has done this protects the data on the cloud side first, because the tool's own protection disappears in exactly this kind of refactor.

Signals to score

• Adds `moved` blocks for both resources, from the old addresses to the module addresses
• States what the new plan must show before approval: nothing added or destroyed, and storage 100 → 200 as an in-place update
• Moves the provider upgrade into its own pull request, whose plan should show nothing they cannot explain
• Turns on deletion protection for the instance first, as its own change, and explains why `prevent_destroy` would not have caught this — it lives in the resource block, and a move removes the block
• Replaces `skip_final_snapshot = true` with a named final snapshot, and takes a manual snapshot before applying anyway
• Writes the check over the plan's JSON: any resource change whose actions include delete, for a type that holds data, fails the job
• Makes overriding the check a visible act approved by someone other than the author
• Asks when the storage change takes effect — immediately or at the next maintenance window — and knows storage can grow but not shrink
• Orders the rollout: protection, then the refactor, then the provider upgrade, each applied and its plan checked clean before the next

Follow-up questions

• Would `prevent_destroy` on the old resource have stopped this pull request?
• What must the new plan show, line by line, before you approve it?
• Write the check. What exactly does it read from the plan?
• Next month someone really does need to replace a database. How do they get past your check?
• When does the storage change actually happen?

Purpose

Reads whether the candidate treats drift as information to act on deliberately — neither reverted silently as a side effect nor written quietly into code — and whether they make the hand change unnecessary next time.

Signals to score

• Keeps the rule's removal out of this pull request, and does not add the rule to code to make the plan clean
• Finds out who added it and why from the cloud audit log before deciding anything
• Checks whether anyone still uses it and tells them when it will close
• Closes it in a change of its own, with its own review
• Replaces what it was for with an access path that needs no port open to the internet
• Runs drift detection on a schedule — a plan whose exit code distinguishes changes present — and sends the result to a person
• Gives incident responders a sanctioned emergency change that is recorded and must be written into code or reverted within a set time
• Says what a plan will never show: resources created by hand that the code does not manage at all

Follow-up questions

• If the database problem were fixed, would you merge with the rule's removal still in it?
• How do you find out who added the rule?
• The on-call engineer says they needed it and may need it again. Now what?
• How would you have known about this three weeks ago?
• What kind of drift would no plan ever show you?

Purpose

Tests whether the candidate reads short-lived credentials as the start of the question rather than the answer. Federation removed the stored keys; the trust policy, what a plan job can do, and who can read state decide who really holds the access.

Signals to score

• Reads the trust condition as accepting a token from any workflow run on any branch of the repository, so a branch can edit its own workflow to apply, or run anything, as administrator
• Says the rule that nothing is applied before review currently lives in a file the change under review can modify
• Knows a plan is not harmless: it evaluates data sources and runs providers, and some data sources run programs, so planning unreviewed code with strong credentials is running it
• Splits the roles: a read-only plan role trusted for pull requests, and an apply role trusted only for a protected environment that requires approval and deploys only from `main`
• Knows the state holds the database's master password in plain text whatever the variable is marked, and that everyone who can read the bucket can read it
• Rotates the password, narrows who can read state, then keeps the password out of state — one the database service manages, or an argument the tool does not store
• Applies the plan that was reviewed rather than planning again on merge, or shows the new plan to an approver before it runs
• Serializes applies, and says what happens when two merges land close together
• Scopes the apply role to what this repository manages instead of administrator access

Follow-up questions

• Which workflow runs can assume `infra-admin` today?
• Is a plan safe to run on a branch nobody has reviewed?
• An engineer can read the state bucket. What can they read in it?
• Two pull requests merge a minute apart. What does each apply do?
• You have one hour. What do you change first?

Purpose

Not scored. This is the candidate's time to learn what the job holds; anything worth keeping goes in the notes.

Purpose

A true, specific weakness is a stronger pitch to the engineer this round is looking for than any description of the stack, and an honest warning to one who wanted it finished. Say it only if it is still true.