Top 30 Automation Interview Questions and Answers
30 multiple-choice questions on Automation, drawn from 30 bites out of the 146 tagged Automation on Tezvyn. Answer them here or read straight down. Every question carries the correct option, why it is correct, and a link to the bite it came from.
30 questions. Pick an answer, or open “Show the answer” to read it.
Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.
Question 1 of 30
Which task best fits the SRE definition of toil rather than overhead or engineering project work?
Show the answer
Answer: a · Manually rerunning the same failed batch job every night by hand
Manually rerunning the same job nightly is manual, repetitive, automatable, and scales with the service, the hallmarks of toil. Designing a system is engineering; meetings and interviews are overhead.
Question 2 of 30
A team merges into a shared branch daily with automated builds and tests. What is the single most important goal of this Continuous Integration practice?
Show the answer
Answer: c · Keeping the integrated codebase in a workable state at all times
The defining goal of CI is maintaining a workable integrated codebase, not deployment, which is the realm of CD. While automation and bug detection are part of the practice, they are mechanisms and secondary benefits rather than the core objective.
Read the full bite: What is CI, and what is its single most important goal?
Question 3 of 30
Which characteristic is most crucial for an effective build automation process?
Show the answer
Answer: c · It consistently transforms source code into a runnable application, regardless of the environment.
The card emphasizes that build automation makes the process "repeatable, reliable" and ensures "the same result every time, no matter who pushes the 'start' button." Option C directly reflects this core benefit. Option D describes the "it works on my machine" problem that build automation aims to eliminate, not a desired characteristic.
Question 4 of 30
A developer pushes to main, triggering a CI pipeline with build, test, and deploy stages. Which outcome best matches typical execution?
Show the answer
Answer: b · A runner builds the project; then multiple runners execute test jobs in parallel; deployment proceeds only if every test job succeeds.
The card states that runners (not the Git server) execute jobs, that jobs within a stage run in parallel, and that a stage must succeed completely before the next stage begins. Option C is tempting because it correctly mentions sequencing but wrongly assumes everything runs sequentially on one machine and ignores the requirement that all jobs pass.
Read the full bite: Describe the typical CI pipeline sequence from push to deploy
Question 5 of 30
What is a key advantage of automated testing in modern software development?
Show the answer
Answer: a · It allows for rapid and confident deployment of code changes by detecting regressions early.
The card highlights that automated testing "provides the confidence needed to deploy changes frequently" and is "the foundation for catching regressions." Option B is incorrect because the card explicitly states automated testing is "not suited for exploratory testing... or for assessing subjective user experience."
Read the full bite: Automated Testing: Catch Bugs Before They Ship
Question 6 of 30
A company automatically deploys its internal tools to production but requires manual sign-off for its customer-facing payment service. What does this mixed strategy best demonstrate?
Show the answer
Answer: d · Different applications may require different pipeline models based on business risk and compliance needs.
The card stresses that the choice between Continuous Delivery and Continuous Deployment is driven by business context, regulatory requirements, and blast radius, and that organizations often run a mixed model. Option A reflects the common misconception that Delivery is just an inferior version of Deployment, while the correct answer captures the intentional, risk-based pipeline design described in the card.
Question 7 of 30
Which event should trigger an automated CI/CD retraining pipeline rather than just an alert or manual review?
Show the answer
Answer: c · Sustained accuracy drop of 5% over a rolling window or business metric degradation past a predefined cost threshold
The card specifies that automated retraining launches on sustained accuracy drops of 5% or more or business metric degradation exceeding a cost threshold, whereas latency spikes and missing features should page an on-call engineer for infrastructure issues. Weekly manual reviews and overly sensitive single-hour drift alerts are red flags that signal immature operational practices.
Read the full bite: What production metrics and auto-thresholds trigger model retraining?
Question 8 of 30
What is the primary problem Infrastructure as Code (IaC) aims to solve in managing IT infrastructure?
Show the answer
Answer: a · Preventing configuration drift and ensuring consistent, repeatable environments.
The card explicitly states IaC was created to combat 'configuration drift' and ensure 'consistent, repeatable environments.' While IaC can contribute to cost efficiency, its main purpose is not cost reduction, and it does not eliminate all human involvement, but rather automates the provisioning process through code, not GUIs.
Read the full bite: Infrastructure as Code: Manage Servers with Code, Not Clicks
Question 9 of 30
What is the best way to prioritize which toil to automate first?
Show the answer
Answer: c · Rank by return on investment, weighing frequency and time saved against automation effort and risk
Prioritizing by ROI, frequency times time saved versus effort and risk, maximizes recovered engineering time. Irritation, ease alone, or script count are poor proxies for actual impact.
Read the full bite: How do you find and eliminate toil systematically?
Question 10 of 30
Which is the primary advantage of Pipeline as Code over configuring CI/CD processes via a graphical user interface?
Show the answer
Answer: a · It enables version control, peer review, and auditability of the build and deployment logic.
The core benefit of Pipeline as Code is treating the pipeline definition as a version-controlled file, which allows for reviewable changes and a complete audit history. Option D is incorrect because Pipeline as Code explicitly involves defining the pipeline through code, such as a Jenkinsfile.
Read the full bite: Pipeline as Code: Versioning Your Build Process
Question 11 of 30
According to the 'cattle, not pets' mental model for immutable infrastructure, which action is characteristic?
Show the answer
Answer: a · Building a new server image with all necessary updates and replacing existing instances.
The 'cattle, not pets' model dictates that servers are replaced, not modified. This means building a new image with updates and deploying new instances from it, then decommissioning the old ones. Modifying running instances, even with configuration management, is characteristic of mutable infrastructure.
Read the full bite: Immutable Infrastructure: Treat Servers Like Cattle, Not Pets
Question 12 of 30
What fundamentally distinguishes the SRE response to a recurring high-volume alert from a traditional ops response?
Show the answer
Answer: a · SRE treats it as a defect to automate or eliminate so effort scales sublinearly with load
SRE applies software engineering to remove the recurring work entirely, breaking the link between load and headcount. Faster manual response, more dashboards, or more engineers are the linear-scaling ops pattern SRE avoids.
Read the full bite: SRE vs traditional ops on a recurring alert?
Question 13 of 30
How does rebasing a feature branch onto main before a PR typically affect CI behavior compared to merging main into that branch?
Show the answer
Answer: b · Rebase generates new commit SHAs, causing CI to treat rebased commits as new pushes and queue multiple builds.
Rebase replays commits onto the target branch, which creates fresh SHAs that CI systems treat as brand-new pushes, burning compute minutes and orphaning prior build results, whereas merge preserves the original SHAs and triggers a single integration build. Option C is tempting because many beginners believe rebase is inherently cleaner or safer, but it actually requires force-push and breaks the one-to-one link between a commit and its CI result.
Read the full bite: Difference between git merge and git rebase before a pull request
Question 14 of 30
Which operation is LEAST suited for an idempotent design in an automation script?
Show the answer
Answer: a · Recording each attempt of a user login into an audit trail.
The card states that "appending a log entry" is an example of an operation where idempotency is the "wrong goal" because you want "each execution to have a distinct effect." The other options describe tasks (package installation, resource provisioning, schema migration) that are explicitly mentioned as scenarios where idempotency is vital for reliable, repeatable automation.
Question 15 of 30
Why should a team not rely solely on a pre-push hook to guarantee that all tests pass before merging?
Show the answer
Answer: a · It is local-only, not cloned with the repository, can be skipped with --no-verify, and does not run for web or API commits.
Pre-push hooks reside in .git/hooks and are not copied on clone, can be bypassed with --no-verify, and do not run for web or API commits, so they cannot replace server-side enforcement. Option B is a tempting misconception: --no-verify skips pre-push hooks as well as commit hooks.
Read the full bite: Describe using a pre-push Git hook for checks and its CI limitations.
Question 16 of 30
Which of the following describes a proper ETL implementation?
Show the answer
Answer: b · A scheduled process automatically extracts data from several sources, transforms it, and loads it into a central database.
ETL is intended as an automated, three-phase pipeline run on recurring schedules, which option B illustrates. Option A represents the manual-run footgun the card warns against, while B omits the required transformation phase and D describes a one-time task lacking recurring automation.
Question 17 of 30
You need to add a forbidden-word check to a React app's CI pipeline. Which approach best prevents user-facing policy violations while keeping the signal-to-noise ratio low?
Show the answer
Answer: a · Extract string literals from a framework-specific user-facing hook, check against tiered rules with allowlists, and run as a fast PR annotation job.
Option A is correct because it targets only user-facing strings via AST-aware extraction, uses severity tiers and allowlists to control noise, and gates pull requests with fast inline feedback. Option C is a tempting distractor because grepping all source files sounds thorough, but it cannot distinguish UI text from variable names or comments, generating false positives that train teams to ignore the check.
Read the full bite: How would you automate forbidden-word checks in CI/CD?
Question 18 of 30
What is the primary problem that automated token pipelines are designed to solve for design systems?
Show the answer
Answer: b · Reducing the manual effort and inconsistency in translating design decisions into platform-specific code.
Automated token pipelines address the historical challenge of manual, error-prone translation of design decisions into code across multiple platforms, which leads to inconsistencies and high maintenance. While they facilitate collaboration, their core purpose is not to dictate specific design software but to standardize design decisions for automated code generation.
Read the full bite: Automated Token Pipelines: A Single Source of Truth
Question 19 of 30
Which task is an ideal use case for a user data script?
Show the answer
Answer: a · Automating the initial installation of a web server and application code on a new instance.
User data scripts are designed for "Day One" instance configuration, such as installing software and pulling application code on first boot. They are not suitable for ongoing updates, creating AMIs with baked-in configurations, or complex multi-service orchestration.
Read the full bite: User Data Scripts: Day-One Instance Configuration
Question 20 of 30
What is the key difference between a quality gate and running tests in a CI pipeline?
Show the answer
Answer: b · A quality gate enforces metric thresholds that block merges or deployments when failed.
A quality gate is a policy layer that enforces metric thresholds to block pipeline progression or merges, whereas merely running tests or linting only generates data without enforcing release readiness. The tempting distractor confuses executing checks with the policy decision that acts on their results.
Read the full bite: What is a CI/CD quality gate? Give a simple example.
Question 21 of 30
Which approach reliably automates blocking a merge when a pull request causes total project coverage to drop by more than two percentage points?
Show the answer
Answer: b · Generate a coverage report in CI, upload it to Codecov, set the project status threshold to 2 in codecov.yml, and require the Codecov project status in branch protection
This option correctly combines coverage artifact generation, Codecov upload, a project status threshold of 2, and branch protection enforcement. Option D is tempting because it uses the same tools, but patch coverage only measures lines changed in the PR rather than the overall project drop.
Read the full bite: How would you block merges when PR coverage drops 2%?
Question 22 of 30
Which combination of tools and logic is most appropriate for maintaining participant engagement across a two-week diary study?
Show the answer
Answer: c · Calendly scheduling, cascading reminders via Zapier, and automated no-show rebooking flagged in Airtable
A scalable diary study requires an orchestrated pipeline with self-scheduling, cascading reminders, and automatic no-show rebooking to manage longitudinal complexity. Option D is tempting because Google Forms is a common research tool, but a single static email cannot handle the repeated touchpoints and scheduling logic required for retention.
Read the full bite: Describe a workflow to automate a 50-person diary study
Question 23 of 30
What is Make's core mechanism for deciding which build steps to execute?
Show the answer
Answer: c · It compares the modification times of target files with their dependencies.
Make achieves efficiency by building a dependency graph and comparing timestamps. It only re-executes commands for a target if its dependencies are newer or the target doesn't exist, avoiding unnecessary work. Option D describes a simple script, which Make improves upon by adding intelligence.
Question 24 of 30
In an automated rollback pipeline triggered by a failed canary smoke test, which step must occur before redeploying the last known good release?
Show the answer
Answer: c · Shift traffic back to the stable baseline and freeze the canary progression
The card states that traffic isolation—freezing the canary and shifting traffic to the stable baseline—must happen before any rollback begins to minimize blast radius. Running health checks against the previous release is part of post-redeploy verification, while manual approval or in-place patches break the automated safety contract.
Read the full bite: Smoke test fails after canary deployment. Design the automated rollback.
Question 25 of 30
Which strategy best balances immediate pipeline unblocking with sustainable reduction of E2E flakiness at scale?
Show the answer
Answer: b · Baseline flakiness rates, auto-quarantine chronic offenders from presubmit, and fix root causes like concurrency
Baselining metrics and quarantining chronic offenders targets root causes while protecting presubmit integrity. Relying solely on retries masks flakiness, delays detection of real breakages, and never reduces the overall flakiness rate.
Read the full bite: How would you diagnose, report, and mitigate E2E flakiness at scale?
Question 26 of 30
Which statement accurately describes a key characteristic of static analysis?
Show the answer
Answer: d · It analyzes source code for potential issues without actually running the program.
Static analysis fundamentally operates by examining the source code itself, without executing the program, to find patterns that indicate potential issues. Option B describes dynamic analysis, which observes program behavior during runtime, a direct contrast to static analysis.
Read the full bite: Static Analysis: Read Code, Don't Run It
Question 27 of 30
What should an automated pipeline validate after a model is tagged Staging but before it receives production traffic?
Show the answer
Answer: c · Data drift, performance regression, bias thresholds, schema compatibility, and security scanning
Before any traffic exposure, the pipeline must automatically validate data drift, performance regression, bias, schema compatibility, and security against production baselines. Option B is tempting because it mentions holdout metrics and model cards, but a signed card is a trigger rather than a validation gate, and holdout metrics alone omit critical production-specific checks like drift and bias.
Question 28 of 30
What is the main benefit of Gradle's approach to build automation compared to tools that rely on rigid XML configurations?
Show the answer
Answer: b · It offers greater flexibility and programmatic control over the build process using a scripting language.
The card emphasizes that Gradle's code-based approach, using a Groovy or Kotlin DSL, provides the flexibility of a real programming language, allowing for variables, control flow, and custom logic. This contrasts with the rigid, declarative nature of XML-based tools. Option C describes the characteristic of XML-based tools, not Gradle.
Question 29 of 30
A developer aims to create a real-time, collaborative design editing experience using the Figma REST API. Why is this approach fundamentally flawed?
Show the answer
Answer: c · The API is primarily designed for static data extraction and automation, not live, synchronous updates.
The Figma REST API is an asynchronous request-response system designed for data extraction and automation, not for mirroring the live, multiplayer experience of the Figma app. While parsing large JSON might be a performance consideration, the API's fundamental design as an asynchronous system is the core limitation for real-time collaboration, not the data complexity itself.
Read the full bite: Figma REST API: Access Design Files as Structured Data
Question 30 of 30
According to the card, what is the primary pitfall or misconception when using code coverage?
Show the answer
Answer: a · Achieving a high code coverage percentage directly ensures the high quality and correctness of the software.
The card explicitly warns that the 'footgun is mistaking high coverage for high quality' and that chasing high coverage can 'foster a false sense of security.' Code coverage measures execution, not assertion quality. Option B is incorrect because the card states its 'real value is revealing the unexplored parts of your codebase.'
Read the full bite: Code Coverage: What Your Tests Don't Tell You
Could you explain these out loud?
That is what an interview actually tests. Tezvyn gives you questions like these with what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.