These DevOps engineer interview questions cover what hiring panels in 2026 actually test: whether you can design a pipeline that ships safely many times a day, recover quickly when a deploy goes wrong, and explain the trade-offs behind every tool you have used. Interviewers no longer reward reciting tool names; they want to hear how you think about flow, feedback and failure, and they almost always hand you a broken pipeline or a production outage to reason through. The 75 questions run from culture and DORA metrics to CI/CD, GitOps, observability, security, AI and sixteen scenario based questions.
How to use this guide:
- Freshers are tested on fundamentals, Git, Linux, a basic pipeline and containers; be ready to draw your project pipeline.
- Engineers with two to five years get CI/CD design, deployment strategies, Terraform state, Kubernetes basics, secrets handling and at least two scenarios.
- Senior, lead and platform roles are pushed on DORA metrics, progressive delivery, GitOps, platform engineering, supply-chain security, incident leadership and cost.
- This is the hub guide: for Docker, Kubernetes, Terraform, Ansible, Git, Prometheus and Grafana, DevSecOps, FinOps, AWS, Azure, Linux and MLOps, answers summarise and link to the specialist guide.
Contents
- DevOps culture and fundamentals (Q1โQ12)
- CI/CD pipeline design and artifacts (Q13โQ24)
- Deployment strategies and rollback (Q25โQ30)
- Infrastructure as Code and configuration management (Q31โQ36)
- Containers and orchestration (Q37โQ40)
- GitOps and platform engineering (Q41โQ44)
- Observability, on-call and incidents (Q45โQ50)
- Pipeline security and cost awareness (Q51โQ54)
- AI in DevOps and DevOps for AI (Q55โQ57)
- Career paths and fresher preparation (Q58โQ59)
- DevOps scenario based questions (Q60โQ75)
- Key takeaways
- Interview preparation checklist
- FAQ
DevOps culture and fundamentals
1. What is DevOps, and why is it important?
Answer: DevOps is a way of working in which the people who build software and the people who run it share responsibility for delivering it, supported by automation and fast feedback. The goal is to shorten the path from a code change to value in production while keeping that path safe. It matters because large, infrequent releases are slow and hard to debug; DevOps replaces them with small batches, automated build-test-deploy, shared monitoring and blameless learning.
Interview tip: Avoid answering "DevOps is CI/CD plus Docker plus Kubernetes". Lead with culture and flow, then mention the practices and tools that enable them.
2. How does DevOps differ from traditional IT operations and development models?
Answer: In a traditional model, development writes code and "throws it over the wall" to a separate operations team that deploys and runs it, often through change tickets and scheduled release windows. Incentives conflict: features versus stability. DevOps aligns them. Teams own a service end to end ("you build it, you run it" in its strong form), environments are created from code rather than by hand, releases are small and frequent, and stability comes from automated testing, progressive rollout and fast rollback rather than from releasing rarely.
Real-world example: Consider a bank's GCC team in Hyderabad that moved from a monthly weekend release with a long manual runbook to daily deployments through a pipeline.
3. What does CALMS mean in DevOps?
Answer: CALMS is a common framework for assessing DevOps adoption: Culture (shared ownership, blameless learning), Automation (build, test, infrastructure, deployment), Lean (small batches, limiting work in progress, removing waste and waiting), Measurement (delivery and reliability metrics, not vanity metrics) and Sharing (knowledge, tooling and postmortems across teams). Automation is only one of the five.
4. What are the DORA metrics, and what does each one measure?
Answer: DORA (DevOps Research and Assessment, the research programme now run within Google Cloud) started with the "four keys" and currently describes five software delivery performance metrics in two groups.
| Group | Metric | What it measures |
|---|---|---|
| Throughput | Change lead time | Time from a change being committed to version control to it running in production |
| Throughput | Deployment frequency | How often you deploy to production, or the time between deployments |
| Throughput | Failed deployment recovery time | Time to recover from a deployment that fails and needs immediate intervention (earlier versions called this time to restore service, often shortened to MTTR) |
| Instability | Change fail rate | Share of deployments that need immediate intervention, such as a rollback or hotfix |
| Instability | Deployment rework rate | Share of deployments that are unplanned and happen because of a production incident |
The first four are the original four keys; rework rate was added more recently. DORA's central finding: speed and stability are not a trade-off.
5. How would you measure DORA metrics in a real organisation without them being gamed?
Answer: Collect them from systems: commit and deployment events for lead time and frequency, and deployments linked to incidents, rollbacks or hotfixes for fail rate and recovery time. Then set rules that make gaming pointless: measure per service and per team for improvement, never to rank individuals; agree definitions up front (does a config change count as a deployment?); read trends, not single values; and read throughput and instability together.
Production consideration: The hardest link is deployment to incident. Tag every incident with the deployment or change ID that caused it during the postmortem, or your change fail rate will be fiction.
6. What is the difference between continuous integration, continuous delivery and continuous deployment?
Answer: Continuous integration means every developer merges small changes to the main branch frequently, at least daily, and each merge triggers an automated build and test run so integration problems surface within minutes. Continuous delivery means every change that passes the pipeline is in a releasable state and can be deployed to production at any time with a button press or approval; the decision to release is a business one. Continuous deployment goes one step further: every change that passes all automated checks goes to production automatically with no human gate. Regulated organisations often stop at continuous delivery with an approval step.
7. What tools make up a typical DevOps toolchain, and which have you used?
Answer: Describe the toolchain by stage, then name what you actually used and why. A typical map:
| Stage | Common tools |
|---|---|
| Source control | Git on GitHub, GitLab, Bitbucket or Azure Repos |
| CI/CD | GitHub Actions, GitLab CI, Jenkins, Azure Pipelines, AWS CodePipeline |
| Artifacts | Container registries (ECR, ACR, Artifact Registry, Harbor), Nexus, Artifactory |
| Infrastructure as Code | Terraform or OpenTofu, CloudFormation, Bicep, Pulumi |
| Runtime | Docker, Kubernetes (EKS, AKS, GKE), serverless |
| GitOps | Argo CD, Flux |
| Observability | Prometheus, Grafana, OpenTelemetry, ELK or OpenSearch, CloudWatch, Azure Monitor |
| Security | Secret scanners, SAST, dependency scanning, image scanning, Vault or cloud secret managers |
Interview tip: Name only tools you can debug. Cloud specifics are covered in the AWS interview questions and Azure interview questions guides.
8. Which Git branching strategy have you used, and why: trunk-based development or GitFlow?
Answer: Trunk-based development keeps one main branch; developers work on short-lived branches (hours to a day or two) or commit directly, and unfinished work is hidden behind feature flags. It suits continuous integration because there is little divergence to merge. GitFlow uses long-lived develop and release branches plus feature and hotfix branches; it suits versioned products maintaining several releases, but long-lived branches delay integration. For a continuously deployed web service I choose trunk-based development with PR review and CI on every PR.
9. What is the difference between git merge and git rebase, and when would you use each?
Answer: git merge joins two histories with a merge commit and preserves exactly what happened. git rebase replays your commits on top of another branch, rewriting their hashes to produce a linear history. Use rebase on your own local or feature branch to bring it up to date with main before opening or updating a PR,. Never rebase commits that others have already pulled from a shared branch, because rewriting shared history forces everyone to reconcile. The deeper Git questions (reflog, cherry-pick, bisect, large binary files with Git LFS) are in the Git interview questions guide.
10. What does "shift left" mean, and what are its limits?
Answer: Shift left means moving testing, security and quality checks earlier in the delivery process, closer to when code is written, because a defect found in the IDE or the PR is far cheaper to fix than one found in production. Examples: linting and unit tests on every commit, secret scanning in pre-commit hooks, dependency scanning in the PR, and IaC policy checks before terraform apply. The limit is that some problems only appear in production under real traffic and data, so shift left must be paired with "shift right": canary analysis, observability, chaos testing and fast rollback.
11. What is the role of automation in DevOps, and what should you not automate?
Answer: Automation makes repeatable work fast, consistent and auditable: builds, tests, environment creation, deployments, certificate renewal, backups and routine remediation. What not to automate, or not yet: a process nobody understands (automating chaos produces faster chaos), rare high-risk actions where a human check is cheaper than building safe automation (deleting a production database), and judgement calls such as incident severity or customer communication.
12. What Linux and networking skills does a DevOps engineer need?
Answer: Enough to debug a box without a GUI. On Linux: processes and signals (ps, top, kill), systemd services and journalctl, file permissions and ownership, disk and inode usage (df, du), memory and the OOM killer, and shell scripting with error handling. On networking: DNS resolution, TCP handshakes and ports, HTTP status codes, TLS certificates, load balancers, NAT, subnets and CIDR, and tools like curl, dig, ss and tcpdump. Many "Kubernetes problems" are really DNS, ports, certificates or permissions. Practise with the Linux commands interview questions guide.
CI/CD pipeline design and artifacts
13. What are the key stages of a CI/CD pipeline?
Answer: A solid pipeline for a containerised service usually has these stages, with fast checks first so failures surface early:
commit / PR
|
v
lint + unit tests + secret scan (minutes)
|
v
build artifact once, tag with SHA
|
v
SAST, dependency + image scan, SBOM
|
v
push to registry, sign artifact
|
v
deploy to staging -> integration tests
|
v
approval (if required)
|
v
progressive prod rollout -> verify
|
v
auto rollback on failed health checksPull requests run the early stages; merges to main run the full chain.
14. What does "build once, deploy many" mean, and how do you manage build artifacts?
Answer: You build an artifact (container image, JAR, package) exactly once, give it an immutable identifier, and promote that same artifact through test, staging and production, changing only configuration per environment. Rebuilding for each environment means production runs something that was never tested. In practice: tag images with the commit SHA (optionally also a semantic version), push to a registry such as ECR, ACR, Artifactory or Nexus, deploy by digest for full immutability, make tags immutable in the registry so nobody can overwrite v1.4.2.
Interview tip: Mentioning that latest is not a deployable tag, and why, is a quick credibility signal.
15. Explain the Jenkins architecture and how you would scale it for many teams.
Answer: Jenkins has a controller (formerly called master) that serves the UI, stores configuration and job history in JENKINS_HOME, schedules builds, and agents (formerly slaves) that execute builds on executors. To scale: never run builds on the controller; use ephemeral agents, for example pods created per build through the Kubernetes plugin or cloud VMs, so capacity follows demand and every build starts clean; manage configuration with JCasC and jobs with Jenkinsfiles; and pin and test plugins, Jenkins' main operational risk. The open-source controller is a single point of failure, so HA usually means fast, tested recovery from backups and configuration as code.
Interview tip: For a Jenkins-focused role, the Jenkins CI/CD course covers these patterns hands-on.
16. What is the difference between declarative and scripted Jenkins pipelines, and what are shared libraries for?
Answer: Both live in a Jenkinsfile checked into the repository. Declarative pipelines use a structured pipeline { agent ... stages { ... } post { ... } } syntax that is easier to read, validate and standardise. Scripted pipelines are full Groovy, giving flexibility for complex logic at the cost of readability and more room for mistakes. Prefer declarative and push any complex logic into shared libraries: versioned Groovy code in a separate repository that teams import with @Library, exposing steps like buildAndPushImage(). They remove copy-paste across Jenkinsfiles.
17. How would you choose between GitHub Actions, GitLab CI, Jenkins and Azure Pipelines?
Answer: Start from where the code lives and what the organisation already operates. If code is on GitHub, GitHub Actions is the lowest-friction option, with a large action marketplace and simple OIDC federation to clouds. GitLab CI is the natural choice on GitLab. Azure Pipelines fits Microsoft-centred estates using Azure DevOps boards and repos. Jenkins makes sense when you need maximum flexibility, must run fully self-hosted, or already have a large investment in shared libraries; the cost is that you operate and patch it yourself. Also compare runners, identity integration, templates, audit and cost per build minute.
18. What strategies do you use to optimise build times?
Answer: Measure first: find which stage takes the time. Then apply the usual levers. Cache dependencies keyed on the lock file (Maven, npm, pip caches). Order Dockerfile instructions so dependency layers are cached, and use BuildKit cache mounts or a remote layer cache. Run independent stages and test shards in parallel. Run only what changed in a monorepo using path filters or a build tool with dependency graphs. Move slow end-to-end suites to run after merge or on a schedule, keeping the PR gate fast.
19. How do you design quality gates and the testing strategy in a pipeline?
Answer: Follow the test pyramid: many fast unit tests, fewer integration or contract tests, and a small number of end-to-end tests for critical journeys. Put the fast, deterministic tests in the PR gate and make them blocking. Add static analysis, coverage on changed code rather than an absolute number, and security scans with severity thresholds. Every gate must be trustworthy: a gate that fails randomly is worse than no gate, because people learn to re-run until green.
20. How do you handle secrets and sensitive data in CI/CD pipelines?
Answer: The principle is: no long-lived secrets in code, pipeline files or logs, and pipelines get the minimum access they need for the shortest time. Concretely: use OIDC federation so the CI job exchanges its signed identity token for short-lived cloud credentials (for example GitHub Actions assuming an AWS IAM role, with the trust policy restricted to a specific repository and branch or environment) instead of storing access keys. Store application secrets in a secret manager (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault) and fetch them at deploy or run time. Scope any unavoidable CI secrets to protected branches and never expose them to fork PRs. Add secret scanning in pre-commit hooks and in CI, and have a rotation runbook ready.
21. How do you handle database schema migrations in a CI/CD pipeline?
Answer: Version migrations in the repository using a tool such as Flyway, Liquibase, Alembic or the framework's own migration system, and run them as a controlled pipeline step or a pre-deploy job, not by hand. The key pattern is expand and contract: first deploy a backward-compatible change (add a nullable column or new table), deploy application code that writes to both old and new structures, backfill data, switch reads, and only in a later release remove the old column. That keeps old and new application versions working at the same time, which is essential for rolling, blue/green and canary deployments and makes application rollback safe.
22. How do pipelines differ for a monorepo versus many repositories?
Answer: In a monorepo, one change can touch many services, so the pipeline must detect what changed and build and test only affected components, using path filters or a build system with dependency awareness; otherwise every commit triggers everything and CI becomes slow and costly. In polyrepo setups each service has its own simple pipeline, but you need reusable templates to avoid drift, plus versioned shared libraries and contract tests to catch integration problems between services.
23. What are good practices for writing maintainable pipeline-as-code?
Answer: Keep the pipeline definition in the same repository as the code and review it like code. Reuse through versioned templates, reusable workflows or shared libraries rather than copy-paste, and pin versions of templates and third-party actions (pin actions to a commit SHA, not a moving tag). Keep business logic in scripts that can run locally (make test), so the pipeline is a thin orchestrator and developers can reproduce failures on their machine. Treat pipeline changes with the same branch protection as application code, because a pipeline with production credentials is a production system.
24. How do you manage environments and promotion, including preview environments?
Answer: Define a small number of long-lived environments (for example dev, staging, production), each created from the same IaC with different variables, and promote the same artifact through them. Configuration differences belong in environment-specific values files or a configuration service, never in the image. Ephemeral preview environments spin up per pull request, often as a Kubernetes namespace, so reviewers and testers can try a change in isolation; they must be torn down automatically when the PR closes, use synthetic or masked data, and have cost limits. Keep staging production-like in networking, identity and data volume.
Deployment strategies and rollback
25. How would you implement a blue-green deployment strategy?
Answer: Run two identical production environments. Blue serves live traffic; you deploy the new version to green, run smoke tests against green directly, then switch traffic by changing the load balancer target group, a Kubernetes Service selector, or DNS weights. If problems appear, switch back to blue, which is still running the old version, so rollback takes seconds. The hard parts are not the switch but the state: database changes must be backward compatible (see Q21), sessions should live outside the instances, and in-flight connections must drain.
26. What is a canary deployment, and how do you automate the go or no-go decision?
Answer: A canary sends a small share of real traffic to the new version while the rest stays on the stable version, then increases the share in steps if the canary is healthy. Automated analysis compares canary and baseline on error rate, latency, saturation and business metrics. Tools like Argo Rollouts or Flagger on Kubernetes, or the traffic-shifting features of cloud load balancers and service meshes, run the steps and abort automatically if the analysis fails. Related techniques are dark launches (code deployed but hidden behind a flag) and shadow traffic (copying real requests to the new version and discarding its responses), which test behaviour under real load without customer impact, provided side effects such as payments or emails are suppressed.
27. What is the difference between rolling, recreate, blue-green and canary deployments?
| Strategy | How it works | Use when | Watch out for |
|---|---|---|---|
| Recreate | Stop all old instances, start new ones | Downtime is acceptable or versions cannot coexist | Outage during the switch |
| Rolling | Replace instances in batches | Default for stateless services on Kubernetes | Two versions live at once; slow rollback |
| Blue-green | Full parallel environment, switch traffic | Fast rollback matters most | Double capacity, shared database state |
| Canary | Small traffic share first, then increase | High-traffic services, risk-sensitive changes | Needs good metrics and traffic splitting |
Answer: Choose based on rollback speed needed, cost of extra capacity, whether two versions can run together and the quality of your observability. Kubernetes supports rolling and recreate natively; blue-green and canary need extra tooling.
28. What are feature flags, and how do they change deployment and release?
Answer: A feature flag is a runtime switch that turns code paths on or off without redeploying. Flags separate deployment (code is in production) from release (users see it), which enables trunk-based development with incomplete features, segment rollouts, kill switches and experiments. Risks: flag debt (old flags left in code, creating untested combinations), flag configuration changes that bypass change control, and outages caused by the flag service itself. Good practice is to give every release flag an owner and expiry, remove it once fully rolled out, audit flag changes like deployments, and have safe defaults if the flag service is unreachable. OpenFeature is a vendor-neutral CNCF specification for flag SDKs.
29. Rollback or roll forward: how do you decide, and what makes rollback safe?
Answer: During an incident caused by a deployment, rollback is the default when it is fast and safe, because restoring service matters more than finding the bug. Roll forward when the fix is small and understood, or when an irreversible data change prevents rollback. Rollback is safe only if you prepared for it: the previous artifact is still available and immutable, database changes are backward compatible, configuration is versioned with the code, feature flags can switch the new path off, and the rollback procedure is automated and practised, not a wiki page nobody has run.
30. What is required for genuinely zero-downtime deployments?
Answer: Several things together. Readiness probes or load balancer health checks so new instances receive traffic only when ready. Graceful shutdown: on SIGTERM the application stops accepting new requests, finishes in-flight ones and closes connections, and the termination grace period is long enough; on Kubernetes a short preStop delay helps endpoints update before the process exits. Connection draining on the load balancer. Enough spare capacity during the rollout (maxUnavailable: 0 with a surge). Backward-compatible APIs and schemas so old and new versions can coexist.
Want to practise these pipelines and rollouts on real infrastructure instead of only reading about them? Cloudsoft's DevOps training in Hyderabad covers CI/CD, containers, Kubernetes, Terraform and monitoring through hands-on labs, in the Ameerpet classroom or live online. Call +91 96660 19191 for a free demo.
Infrastructure as Code and configuration management
31. What is Infrastructure as Code, and what are its benefits?
Answer: Infrastructure as Code means defining servers, networks, databases, permissions and other infrastructure in version-controlled files that a tool applies, rather than creating them by clicking in a console. Benefits: environments are reproducible, every change is reviewed in a pull request and leaves an audit trail, drift can be detected, disaster recovery becomes "re-apply the code", and the same module can create many consistent environments. IaC is usually declarative (describe the end state: Terraform, CloudFormation, Bicep) rather than imperative (scripted steps), because declarative tools handle ordering and idempotency.
32. How do Terraform and CloudFormation compare?
Answer: CloudFormation is AWS's native service: no state file to manage, deep AWS integration, stack-level rollback on failure, and support for new AWS features through AWS itself. It only manages AWS (plus registry extensions). Terraform is multi-cloud and multi-provider with one language (HCL), a large module ecosystem and a clear plan before apply; the cost is that you manage state and its security. Since HashiCorp changed Terraform's licence in 2023, the open-source fork OpenTofu exists as a largely compatible alternative. The full set of state, module and workflow questions is in the Terraform interview questions guide.
33. What strategies do you use to manage Terraform state files?
Answer: Never keep state on a laptop or in Git. Use a remote backend with locking and encryption: an S3 bucket with versioning and encryption (recent Terraform versions support S3-native lock files; older setups use a DynamoDB table for locking), Azure Storage with blob leases, Google Cloud Storage, or a managed service such as HCP Terraform. Restrict access, because state can contain secrets in plain text. Split state by environment and by component (network, data, application) so a mistake has a small blast radius and plans stay fast. Use terraform state mv or moved blocks for refactoring, import blocks to adopt existing resources, and lifecycle { prevent_destroy = true } on critical resources such as production databases.
34. How would you handle secrets in an IaC framework like Terraform?
Answer: Keep secret values out of the code and out of variable files committed to Git. Prefer platform-managed secrets (for example a database password held in Secrets Manager or Key Vault) referenced by name. Where Terraform must read a secret, use a data source from the secret manager or Vault provider, mark variables and outputs as sensitive so they are redacted in CLI output, and remember that sensitive values can still land in state, which is why state must be encrypted and access-controlled. Newer Terraform versions add ephemeral values and write-only arguments designed to keep some secrets out of state; check current documentation for which resources support them.
35. How do Ansible and other configuration management tools fit into a DevOps pipeline, and why use them over shell scripts?
Answer: Terraform provisions infrastructure; configuration management tools like Ansible, Chef or Puppet configure what runs on it: packages, users, files, services, OS hardening and application deployment to VMs. Ansible is agentless (uses SSH or WinRM), uses YAML playbooks and roles, and its modules are idempotent: running a playbook twice leaves the system in the same state. Shell scripts can do the same work but you must hand-code idempotency, error handling, inventory, parallelism and reporting. In a pipeline, Ansible commonly runs after Terraform to configure VMs, or is used during image builds (for example with Packer) to create golden images. Go deeper with the Ansible interview questions guide.
36. How do you detect and handle configuration drift in production?
Answer: Drift is when the real infrastructure no longer matches the code, usually because someone changed it manually during an incident. Detect it by running scheduled terraform plan jobs (a non-empty plan on unchanged code means drift), using AWS Config or Azure Policy, and with GitOps controllers that continuously compare cluster state to Git. Prevent it by removing broad console write access in production, using break-glass roles that are logged and alerted, and preferring immutable infrastructure (replace rather than patch). When drift is found, decide deliberately: if the manual change was correct, codify it in a PR; if not, re-apply the code to revert.
Containers and orchestration
37. What are the main benefits of Docker containers, and how does a container differ from a VM?
Answer: A container packages an application with its dependencies into an image that runs the same way everywhere, which removes environment drift between laptop, CI and production. Containers start in seconds, pack densely on hosts and make immutable, versioned deployments natural. A VM virtualises hardware and runs its own full guest kernel and OS; a container shares the host kernel and is isolated using Linux namespaces (process, network, mount and others) and limited with cgroups. Containers are lighter; VMs isolate more strongly. Dockerfile practice, layers, BuildKit and container security are covered in depth in the Docker interview questions guide.
38. What is the difference between a Deployment and a StatefulSet in Kubernetes, and how is persistent storage handled?
Answer: A Deployment manages interchangeable, stateless pods: any pod can be replaced by another with a random name, and rolling updates happen in any order. A StatefulSet gives each pod a stable identity (db-0, db-1), a stable DNS name through a headless Service, ordered creation, scaling and updates, and its own PersistentVolumeClaim from volumeClaimTemplates that stays bound to that identity when the pod is rescheduled. PVCs request a StorageClass, which provisions volumes through a CSI driver. Use StatefulSets for databases, Kafka or Elasticsearch-style clustered systems, though many teams prefer managed cloud databases and reserve Kubernetes for stateless workloads. More cluster questions are in the Kubernetes interview questions guide.
39. What is a Helm chart, and how is it used?
Answer: Helm is the package manager for Kubernetes. A chart is a versioned bundle of templated manifests (templates/), default configuration (values.yaml) and metadata (Chart.yaml). You install a chart as a release with environment-specific values, upgrade it, and roll it back to a previous revision. Common alternatives or complements are Kustomize (patching plain YAML without templates) and GitOps tools that render Helm charts from Git. Pitfalls: overly clever templates that nobody can read, secrets in values files, and drifting chart versions across environments.
40. How does networking between pods and services work in Kubernetes, at interview level?
Answer: Every pod gets its own IP address, and the CNI plugin (for example the AWS VPC CNI, Azure CNI, Calico or Cilium) ensures pods can reach each other across nodes without NAT. Because pod IPs change, a Service provides a stable virtual IP and DNS name (orders.payments.svc.cluster.local) that load-balances to healthy pods selected by labels; kube-proxy or an eBPF data plane implements it. ClusterIP is internal, NodePort and LoadBalancer expose services externally, and Ingress or the newer Gateway API routes HTTP traffic by host and path. NetworkPolicies restrict which pods may talk to which, which is essential for security because the default is allow-all.
GitOps and platform engineering
41. What is GitOps, and how is it different from push-based CD?
Answer: GitOps manages deployments and infrastructure by keeping the desired state in Git and having an agent reconcile the running system to it. The OpenGitOps principles describe it as: the desired state is declarative, it is versioned and immutable (Git history), it is pulled automatically by software agents, and it is continuously reconciled. In push-based CD, the pipeline holds cluster credentials and runs kubectl apply or helm upgrade. In GitOps, CI builds and pushes the image and updates a manifest repository; a controller inside the cluster (Argo CD or Flux) pulls the change and applies it. CI never holds cluster credentials, drift is corrected, and rollback is git revert.
app repo --CI--> image in registry
|
+--PR--> config repo (manifests, tags)
|
| pulled by
v
Argo CD / Flux in cluster
|
v
cluster state == Git42. How do you handle secrets and multiple environments in a GitOps setup?
Answer: Plain Kubernetes Secrets must never be committed to Git, since they are only base64-encoded. Common patterns: the External Secrets Operator syncs secrets from AWS Secrets Manager, Azure Key Vault or Vault into the cluster, with only a reference stored in Git; Sealed Secrets encrypts secrets with a key that only the in-cluster controller can decrypt; SOPS encrypts values in files using KMS keys. For environments, use a directory or Kustomize overlay per environment (or Helm values per environment) in the config repository, promote by PR that updates the image tag in the next environment's folder, and use Argo CD ApplicationSets or Flux Kustomizations to manage many clusters. Avoid one branch per environment.
43. What is platform engineering, and what is an internal developer platform?
Answer: Platform engineering is building and running an internal developer platform (IDP): a curated, self-service layer over infrastructure, CI/CD, observability and security that lets product teams ship without each one becoming expert in Kubernetes, Terraform and cloud IAM. Typical contents: golden paths (opinionated templates that create a new service with a repository, pipeline, Dockerfile, Helm chart, dashboards and alerts already wired), a service catalogue and portal (Backstage is a widely used open-source option), and guardrails built in as policy rather than tickets. The platform team treats the platform as a product with internal customers.
44. How would you measure whether an internal platform is succeeding?
Answer: Measure outcomes for developers, not the number of features the platform team shipped. Useful signals: DORA metrics for teams on the platform compared with before; time for a new service to reach production; time to provision an environment; adoption of golden paths (voluntary adoption is the honest test, since mandated adoption hides poor experience); number of tickets to the platform team for routine tasks, which should fall; and developer satisfaction surveys. If teams are working around the platform with their own scripts, that is user research telling you what the platform is missing.
Observability, on-call and incidents
45. What is the difference between monitoring and observability, and what role does OpenTelemetry play?
Answer: Monitoring watches known failure modes; observability lets you ask new questions to debug failures you did not predict. It relies on correlated telemetry: metrics (cheap aggregates for alerting and trends), logs (detailed events, ideally structured JSON) and traces (the path of one request across services, with timing per hop). OpenTelemetry is the CNCF standard for instrumenting code and collecting this telemetry in a vendor-neutral format; the OpenTelemetry Collector receives, processes and exports data to backends such as Prometheus, Grafana Tempo or Loki, Jaeger, or commercial tools. Prometheus, PromQL and Grafana specifics are in the Prometheus and Grafana interview questions guide.
46. What are SLIs, SLOs and error budgets, and how do they guide release decisions?
Answer: An SLI (service level indicator) is a measured ratio of good events to total events that reflects user experience, such as the proportion of checkout requests served successfully within 300 ms. An SLO (objective) is the target for that SLI over a window, for example 99.9 percent over 28 days. The error budget is the allowed unreliability, the remaining 0.1 percent. While budget remains, teams ship freely; if it is being burned fast, they slow releases and prioritise reliability work. Alert on burn rate (how fast the budget is being consumed) rather than on raw thresholds. SRE-specific depth is in the SRE interview questions for DevOps engineers.
47. What makes a good alert, and how do you avoid alert fatigue?
Answer: A good page is urgent, actionable, and about user impact. Alert on symptoms (error rate, latency, SLO burn rate, the four golden signals of latency, traffic, errors and saturation) rather than causes (one pod restarted, CPU at a high level), which belong on dashboards or lower-priority tickets. Every paging alert should link to a runbook and a dashboard, and have an owner. Reduce fatigue by deleting or downgrading alerts that nobody acts on, grouping related alerts, adding sensible "for" durations to avoid flapping, and routing by service ownership. If a page fires and the right response is "ignore it", the alert is a bug.
48. How is an incident run, and what roles are involved?
Answer: Declare early, using severity levels defined in advance by customer impact. Then assign roles: an incident commander who coordinates and makes decisions but does not debug; one or more responders or operations leads who investigate and mitigate; a communications lead who updates stakeholders and status pages on a fixed cadence; and a scribe who keeps the timeline. Prioritise mitigation (rollback, failover, feature flag off, scale up) over root cause. For incidents involving AI features, there are extra failure modes covered in the AI incident response playbook.
49. What is a blameless postmortem, and what should it contain?
Answer: A blameless postmortem is a written review after a significant incident that focuses on how the system and process allowed the failure, not on who made a mistake. The assumption is that people acted reasonably given what they knew; if one engineer could take down production with one command, the system is the problem. Contents: summary and impact (duration, users affected), a timeline with detection, response and recovery times, contributing factors (usually several, not a single "root cause"), what went well, and action items with owners and due dates, prioritised so that a few important fixes actually get done. Track action items to completion.
50. How do you make on-call sustainable?
Answer: Keep rotations large enough that people are not on call too often, with a primary and secondary, clear handover, and escalation paths. Make the work reasonable: page only for actionable, user-impacting issues, keep runbooks current, and give the on-call engineer authority to roll back without asking. Track pages per shift and out-of-hours interruptions as a health metric, and spend part of each rotation fixing the causes of the noisiest alerts. For global GCC teams, follow-the-sun handovers between India and other regions can avoid night pages entirely if handover discipline is good.
Pipeline security and cost awareness
51. What security controls belong in a CI/CD pipeline?
Answer: Layer them by stage and make the fast ones blocking. Pre-commit and PR: secret scanning, linting, SAST (static analysis of your code), software composition analysis for vulnerable or badly licensed dependencies, and IaC scanning for misconfigurations such as public buckets or open security groups. Build: base image policy, container image scanning, SBOM generation, artifact signing. Deploy: policy as code at admission (Kyverno or OPA Gatekeeper rejecting privileged pods or unsigned images), environment approvals, least-privilege deploy identities. Runtime: DAST and rescanning deployed images. Set severity thresholds and an exceptions process with expiry, or teams will either be blocked constantly or ignore everything. The tool-by-tool view is in the DevSecOps interview questions guide.
52. What is software supply chain security, and what are SBOMs, signing and SLSA?
Answer: Supply chain security protects everything that goes into your artifact and the process that builds it. An SBOM (software bill of materials, in SPDX or CycloneDX format) lists the components in an artifact, so when a new vulnerability is announced you can find affected services in minutes. Signing, for example with Sigstore's cosign, proves an image came from your pipeline and was not altered; admission policies can reject unsigned images. SLSA (Supply-chain Levels for Software Artifacts) is a framework of increasing levels of build integrity, centred on generating verifiable provenance that records how and from what source an artifact was built.
53. How do you secure CI runners and the pipeline's own permissions?
Answer: Treat the CI system as a production system with powerful credentials. Give each pipeline its own identity with least privilege, scoped per environment, so the job deploying to dev cannot touch production. Prefer ephemeral runners that are destroyed after each job, so one compromised build cannot persist. Never attach self-hosted runners to public repositories. Restrict who can edit pipeline definitions and protected branches, require reviews for workflow changes, set default token permissions to read-only, pin third-party actions or plugins to verified versions. In Jenkins, apply role-based access control (for example with the Role-based Authorization Strategy plugin), restrict script approval, and encrypt controller-to-agent communication.
54. How does a DevOps engineer contribute to cloud cost awareness?
Answer: DevOps engineers control many of the decisions that create cost, so cost is part of the job. Practical contributions: enforce tagging (team, service, environment) in IaC so spend can be allocated; right-size instances and Kubernetes requests based on actual usage; autoscale and schedule non-production environments to shut down out of hours; auto-delete preview environments and old snapshots; set registry and log retention policies; use spot or preemptible capacity for CI runners and fault-tolerant jobs; and show cost estimates in Terraform pull requests with tools such as Infracost. FinOps practice in more depth is covered in the FinOps interview questions guide.
AI in DevOps and DevOps for AI
55. How does DevOps change when the application uses LLMs (LLMOps)?
Answer: The pipeline principles stay, but new artifacts and new gates appear. Prompts, model identifiers, retrieval configuration and tool definitions become versioned artifacts that can break behaviour as surely as code. Tests that check exact outputs no longer work, so evaluation suites (golden datasets scored for correctness, groundedness and safety) become a quality gate before deployment, and regressions block the release. Observability adds token usage, cost per request, latency per model call, and traces of retrieval and tool calls, often via OpenTelemetry. Model deprecations act like dependency upgrades, and self-hosted models add GPU concerns. Further reading: AI DevOps and LLMOps, CI/CD for AI applications, and the MLOps and LLMOps interview questions.
56. What is AIOps, and what are its realistic limits?
Answer: AIOps applies machine learning and, increasingly, LLMs to operations data: anomaly detection on metrics instead of fixed thresholds, correlating thousands of alerts into a few incidents, suggesting likely causes by linking an incident to a recent deployment, and LLM agents that summarise logs or run read-only diagnostics. The limits are real: models need clean, well-labelled telemetry and a service ownership map, otherwise they correlate noise; anomaly detectors produce false positives during legitimate changes such as sales events; LLM summaries can be confidently wrong; and automated remediation without approvals can turn one incident into two. Keep humans approving write actions. Scenario-style practice is in the AI DevOps and AIOps interview guide.
57. How should AI coding assistants and AI code review be used in a DevOps workflow?
Answer: They are useful for drafting pipeline YAML, Terraform modules, Dockerfiles, tests and scripts, explaining unfamiliar code, and giving a first-pass review comment on pull requests. Treat their output as an untrusted contribution: it goes through the same PR review, tests, security scanning and policy checks as human code. Watch for specific risks: invented packages or arguments, outdated APIs, over-broad IAM and secrets pasted into prompts. DORA's research on AI-assisted development describes AI as an amplifier: teams with strong testing, small batches and good platforms benefit, while teams with weak foundations see more instability. So measure change fail rate and rework rate alongside any productivity gain. See AI coding assistants in the enterprise.
Career paths and fresher preparation
58. How do DevOps engineer, SRE, platform engineer and Forward Deployed Engineer roles differ?
Answer: They overlap in skills but differ in focus and customer.
| Role | Main focus | Who they serve |
|---|---|---|
| DevOps engineer | CI/CD, automation, IaC, environments, release flow | Product and development teams |
| Site Reliability Engineer | Reliability via SLOs, error budgets, incident response, toil reduction, capacity | End users, through the services |
| Platform engineer | Internal developer platform, golden paths, self-service | Internal developers as customers |
| Forward Deployed Engineer | Engineering inside a customer's environment to integrate, deploy and run software, often AI systems, until it delivers a business outcome | External enterprise customers |
DevOps engineers often move into SRE or platform roles; those who enjoy customer-facing work on AI systems look at FDE roles. See DevOps vs SRE and the DevOps engineer to FDE transition guide.
59. As a fresher without production experience, what project should you build and talk about?
Answer: Build one end-to-end project you understand completely rather than many tutorials. A strong example: a small web service with a database, containerised with a multi-stage Dockerfile; a GitHub Actions pipeline that runs tests, scans, builds and pushes an image tagged with the commit SHA; Terraform that creates the network, a Kubernetes cluster or VM and a managed database; deployment through Helm or Argo CD; Prometheus and Grafana dashboards with one meaningful alert; and a README with an architecture diagram, how to roll back, and what it costs to run. Then break it on purpose: kill a pod, push a failing test, revoke a permission, and write down how you diagnosed each. Real answers to "what went wrong?" beat any certificate.
DevOps scenario based questions
60. The CI pipeline that was green yesterday fails today, and nobody changed the code. What do you do?
Answer: "Nobody changed the code" usually means something outside the repository changed: a dependency, a base image, the runner, a credential or an external service.
What I would check:
- The exact error and which step: dependency resolution, build, test, push or deploy.
- Unpinned dependencies or a floating base image tag that pulled a new version overnight.
- Runner image or tool version changes (hosted runner image updates, new Node or JDK default).
- Expired credentials, tokens or certificates, and registry rate limits on public image pulls.
- Re-run the last green commit: if it fails too, the cause is environmental.
Production consideration: Then remove the class of problem: pin dependencies with lock files, pin base images by digest with automated update PRs, mirror public images into a private registry, and alert on credentials before they expire.
61. A Kubernetes deployment is stuck halfway: new pods are in CrashLoopBackOff and the rollout is not progressing. What do you do?
Answer: First protect users: because a rolling update with sensible settings keeps old pods serving, check whether there is user impact. If there is, or if the fix is not obvious, run kubectl rollout undo (or revert in Git for GitOps), then investigate.
What I would check:
kubectl describe podfor events: image pull errors, OOMKilled, failed probes, scheduling failures.kubectl logs --previousto see why the container exited.- Missing or changed config: a new environment variable, Secret or ConfigMap that does not exist in this environment.
- Readiness or liveness probes that are too aggressive for a slower start.
- Resource limits too low for the new version, or a dependency (database, downstream API) unreachable.
Production consideration: Set progressDeadlineSeconds and have the pipeline fail and roll back automatically when the rollout does not complete, so a stuck rollout never depends on someone noticing.
62. The build takes 40 minutes and developers are complaining. How do you bring it down?
Answer: Measure before changing anything, then target the largest stages first.
What I would check:
- Per-stage timings across recent runs to find the slowest stages and queue time waiting for runners.
- Dependency download time: is there a cache, keyed on the lock file, and is it hit?
- Docker layer caching: are dependency layers rebuilt every time because source is copied too early?
- Tests: can they be sharded in parallel, and are slow end-to-end tests in the PR gate that could run after merge?
- Monorepo: is everything built on every change instead of only affected components?
- Runner size and duplicated work.
Production consideration: Set a target for the PR feedback loop (for example under ten minutes), track it on a dashboard, and treat regressions as bugs.
63. A developer accidentally pushed an AWS access key to a public GitHub repository. What do you do?
Answer: Assume the key is compromised from the moment it was pushed, because automated scanners find public secrets very quickly. Revoke first; cleaning history does not make the key safe.
What I would check:
- Deactivate and delete the key immediately, and create a replacement through the proper secret store if still needed.
- Review CloudTrail for every action taken with that key since the push: new IAM users or keys, launched instances, data access.
- Identify everything that used the key and update it to the new credential or, better, to role-based access.
- Remove the secret from history (git filter-repo or BFG), force-push, knowing forks and clones may still have it.
Production consideration: Prevent the next one: push protection and secret scanning on all repositories, pre-commit hooks, no long-lived access keys for humans or CI (SSO and OIDC instead), and a tested rotation runbook.
64. You are on call and the main customer-facing API starts returning errors at 2 a.m. Walk me through your response.
Answer: Acknowledge the page, assess impact, declare an incident at the right severity, and focus on mitigation before root cause.
What I would check:
- Scope: which endpoints, regions and customers; error rate and latency on the service dashboard.
- What changed recently: deployments, config or flag changes, infrastructure changes, certificate expiry. A recent change is the prime suspect, and rolling it back is the fastest mitigation.
- Dependencies: database connections and latency, downstream APIs, DNS, cloud provider status.
- Saturation: CPU, memory, connection pools, thread pools, queue depth; is traffic unusually high?
- Traces and logs for a failing request to localise the failing hop.
- Escalate early and update stakeholders on a fixed cadence.
Production consideration: Once mitigated, confirm recovery with metrics, hand over cleanly, and schedule a blameless postmortem.
65. Flaky tests are failing the PR gate randomly and developers have started re-running until green. How do you fix this?
Answer: A gate that people bypass by re-running is no longer a gate. The goal is to restore trust quickly without hiding real failures.
What I would check:
- Collect data: which tests fail intermittently, how often, on which runners.
- Common causes: shared state between tests, test order dependence, timing assumptions and fixed sleeps, real network calls, time zones and dates, resource contention on shared runners.
- Quarantine confirmed flaky tests into a non-blocking job with an owner and a deadline, rather than deleting them or adding blanket retries to the gate.
- Fix root causes: isolate data per test, mock external services, replace sleeps with explicit waits, run tests in random order locally to expose dependencies.
Production consideration: Limited automatic retries can be acceptable as a temporary measure if every retry is recorded and reported; silent retries hide genuine race conditions that will also hit production.
66. A canary looked healthy and was promoted, but customers on one mobile app version now report failures. What happened, and what do you do?
Answer: The canary analysis likely measured aggregate metrics, and a failure affecting a small segment, such as an old app version that depends on a response field the new API changed, was diluted below the threshold. Mitigate by rolling back or switching the change off with a flag, then investigate.
What I would check:
- Error rates broken down by client version, region and endpoint, not just overall.
- The API diff for removed or renamed fields, changed types or stricter validation.
- Whether contract tests covered older client versions still in use.
Production consideration: Add segment-level metrics to canary analysis for important dimensions, keep APIs backward compatible with versioning and deprecation windows, and add consumer contract tests for supported client versions.
67. A production deployment ran a database migration that failed halfway. The application is erroring. What do you do?
Answer: Stop the pipeline so nothing else proceeds, assess the database state precisely, and choose the safest path to a consistent state.
What I would check:
- The migration tool's history table: which steps applied, and whether the failed step ran inside a transaction (some databases cannot roll back DDL transactionally).
- Locks: is a long-running migration holding a table lock that is causing the application errors?
- Whether the previous application version works with the current schema; if yes, roll the app back first.
- Backups and point-in-time recovery as the last resort, considering data written since.
Production consideration: Use expand and contract migrations, test migrations against a production-sized copy, set lock timeouts, and separate risky migrations from application releases.
68. A terraform plan in the pipeline shows it will destroy and recreate the production database. What do you do?
Answer: Do not apply. A replace on a stateful resource is a stop-the-line event. Find out which attribute forces replacement.
What I would check:
- The plan output line marked as forcing replacement: often an immutable attribute such as engine version family, subnet group, identifier or encryption setting.
- Whether code was refactored (a resource renamed or moved into a module) without a
movedblock, which makes Terraform think it is a new resource. - Provider version upgrades that changed defaults.
Production consideration: Fix with moved blocks or state moves for refactors, or adjust the change so it is in-place. Protect critical resources with prevent_destroy, deletion protection on the database, and a pipeline policy that blocks any plan destroying tagged stateful resources without explicit senior approval.
69. During an incident someone manually changed a security group and an instance size in the console. A week later an apply reverts them and causes another outage. How do you prevent this?
Answer: The root problem is that emergency changes are not fed back into code, so the code and reality diverged and the next apply "fixed" production back to the broken state.
What I would check:
- Audit logs for manual changes in the period and who made them, without blame.
- Whether scheduled drift detection was running and who receives its output.
Production consideration: Make break-glass access logged and alerted, require a follow-up PR for any manual change before the incident is closed, run daily drift-detection plans that open tickets, and review plans carefully for unexpected changes before applying.
70. The Jenkins controller crashed and will not start, and a release is due today. What do you do?
Answer: Restore CI as an incident in its own right, while assessing whether the release can go through a documented fallback path.
What I would check:
- Controller logs: disk full on
JENKINS_HOME, out of memory, corrupted config, or a plugin update that broke start-up (a very common cause). - If the disk is full, clear old build logs and artifacts and add retention.
- If the instance is unrecoverable, rebuild from Configuration as Code and the latest backup of
JENKINS_HOME. - For the release: use an approved break-glass deployment procedure only if one exists and is audited; otherwise delay the release.
Production consideration: Afterwards, test plugin updates in a staging controller, monitor disk and heap, back up regularly, and practise the rebuild.
71. The monthly cloud bill jumped sharply and finance is asking why. How do you investigate?
Answer: Break the increase down by service, account, region and tag in the cost explorer, find the few line items driving it, and connect each to a change.
What I would check:
- Which services grew: compute, storage, data transfer, NAT gateway processing, logging and monitoring ingestion, managed AI or GPU usage.
- Untagged or orphaned resources: forgotten test clusters, preview environments, unattached volumes, old snapshots.
- Autoscaling that scaled up and never came down, or Kubernetes requests far above usage.
- Whether the increase is legitimate growth, in which case the conversation is unit cost per customer or transaction.
Production consideration: Add budgets and anomaly alerts per account and team, enforce tags in IaC, auto-expire non-production resources, and show cost in pull requests for infrastructure changes.
72. You must standardise CI/CD for fifty teams, each with its own pipeline style. How do you approach it?
Answer: Treat it as a platform product, not a mandate. Teams adopt a golden path when it is easier than their own scripts.
What I would check:
- Interview a sample of teams to find common needs and the pain points of current pipelines.
- Define the non-negotiable controls (security scans, signing, approvals, audit) separately from the flexible parts.
- Build versioned reusable templates or shared libraries covering the common stacks, with sensible defaults and documented extension points.
- Migrate a few willing pilot teams, measure their DORA metrics and feedback, and improve before scaling.
Production consideration: Version templates and roll out changes gradually, because a broken shared template breaks fifty pipelines at once. Enforce the mandatory controls through policy so they hold even for teams that customise.
73. The on-call team receives a large number of pages each week, most of which need no action. How do you fix it?
Answer: Alert fatigue is a reliability risk, because real pages get missed among noise. The fix is a systematic review, not muting everything.
What I would check:
- Export a few weeks of pages: which alerts fire most, and what action was taken for each.
- Delete alerts that never lead to action; downgrade cause-based alerts to tickets or dashboards.
- Replace threshold alerts with SLO burn-rate alerts on user-facing symptoms.
- Fix the underlying causes of the noisiest legitimate alerts, such as a disk that fills every week.
Production consideration: Make page volume per shift a tracked metric reviewed at every on-call handover, and require that every new paging alert has a runbook and an owner.
74. A critical vulnerability is announced in a widely used library, and you have two hundred services. How do you respond?
Answer: Speed depends on preparation: you need to find affected services quickly, prioritise by exposure and patch through the normal pipelines.
What I would check:
- Query SBOMs or the dependency scanning inventory to list every service and image containing the vulnerable versions, including transitive dependencies.
- Prioritise internet-facing and sensitive-data services first.
- Apply temporary mitigations where available: WAF rules, configuration flags that disable the vulnerable feature, network restrictions.
- Raise automated dependency update PRs across repositories, let pipelines test and deploy them, and track progress on a dashboard.
- Rescan running images and check logs for exploitation attempts.
Production consideration: This is where investment in SBOMs, automated dependency updates and fast, trusted pipelines pays off. Teams that deploy small changes often patch far faster.
75. After adopting an AI coding assistant, pull request volume went up but change fail rate also rose. What do you do?
Answer: This is the amplifier effect DORA describes: more code is reaching production faster than the review and test system can absorb. Strengthen the system; do not just ban the tool.
What I would check:
- Which failures increased: missing tests, misconfigured infrastructure, dependency problems, or larger PRs that reviewers skim.
- Test coverage on changed code and whether tests were also generated without real assertions.
- Policy and security scan findings in AI-assisted changes, such as overly broad IAM permissions.
Production consideration: Enforce small PRs, require meaningful tests for new code, add policy as code for IaC, use progressive delivery for risky changes, and track change fail rate and rework rate alongside throughput so productivity claims are tested against stability.
Key takeaways
- DevOps is shared ownership plus fast, safe flow; tools come after culture and measurement.
- Know the current DORA metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate, and that speed and stability rise together.
- Build once, promote the same immutable artifact, and make rollback a tested, automated path that includes database compatibility.
- Choose blue-green, canary, rolling or feature flags based on rollback speed, cost and observability, and be able to explain the trade-off.
- IaC, GitOps and platform engineering exist to make the right way the easy, self-service way, with guardrails as policy.
- In scenarios, lead with impact and mitigation, then investigate what changed, then prevent the class of problem.
- AI helps with code, review and operations, but it amplifies existing practices; keep humans approving write actions and measure stability.
Interview preparation checklist
- Draw your project's pipeline from commit to production on a whiteboard, naming every stage and why it exists.
- Explain CI vs continuous delivery vs continuous deployment, and the five DORA metrics, in under two minutes each.
- Build and deploy one service end to end with GitHub Actions or Jenkins, Docker, Terraform and Kubernetes, then break it and fix it.
- Practise a canary or blue-green rollout and a rollback, including a backward-compatible schema change.
- Set up OIDC from CI to a cloud account so you can explain keyless authentication from experience.
- Write a Terraform configuration with remote state and locking, and explain what forces resource replacement.
- Create a Grafana dashboard and one SLO-based alert with a runbook.
- Prepare three stories: a failure you diagnosed, an automation that saved time, and a disagreement you resolved.
- Rehearse scenario answers in the order: impact, recent change, mitigate, communicate, root cause, prevention.
FAQ
What skills are required for a DevOps engineer role in 2026?
Linux, networking basics, Git, scripting in Bash or Python, one CI/CD tool, Docker, Kubernetes fundamentals, Terraform, one cloud platform in depth, and monitoring. Troubleshooting and communication matter as much.
How should a fresher prepare for a DevOps interview?
Learn Linux, Git and one cloud well, then build one end-to-end project with a pipeline, containers, Terraform and monitoring. Practise explaining it, break it deliberately, and prepare answers on how you diagnosed each failure.
Can a fresher get a DevOps engineer job?
Yes, though many freshers start in related roles such as cloud support, build and release, or junior operations and move into DevOps.
Which CI/CD tool should I learn first?
GitHub Actions is a practical first choice because it is easy to start and widely used. Learn Jenkins concepts as well, since many enterprises and GCCs still run Jenkins, and the pipeline principles transfer between tools.
How are experienced DevOps engineers interviewed differently from freshers?
Experienced candidates get fewer definitions and more design and scenario questions: pipeline architecture, deployment strategies, Terraform state, incident handling, security controls and how they measured improvement with DORA metrics.
Do I need to know Kubernetes for a DevOps interview?
For most roles, yes, at least pods, Deployments, Services, ConfigMaps, Secrets, probes and basic troubleshooting.
Is DevOps a good career with AI changing software development?
AI changes the work rather than removing it. Someone still has to design pipelines, secure supply chains, run AI workloads reliably and govern AI-generated changes, and those skills are in demand across product companies and GCCs.
What is the difference between DevOps and SRE?
DevOps focuses on delivery flow and automation across the lifecycle, while SRE focuses on reliability using SLOs, error budgets, incident response and toil reduction. The skills overlap heavily.
Are certifications necessary for DevOps jobs?
They are not mandatory but can help with shortlisting, especially cloud and Kubernetes certifications. Pair any certification with a project you can explain.
For structured, hands-on preparation, Cloudsoft's DevOps course in Ameerpet and online takes you through CI/CD, containers, Kubernetes, Terraform, GitOps and monitoring through hands-on labs. If you want DevOps alongside AI, ML and security, look at the APEX AI, ML, Cloud and Cyber Security program. And if you are a DevOps engineer ready to deploy enterprise AI systems for customers, the AI Forward Deployed Engineer course (FDE PRO) builds on these pipeline, Kubernetes and observability skills. Classroom beside Ameerpet Metro or live online; call +91 96660 19191 for a free demo.
