Infosys DevOps Engineer Interview Questions: 22 Real-World Scenarios for 5–8 Years of Experience 🚀
Infosys DevOps Engineer Interview Questions: 22 Real-World Scenarios for 5–8 Years of Experience 🚀
Company: Infosys Role: DevOps Engineer Experience: 5–8 Years Interview Mode: Virtual / Offline Interview Date: 17 October 2026
If you have 5–8 years of DevOps experience, interviewers expect more than definitions of Docker, Kubernetes, Terraform, and Jenkins. They want to understand how you troubleshoot production incidents, make infrastructure reliable, automate repetitive tasks, and protect applications without slowing down delivery.
Imagine this scenario: a production application suddenly becomes slow after a deployment. CPU utilization is high, several Kubernetes Pods are restarting, and the monitoring dashboard shows a latency spike. The release pipeline reports success, but customers are experiencing failures.
What do you investigate first? How do you identify the root cause? When do you roll back? And how do you prevent the same incident from happening again?
These are the decisions that separate someone who has used DevOps tools from someone who can operate a production platform.
This article covers 22 scenario-based questions across Linux, Shell Scripting, Docker, Kubernetes, CI/CD, cloud infrastructure, Terraform, observability, DevSecOps, and system design.
DOCUMENT 1: Linux, Docker, Kubernetes, and CI/CD 🛠️
1. How would you troubleshoot high CPU, memory usage, and disk I/O on a Linux server?
🧠 Simple Concept
Start by identifying which resource is saturated, then determine which process or workload is responsible. Avoid restarting services before collecting evidence.
⚙️ How does it work?
Step 1: Check overall system health.
uptime
top
free -h
df -h
iostat -xz 1 5
vmstat 1 5uptimeshows load averages and system uptime.topidentifies CPU-consuming processes.free -hshows available and used memory.df -hidentifies filesystems running out of space.iostathelps identify disk utilization and I/O latency.vmstatshows processes, memory, swapping, and CPU activity.
Install sysstat if iostat is unavailable.
Step 2: Investigate CPU usage.
ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu | headCheck whether CPU consumption comes from application processes, background jobs, excessive threads, or unexpected workloads.
Step 3: Investigate memory pressure.
ps -eo pid,cmd,%mem,rss --sort=-rss | head
free -hCheck swap activity, memory leaks, and OOM-killer messages:
sudo dmesg -T | grep -i -E 'oom|killed process'Step 4: Investigate disk I/O.
iostat -xz 1 5
sudo iotop -oLook for high I/O wait, sustained device utilization, high latency, and processes performing excessive reads or writes.
🏢 Production Example
A Java service suddenly consumes 95% CPU. Instead of rebooting the server, you identify a recently introduced inefficient database query. The application team optimizes the query, CPU utilization returns to normal, and the incident is documented.
🚨 Common Interview Trap
High load average does not automatically mean high CPU usage. Processes waiting on disk I/O can also contribute to load.
🎯 Candidate-Style Answer
“I first establish whether the bottleneck is CPU, memory, disk I/O, or a combination. I correlate system metrics with process-level information and application logs, identify recent changes, and apply the smallest safe corrective action. After recovery, I add monitoring or capacity controls to prevent recurrence.”
2. Write a Bash script to check service health, retry failures, and alert on recovery.
A production health check should distinguish between a service that is healthy, a service that is failing, and a service that has recovered after intervention.
#!/usr/bin/env bash
set -uo pipefail
SERVICE="${1:-nginx}"
MAX_RETRIES=3
SLEEP_SECONDS=5
log() {
echo "$(date '+%F %T') | $*"
}
check_service() {
systemctl is-active --quiet "$SERVICE"
}
for attempt in $(seq 1 "$MAX_RETRIES"); do
if check_service; then
log "Service $SERVICE is healthy."
exit 0
fi
log "Attempt $attempt/$MAX_RETRIES failed."
sleep "$SLEEP_SECONDS"
done
log "Service $SERVICE remains unhealthy. Attempting restart."
if sudo systemctl restart "$SERVICE"; then
sleep 3
if check_service; then
log "RECOVERY ALERT: $SERVICE restarted successfully."
exit 0
fi
fi
log "CRITICAL ALERT: $SERVICE could not be recovered."
exit 1Run it with:
chmod +x service-health.sh
./service-health.sh nginxProduction considerations: Add alert delivery through an approved notification system, log to a central destination, and avoid overlapping executions. Automatic restarts should be restricted to approved services and used with safeguards. A restart can restore service temporarily while hiding the underlying defect.
The script above checks current service health and reports successful recovery. For a reliable production alert, also persist the previous health state so that a recovery notification is sent only when the service transitions from unhealthy to healthy.
3. How do you troubleshoot container crashes, OOMKilled events, and image pull failures?
Start by identifying the failure category instead of assuming every container problem is an application bug.
💻 Commands
docker ps -a
docker logs --tail 100 <container>
docker inspect <container>
docker stats
docker eventsFor Kubernetes workloads:
kubectl get pods -A
kubectl describe pod <pod> -n <namespace>
kubectl logs <pod> -n <namespace> --previous
kubectl get events -n <namespace> --sort-by=.lastTimestamp⚙️ Troubleshooting approach
Container exits immediately: Check entrypoint, command, application logs, environment variables, and exit code.
OOMKilled: Investigate memory consumption, configured memory limits, application leaks, and workload demand.
ImagePullBackOff: Verify the image name, tag, registry availability, credentials, network connectivity, and image pull secrets.
Repeated restarts: Examine startup failures, health probes, dependency availability, and resource constraints.
🏢 Production Example
A container is repeatedly killed because its memory limit is lower than its actual working-set requirement. You validate memory metrics, inspect application behavior, and adjust resource configuration only after confirming the workload’s legitimate needs.
🚨 Common Interview Trap
Increasing memory limits without investigating a memory leak can postpone the next outage rather than fix it.
4. How do multi-stage builds, image layers, and Docker networking affect performance and security?
🧠 Simple Concept
Docker image design affects build speed, deployment time, image size, and the amount of software exposed to attackers.
⚙️ Multi-stage build example
FROM golang:1.24 AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o server .
FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=builder /app/server /server
USER nonroot:nonroot
ENTRYPOINT ["/server"]This illustrates the multi-stage pattern: build tools stay in the builder stage, while the runtime image contains only what the application needs. Validate the language version, runtime compatibility, and base-image availability for your environment.
Image layers: Docker caches layers. Place stable dependency installation steps before frequently changing source files to improve build-cache reuse. Use .dockerignore to prevent unnecessary files and secrets from entering the build context.
Networking:
Bridge networking is commonly used for standalone containers.
Host networking shares the host network namespace and changes isolation characteristics.
Overlay networking can connect workloads across hosts when supported by the platform.
Published ports expose container services through host networking rules.
🔐 Best practices
Pin base images to approved versions or digests.
Scan images for vulnerabilities.
Avoid embedding credentials in Dockerfiles or image layers.
Run as a non-root user where possible.
Keep runtime images minimal.
Use trusted registries and controlled image promotion.
🎯 Candidate-Style Answer
“I optimize the build cache and runtime image separately. Multi-stage builds reduce unnecessary tooling in production, while image scanning, trusted base images, non-root execution, and network isolation reduce risk. I also measure image pull time and build duration rather than assuming a smaller image automatically solves every deployment problem.”
5. A Kubernetes Pod is stuck in Pending, CrashLoopBackOff, or ImagePullBackOff. How do you debug it?
These states represent different failure categories, so the investigation should begin with the Pod’s actual status and events.
💻 Commands
kubectl get pods -n production -o wide
kubectl describe pod <pod> -n production
kubectl get events -n production --sort-by=.lastTimestamp
kubectl logs <pod> -n production --previous
kubectl get nodesPending: Check CPU and memory requests, node capacity, node selectors, affinity, taints, tolerations, and persistent volume claims.
CrashLoopBackOff: Check application logs, startup commands, environment variables, dependency connectivity, exit codes, and liveness probes.
ImagePullBackOff: Verify the image repository, tag, registry credentials, and network access.
🏢 Production Example
A deployment creates new Pods, but they remain Pending. The events show that no node has enough available CPU to satisfy their requests. You review actual workload usage and node capacity, then determine whether to adjust scheduling constraints, right-size requests, or scale the node group.
🚨 Common Interview Trap
Do not randomly delete Pods. A replacement Pod will encounter the same underlying issue if scheduling, configuration, or application behavior remains unchanged.
6. How do requests, limits, HPA, and Cluster Autoscaler work together?
Kubernetes resource management involves two different decisions: how much resource a workload needs and how much infrastructure the cluster needs.
Requests influence scheduling and resource allocation decisions.
Limits constrain resource consumption. CPU limits can cause throttling; memory-limit breaches can lead to OOM kills.
Horizontal Pod Autoscaler (HPA) changes the replica count based on configured metrics.
Cluster Autoscaler adjusts node capacity when supported scheduling conditions indicate that additional nodes are needed or existing nodes can be removed.
Example flow
Traffic increases
|
v
Metrics show higher utilization
|
v
HPA increases Pod replicas
|
v
Pods cannot fit on available nodes
|
v
Cluster Autoscaler adds nodes
|
v
Pods are scheduled and become ReadyThis flow depends on correctly configured metrics, resource requests, compatible node groups, scheduling constraints, and autoscaler support.
Interview trap: HPA does not directly add worker nodes. It adjusts workload replicas. Node scaling is a separate mechanism.
7. How do Helm releases, rollback, and configuration management work?
Helm packages Kubernetes resources into reusable charts. It helps teams manage application deployments consistently across environments.
💻 Commands
helm lint ./my-chart
helm template my-app ./my-chart
helm upgrade --install my-app ./my-chart \
-n production --create-namespace
helm history my-app -n production
helm rollback my-app 2 -n productionUse separate values files or controlled configuration overlays for development, staging, and production.
my-chart/
├── Chart.yaml
├── values.yaml
└── templates/
├── deployment.yaml
├── service.yaml
└── ingress.yamlBefore a release, validate rendered manifests, review configuration changes, and verify readiness probes and rollback procedures.
Production example: A new release introduces an incorrect environment variable. You identify the failed rollout, roll back to a known-good Helm revision, and investigate the configuration change before attempting another deployment.
Remember that Helm rollback does not automatically reverse every external side effect, such as a database schema migration.
8. How would you troubleshoot Service, Ingress, DNS, and NetworkPolicy failures?
Follow the traffic path from the client to the application instead of jumping directly to the Ingress controller.
Client
|
v
Load Balancer / Ingress
|
v
Kubernetes Service
|
v
Service Endpoints
|
v
Pod💻 Commands
kubectl get ingress,svc,endpoints -A
kubectl describe ingress <name> -n <namespace>
kubectl get endpointslice -n <namespace>
kubectl get networkpolicy -n <namespace>
kubectl exec -it <pod> -n <namespace> -- nslookup kubernetes.defaultCheck:
DNS resolution and the destination IP.
Load balancer health and Ingress rules.
Service selectors and target ports.
Whether ready Pods appear in EndpointSlices.
Application listening ports.
Network policies, firewall rules, and security groups where applicable.
TLS certificates and backend protocol settings.
A Service with no ready endpoints may appear to be an Ingress problem, but the actual failure could be a Pod readiness issue.
9. How do you debug a Jenkins, GitHub Actions, or GitLab CI pipeline that suddenly fails?
Start with the first failing stage and compare the failed run with the last successful run.
Investigation checklist
Did the source code change?
Did a dependency or base image change?
Did credentials expire or permissions change?
Is an external repository or package registry unavailable?
Did the runner or build agent run out of disk space?
Are environment variables or protected secrets missing?
Did a tool version change unexpectedly?
💻 Useful commands
git diff <last-good-commit>...HEAD
df -h
free -h
docker system dfFor Jenkins, inspect stage logs, agent health, credential bindings, and workspace state. For GitHub Actions or GitLab CI, inspect job logs, runner availability, permissions, and artifacts.
🏢 Production Example
A previously stable pipeline begins failing during dependency installation. The root cause is an upstream package version change. You restore a known-good dependency lockfile, pin the required versions, and add dependency validation to reduce recurrence.
Interview trap: Retrying a flaky job may restore the pipeline, but it does not explain why the job failed.
10. How do you implement zero-downtime deployments, automated rollback, and approval gates?
Zero downtime requires more than changing a deployment strategy. The application, infrastructure, database, and health checks must all support the transition.
Recommended approach
Build and test an immutable application artifact.
Scan the artifact and dependencies.
Deploy to a small canary group or use blue-green infrastructure.
Wait for readiness and startup checks.
Monitor latency, error rate, saturation, and business metrics.
Promote the release only when defined thresholds are met.
Roll back automatically when agreed failure conditions occur.
Require human approval for high-risk production changes when appropriate.
Deployment strategies:
Rolling: Gradually replaces existing instances or Pods.
Blue-green: Switches traffic between two environments.
Canary: Sends a controlled fraction of traffic to the new version.
Database changes should follow an expand-and-contract approach where possible, allowing old and new application versions to coexist during rollout.
🎯 Candidate-Style Answer
“I use immutable artifacts, automated health checks, staged traffic shifting, and measurable rollback conditions. I also ensure that the previous application version remains compatible with the current database schema. Approval gates are risk-based, not simply extra buttons in the pipeline.”
DOCUMENT 2: Cloud, Terraform, Monitoring, and SRE ☁️
11. How would you design highly available infrastructure across AWS, Azure, or GCP?
The goal is to remove single points of failure and make recovery predictable.
🏗️ Reference architecture
Users
|
DNS / Global Routing
|
Regional Load Balancer
|
+--------+--------+
| |
Zone A Zone B
App Nodes App Nodes
| |
+--------+--------+
|
Managed Database
Multi-zone HA
|
Backups / DR RegionCore design principles:
Deploy application capacity across multiple availability zones.
Use load balancers and health checks to route traffic to healthy targets.
Scale horizontally where the application supports it.
Use managed databases with appropriate high-availability options.
Store durable data outside ephemeral application instances.
Monitor dependencies, capacity, and regional health.
Test backup restoration and disaster recovery.
Define recovery time objective (RTO) and recovery point objective (RPO).
Important distinction: Multi-zone high availability does not automatically provide regional disaster recovery. A regional outage requires a separately designed and tested recovery strategy.
12. How do IAM roles, load balancers, Auto Scaling, and disaster recovery work together?
Think of these components as different layers of a production platform.
IAM roles control which identities and workloads can access cloud resources. Prefer short-lived credentials and workload identities over long-lived access keys.
Load balancers distribute traffic to healthy targets and perform health checks.
Auto Scaling adjusts compute capacity based on defined policies and workload demand.
Disaster recovery provides a way to restore service after a major failure using backups, replicated data, infrastructure automation, and documented recovery procedures.
Production example
An application receives a traffic spike. Auto Scaling increases capacity, the load balancer routes requests to healthy instances, and the application uses a least-privilege role to access its database or object storage. If the primary region becomes unavailable, the disaster recovery plan restores service in the recovery environment.
🚨 Common Interview Trap
Scaling compute does not solve every bottleneck. A database connection limit, storage I/O ceiling, or downstream API limit can remain the actual constraint.
13. How do you manage remote Terraform state, locking, and concurrent runs?
Terraform state records the relationship between configuration and managed infrastructure. Losing or corrupting it can complicate future infrastructure changes.
Recommended controls
Store state in an access-controlled remote backend.
Enable versioning or another supported recovery mechanism.
Use backend-supported state locking where available.
Separate state by environment and ownership boundary.
Restrict production state access.
Run plans and applies through controlled CI/CD workflows.
Avoid concurrent applies against the same state.
💻 Example workflow
terraform init
terraform fmt -check
terraform validate
terraform plan -out=tfplan
terraform apply tfplanThe backend must be configured correctly before running this workflow. Locking behavior depends on the backend and its supported features. For example, an S3 backend can use native lock files in supported Terraform versions and configurations.
🏢 Production Example
Two engineers attempt to modify the same environment simultaneously. The state lock prevents conflicting operations when supported and configured correctly. The team reviews the planned changes, applies them through the approved workflow, and keeps an auditable record of the change.
Interview trap: Never manually edit Terraform state as a routine drift-remediation method. Use documented state commands only when necessary and with a recovery plan.
14. How do you detect and resolve infrastructure drift without causing outages?
Infrastructure drift occurs when the real infrastructure differs from the declared configuration or the recorded state.
Common causes include manual console changes, emergency fixes, external automation, and configuration changes made outside Terraform.
💻 Commands
terraform plan
terraform plan -refresh-onlyUse a normal plan to identify proposed infrastructure changes. A refresh-only plan helps review changes to observed resource state without proposing configuration changes to reconcile infrastructure.
Safe remediation process
Identify the affected resources.
Review audit logs and determine who or what changed them.
Run a fresh plan and inspect the proposed actions.
Decide whether the configuration should adopt the legitimate change or restore the intended configuration.
Check for destructive replacements, downtime, and dependency impacts.
Obtain approval for high-risk changes.
Apply the reviewed plan and verify the outcome.
Production example: Someone manually changes a security group rule during an incident. You confirm the business requirement, update the infrastructure code if the change is legitimate, and remove unauthorized rules through a controlled change.
Do not blindly apply a plan simply because Terraform generated it. Terraform is very capable of carrying out a bad decision with excellent consistency.
15. How would you use Prometheus and Grafana to investigate a production latency spike?
Start with the user-visible symptom, then correlate it with service and infrastructure metrics.
📊 Investigation sequence
Step 1: Confirm the latency increase.
A Prometheus query might be:
histogram_quantile(
0.95,
sum by (le) (
rate(http_request_duration_seconds_bucket[5m])
)
)This calculates an approximate p95 latency from a suitably instrumented histogram. The exact metric name depends on your application.
Step 2: Check error rate.
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))Step 3: Check resource saturation.
Investigate CPU throttling, memory pressure, disk latency, connection pools, database query duration, and request queue depth.
Step 4: Correlate with changes.
Compare the incident timeline with deployments, configuration updates, scaling events, and dependency failures.
🏢 Production Example
P95 latency increases immediately after a release. CPU usage remains normal, but database query duration rises sharply. Distributed traces identify a slow query introduced by the new version. The team rolls back the release and fixes the query.
Interview trap: Average latency can hide serious problems affecting a smaller group of users. Percentiles and error rates often reveal more useful information.
16. How do logs, metrics, and traces integrate through OpenTelemetry?
OpenTelemetry provides vendor-neutral instrumentation and collection for observability data.
Metrics describe aggregate behavior over time, such as request rate, latency, and error counts.
Logs provide timestamped records describing specific events.
Traces follow a request through multiple services and dependencies.
Example architecture
Application
|
v
OpenTelemetry SDK
|
v
OpenTelemetry Collector
|
+------> Metrics Backend
|
+------> Log Backend
|
+------> Trace BackendThe Collector can receive, process, and export telemetry. Depending on the pipeline, it can enrich attributes, batch data, filter sensitive fields, and send telemetry to different backends.
Production example
A customer reports a slow checkout request. Metrics show elevated latency, logs reveal repeated payment-provider timeouts, and a distributed trace identifies the external API call consuming most of the request time.
Best practice: Use trace and correlation IDs to connect relevant telemetry, avoid high-cardinality metric labels, and never export passwords, access tokens, or other sensitive data.
17. How do you define SLIs, SLOs, and error budgets for an SRE team?
These concepts turn reliability from a vague goal into something measurable.
SLI: Service Level Indicator, the metric used to measure reliability.
SLO: Service Level Objective, the target for that metric.
SLA: Service Level Agreement, a commitment to customers that may include consequences for missing the target.
Example
Suppose a service has an SLO of 99.9% successful requests over a 30-day period.
For a simplified request-based model:
Error budget = 100% - SLO
= 0.1%If the service handles one million eligible requests, a 99.9% success objective corresponds to up to approximately 1,000 unsuccessful requests, assuming the SLO is defined using that request-counting model.
How teams use the error budget
Healthy budget: Continue planned delivery while maintaining reliability controls.
Rapid budget consumption: Investigate incidents and prioritize reliability improvements.
Budget exhausted: Consider slowing risky releases and addressing the dominant failure sources.
The exact policy should be agreed upon by engineering and product teams. An error budget is a decision-making mechanism, not a decorative dashboard number.
DOCUMENT 3: Security, DevSecOps, Coding, and System Design 🔐
18. How do you manage secrets securely across CI/CD pipelines and Kubernetes?
Secrets include database passwords, API tokens, signing keys, and cloud credentials. Exposing them can compromise an entire environment.
Recommended approach
Use an approved secrets manager such as AWS Secrets Manager, Azure Key Vault, or Google Cloud Secret Manager.
Use workload identity or short-lived credentials where supported.
Restrict access through least-privilege policies.
Inject secrets at runtime rather than baking them into container images.
Use Kubernetes Secrets with appropriate encryption-at-rest and access controls.
Rotate credentials and audit access.
Mask sensitive values in CI/CD logs.
Never commit secrets to Git.
Production example
A pipeline requires temporary access to a cloud registry. Instead of storing a permanent access key in a repository, the pipeline uses an approved identity federation mechanism to obtain short-lived credentials.
If a secret is exposed, revoke or rotate it immediately, investigate where it was used, and remove the exposure. Deleting the secret from the latest commit does not necessarily remove it from Git history or build artifacts.
19. How would you integrate image scanning, dependency checks, and IaC security scans into CI/CD?
DevSecOps works best when security checks are automated and connected to release decisions.
🔄 Example pipeline
Commit / Pull Request
|
v
Code Quality + Unit Tests
|
v
Dependency / Secret Scanning
|
v
Terraform / IaC Security Scan
|
v
Build Container Image
|
v
Image Vulnerability Scan
|
v
Publish Approved Artifact
|
v
Deploy to Staging
|
v
Smoke Tests + Approval
|
v
Production DeploymentPossible controls include:
Dependency vulnerability scanning.
Secret detection.
Container image scanning.
Infrastructure-as-code policy checks.
Software composition analysis.
Artifact signing and provenance verification.
Runtime security monitoring.
🚨 Common Interview Trap
Failing every build for every low-risk finding can make teams ignore security tooling. Define severity thresholds, exploitability considerations, exceptions with expiry dates, and ownership for remediation. Critical issues should block release according to the organization’s risk policy.
20. Write a Bash script to identify failed services and restart them safely.
This scenario is similar to Question 2, but it emphasizes identifying failed services and applying a safe recovery policy.
The following example checks an explicit allowlist, attempts a restart, and verifies recovery.
#!/usr/bin/env bash
set -uo pipefail
SERVICES=("nginx" "ssh")
LOG_FILE="/var/log/service-recovery.log"
log() {
printf '%s | %s\n' \
"$(date '+%F %T')" "$*" | tee -a "$LOG_FILE"
}
for service in "${SERVICES[@]}"; do
if ! systemctl list-unit-files "${service}.service" \
--no-legend | grep -q "${service}.service"; then
log "SKIP: ${service} unit not found."
continue
fi
if systemctl is-active --quiet "$service"; then
log "OK: ${service} is active."
continue
fi
log "WARNING: ${service} is inactive. Checking restart policy."
if sudo systemctl restart "$service"; then
sleep 3
if systemctl is-active --quiet "$service"; then
log "RECOVERED: ${service} is active."
else
log "CRITICAL: ${service} remains inactive."
fi
else
log "CRITICAL: restart command failed for ${service}."
fi
doneProduction safety checklist
Use an approved allowlist instead of restarting every failed service.
Verify that the script has the minimum required privileges.
Prevent overlapping runs using an appropriate locking mechanism.
Configure log rotation and centralized alerting.
Add restart limits and escalation paths.
Avoid automatically restarting critical stateful services without a service-specific recovery plan.
Important: Validate the service unit lookup, permissions, and logging path on your target Linux distribution before using this script in production. For critical infrastructure, a managed service supervisor and established monitoring system are usually safer than an improvised restart loop.
21. Production latency suddenly increases after deployment. How would you investigate and roll back?
This question tests whether you can make a controlled decision during an incident.
Step 1: Establish impact
Check:
P95 and p99 latency.
HTTP 5xx rate and timeout rate.
Affected regions, endpoints, and customer segments.
Whether the issue affects all traffic or only the new release.
Step 2: Correlate the timeline
Review deployment history, configuration changes, feature flags, database migrations, infrastructure changes, and dependency health.
Step 3: Compare versions
Check whether the previous version has normal latency. Inspect application metrics, traces, logs, resource utilization, and database behavior.
Step 4: Reduce impact
If the new deployment is the likely cause and the impact is material, follow the incident policy to stop promotion and roll back to the last known-good version. If supported, shift traffic away from the affected release or disable a problematic feature flag.
Step 5: Validate recovery
Confirm that latency and error rates return to acceptable levels. Check downstream dependencies and verify that the rollback has not introduced compatibility problems.
Step 6: Prevent recurrence
Write a post-incident review, fix the root cause, improve pre-production testing, and add release guardrails.
🎯 Candidate-Style Answer
“I would first assess customer impact and compare the incident timeline with the deployment. I would use metrics to establish the symptom, logs to identify errors, and traces to locate the slow component. If evidence points to the release and the rollback is safe, I would restore the previous version, verify recovery against our SLOs, and then investigate the root cause.”
Interview trap: Do not spend 45 minutes proving that a deployment caused the outage while customers continue experiencing it. Stabilize the service first, then conduct the deeper investigation.
22. Design a secure, autoscaling Kubernetes platform with high availability, monitoring, and disaster recovery.
This is the kind of system-design question where the interviewer wants to understand your trade-offs, not just hear a list of AWS services.
🏗️ Reference architecture
Users
|
DNS / WAF / CDN
|
Regional Load Balancer
|
Ingress Controller
|
+-------------+-------------+
| |
Zone A Zone B
Worker Nodes Worker Nodes
| |
+-------------+-------------+
|
Kubernetes Services
|
Application Pods
|
Managed Database / Cache
|
Durable Storage / Backups
Observability:
Prometheus + Grafana + Centralized Logs
+ OpenTelemetry + Alerting
Security:
IAM / Workload Identity / RBAC / Secrets
+ Network Policies / Image Scanning
Disaster Recovery:
Versioned Backups + Replication
+ Infrastructure as Code + Recovery TestsLayer 1: Network and access security
Create private subnets for worker nodes and application workloads where appropriate. Expose only approved entry points through load balancers, firewalls, and web application protection.
Use separate environments, least-privilege identity policies, Kubernetes RBAC, and network policies. Keep administrative access controlled and auditable.
Layer 2: Kubernetes high availability
Use a managed Kubernetes control plane where practical. Distribute worker capacity across multiple availability zones, and configure replicas, topology spread constraints, and pod anti-affinity where appropriate.
Use readiness, liveness, and startup probes for their intended purposes. Configure PodDisruptionBudgets to limit voluntary disruptions, while recognizing that they do not prevent every failure.
Layer 3: Autoscaling
Configure resource requests and limits based on measured workload behavior. Use HPA for workload replicas and a compatible node autoscaling mechanism for infrastructure capacity.
Monitor pending Pods, scaling delays, resource saturation, and cluster capacity. Autoscaling is not instantaneous, so critical services may need baseline capacity and sensible headroom.
Layer 4: CI/CD and release safety
Build immutable images, scan them, and promote the same approved artifact across environments.
Deploy through Helm or a controlled GitOps workflow. Use canary or rolling releases, readiness gates, smoke tests, and measurable rollback conditions. Make database migrations backward-compatible whenever possible.
Layer 5: Observability and SRE
Collect metrics, logs, and traces. Build dashboards around latency, traffic, errors, and saturation. Define SLIs and SLOs, route alerts to the responsible team, and avoid alerting on every harmless metric fluctuation.
Layer 6: Disaster recovery
Back up persistent data and Kubernetes configuration that cannot be recreated from source control. Replicate critical data where the recovery objective requires it.
Define RTO and RPO, automate infrastructure recovery using Terraform, document failover procedures, and regularly test restoration. A backup that has never been restored is a hopeful theory, not a proven recovery capability.
🎯 Candidate-Style Answer
“I would design the platform across multiple availability zones with private workloads, least-privilege identity, controlled ingress, and autoscaling. I would use immutable images and automated CI/CD with security checks, health validation, and rollback. Prometheus, Grafana, centralized logs, and OpenTelemetry would support incident investigation. For disaster recovery, I would define RTO and RPO, protect persistent data, automate infrastructure recreation, and regularly test failover and restoration.”
Final Interview Preparation Checklist 🎯
Before your Infosys DevOps interview, practise explaining these scenarios aloud. For each one, focus on the reasoning behind the command or design decision.
Troubleshoot CPU, memory, disk I/O, and Linux processes.
Write and explain Bash health-check and recovery scripts.
Diagnose Docker crashes, OOM kills, and registry failures.
Debug Kubernetes scheduling, probes, networking, and scaling.
Explain Helm releases, rollback, and zero-downtime deployment.
Troubleshoot CI/CD failures using logs and change history.
Design cloud infrastructure for availability and disaster recovery.
Explain Terraform state, locking, drift, and safe remediation.
Use Prometheus, Grafana, logs, and traces to investigate latency.
Define SLOs, error budgets, secrets controls, and security gates.
Walk through a production incident from detection to prevention.
Explain a complete secure Kubernetes platform architecture.
The answer framework that works for experienced DevOps engineers
When you receive a scenario-based question, organize your response into five steps:
1. Detect: What symptom or alert tells you something is wrong?
2. Investigate: Which commands, metrics, logs, or traces will help narrow down the cause?
3. Mitigate: What is the safest action to restore service?
4. Validate: How will you prove that the system is healthy again?
5. Prevent: What automation, monitoring, testing, or design change will reduce the chance of recurrence?
This approach shows practical experience because it connects diagnosis, risk management, recovery, and continuous improvement.
Conclusion
DevOps interviews at the 5–8 year level are not simply tests of whether you remember commands. They evaluate how you handle uncertainty, prioritize production stability, automate safely, and explain the trade-offs behind your decisions.
You do not need to claim that you know everything. You need to demonstrate that you can investigate a problem methodically, communicate clearly, protect customer impact, and learn from incidents.
Remember: A successful pipeline is useful. A platform that remains secure, observable, recoverable, and reliable when the pipeline or application fails is much more valuable. 🚀
Hashtags
#Infosys #DevOpsEngineer #DevOpsInterview #DevOpsInterviewQuestions #Linux #ShellScripting #Docker #Kubernetes #Jenkins #CICD #AWS #Azure #GCP #Terraform #InfrastructureAsCode #Prometheus #Grafana #OpenTelemetry #SRE #DevSecOps #CloudEngineering #PlatformEngineering #ProductionSupport #SiteReliabilityEngineering
Follow Me
If you enjoyed this article and would like more practical DevOps, Cloud, Kubernetes, AWS, Terraform, CI/CD, and Software Engineering content, connect with me on LinkedIn.
Arvind Verma is free today. But if you enjoyed this post, you can tell Arvind Verma that their writing is valuable by pledging a future subscription. You won't be charged unless they enable payments.
© 2026 Arvind Verma
548 Market Street PMB 72296, San Francisco, CA 94104