🚀 Wipro DevOps Interview Questions: 50+ Real-World Questions With Answers
🚀 Wipro DevOps Interview Questions: 50+ Real-World Questions With Answers
Linux, Git, Docker, Kubernetes, Jenkins, AWS, Terraform & Production Troubleshooting
Preparing for a Wipro DevOps interview? Knowing commands is one thing. Explaining how you use them to troubleshoot real production issues is another.
A friend recently attended a Wipro DevOps interview and shared a collection of questions covering Linux, Git, Docker, Kubernetes, Jenkins, AWS, and Terraform.
The questions cover both fundamentals and real-world scenarios. You may be asked to explain chmod 755, recover a deleted Git branch, troubleshoot a Kubernetes Pod stuck in Pending, or investigate a deployment that completed successfully but returns HTTP 502 errors.
In this guide, every question follows a consistent interview-preparation framework:
🧠 Simple Concept
❓ Why do we need it?
⚙️ How does it work?
🏢 Production Example
💻 Command / YAML
🚨 Common Interview Trap
🎯 Candidate-Style Answer
🧠 Memory Trick
These questions are based on a friend’s interview experience, not an official Wipro question paper or a guarantee of future interview questions.
Part 1 of 3: Linux, Git, and Docker
🐧 Linux Interview Questions
Q1. What happens when you run chmod 755?
🧠 Simple Concept: chmod changes file permissions. The number 755 grants the owner read, write, and execute permissions, while the group and others receive read and execute permissions.
❓ Why do we need it? To control who can read, modify, or execute files on a Linux system.
⚙️ How does it work? The permissions are represented by three digits: owner, group, and others. The values are 4 for read, 2 for write, and 1 for execute.
🏢 Production Example: A deployment script cannot run because it lacks execute permission.
💻 Command:
chmod 755 deploy.sh
ls -l deploy.sh🚨 Common Interview Trap: 755 does not mean everyone has full permissions. Only the owner can write to the file.
🎯 Candidate-Style Answer: “The chmod 755 command gives the owner read, write, and execute permissions, while the group and others get read and execute permissions. I use it when a script needs to be executable without allowing every user to modify it.”
🧠 Memory Trick: 7 = 4+2+1; 5 = 4+1.
Q2. How do you find files larger than 1 GB?
🧠 Simple Concept: Linux find searches directories using conditions such as filename, file type, and size.
❓ Why do we need it? To investigate disk usage and identify large logs, backups, or application artifacts.
⚙️ How does it work? -type f selects regular files, while -size +1G searches for files larger than the specified size.
🏢 Production Example: A server runs out of disk space because application logs have grown unexpectedly.
💻 Command:
find /var -type f -size +1G 2>/dev/null🚨 Common Interview Trap: Finding large files is not the same as finding which filesystem is full. Check df -h and du -sh when investigating disk usage.
🎯 Candidate-Style Answer: “I use find with a size condition to locate large files, then inspect the relevant directories and determine whether logs or artifacts can be safely rotated, archived, or removed.”
🧠 Memory Trick: find locates files; du measures directory usage; df checks filesystem capacity.
Q3. How do you identify the top memory-consuming processes?
🧠 Simple Concept: Linux provides process-monitoring commands that show resource consumption.
❓ Why do we need it? To investigate memory pressure and identify potentially problematic processes.
⚙️ How does it work? Sort the process list by memory usage and inspect the largest consumers.
🏢 Production Example: A Linux VM becomes unresponsive because an application is consuming excessive memory.
💻 Command:
ps aux --sort=-%mem | head -n 10
free -h🚨 Common Interview Trap: High memory usage alone does not prove a memory leak. Linux also uses memory for caching.
🎯 Candidate-Style Answer: “I identify the processes consuming the most memory, check overall memory availability, and correlate the findings with application logs and workload changes before taking action.”
🧠 Memory Trick: ps shows processes; free shows memory availability.
Q4. Explain hard links and soft links.
🧠 Simple Concept: A hard link is another directory entry pointing to the same inode. A soft link, also called a symbolic link, points to a pathname.
❓ Why do we need it? Links provide alternative ways to access files and organize filesystem paths.
⚙️ How does it work? Hard links refer to the same underlying file data. Symbolic links refer to a target path and can become broken if the target disappears.
🏢 Production Example: An application uses a symbolic link such as /opt/app/current to point to a selected release directory.
💻 Command:
ln original.txt hardlink.txt
ln -s original.txt softlink.txt
ls -li🚨 Common Interview Trap: Hard links generally cannot cross filesystem boundaries. Symbolic links can cross them, but their targets may become invalid.
🎯 Candidate-Style Answer: “A hard link refers to the same inode as the original file, while a symbolic link points to a path. I commonly use symbolic links to simplify paths to application releases or configuration files.”
🧠 Memory Trick: Hard link = same inode. Soft link = target path.
Q5. What is the difference between grep, awk, and sed?
🧠 Simple Concept: All three process text, but they solve different problems.
❓ Why do we need it? To filter logs, extract fields, and transform text without manually opening large files.
⚙️ How does it work?
grepsearches for matching lines.awkprocesses records and fields.sedperforms stream editing and substitutions.
🏢 Production Example: Search application logs for errors, extract fields from access logs, and transform configuration text in a controlled script.
💻 Commands:
grep "ERROR" application.log
awk '{print $1, $5}' access.log
sed 's/old/new/g' config.txt🚨 Common Interview Trap: These tools overlap in some tasks, but they are not identical. awk is particularly useful for field-based processing.
🎯 Candidate-Style Answer: “I use grep to find matching log entries, awk to extract specific fields, and sed to perform text substitutions or transformations.”
🧠 Memory Trick: Grep searches, awk analyzes fields, sed edits.
Q6. How do you schedule a task using cron?
🧠 Simple Concept: Cron runs scheduled commands on Unix-like systems.
❓ Why do we need it? To automate recurring jobs such as backups, cleanup scripts, and reports.
⚙️ How does it work? A cron expression specifies the minute, hour, day of month, month, and day of week.
🏢 Production Example: Run a backup script every day at 2 AM.
💻 Command:
crontab -eAdd:
0 2 * * * /opt/scripts/backup.sh🚨 Common Interview Trap: Cron jobs may run with a limited environment and different PATH values from an interactive shell. Use absolute paths and log job output.
🎯 Candidate-Style Answer: “I configure a cron expression to schedule the script, use absolute paths, capture logs, and verify that the job runs successfully under the intended user.”
🧠 Memory Trick: Minute, hour, day, month, weekday.
🌿 Git Interview Questions
Q7. What are Git cherry-pick and Git squash?
🧠 Simple Concept: Cherry-pick applies a particular commit to the current branch. Squash combines multiple commits into one.
❓ Why do we need it? To move specific fixes between branches and maintain cleaner commit history.
⚙️ How does it work? Cherry-pick replays a commit’s changes. Interactive rebase allows commits to be combined.
🏢 Production Example: A critical bug fix is available on a development branch, but the release branch needs only that fix.
💻 Commands:
git cherry-pick <commit-hash>
git rebase -i HEAD~3🚨 Common Interview Trap: Squashing and cherry-picking can produce conflicts. Rewriting shared history can disrupt collaborators.
🎯 Candidate-Style Answer: “I use cherry-pick to apply a specific commit without merging an entire branch. I use interactive rebase to squash related commits before merging, when rewriting the branch history is appropriate.”
🧠 Memory Trick: Cherry-pick selects a commit; squash combines commits.
Q8. How do you recover a deleted Git branch?
🧠 Simple Concept: Git’s reflog records recent changes to local references.
❓ Why do we need it? To recover commits after accidental branch deletion or other reference changes.
⚙️ How does it work? Locate the commit where the deleted branch pointed, then recreate the branch from that commit.
🏢 Production Example: A developer deletes a feature branch before merging its changes.
💻 Commands:
git reflog
git branch recovered-branch <commit-hash>🚨 Common Interview Trap: Reflog is local and entries eventually expire. Recovery is not guaranteed indefinitely.
🎯 Candidate-Style Answer: “I inspect the reflog to identify the last relevant commit, recreate the branch at that commit, and verify its history before continuing.”
🧠 Memory Trick: Reflog remembers recent reference movements.
Q9. Explain Git tags and their use cases.
🧠 Simple Concept: Tags identify specific commits, often representing software releases.
❓ Why do we need it? To associate deployments and release artifacts with a known source revision.
⚙️ How does it work? A tag references a commit. Annotated tags also include metadata and a message.
🏢 Production Example: A CI/CD pipeline builds and publishes an application version associated with v1.2.0.
💻 Commands:
git tag -a v1.2.0 -m "Release 1.2.0"
git push origin v1.2.0🚨 Common Interview Trap: Creating a local tag does not automatically push it to the remote repository.
🎯 Candidate-Style Answer: “I use tags to mark release commits and help trace deployed versions back to source code. I generally prefer annotated tags for release records.”
🧠 Memory Trick: Branches move; tags mark a point.
Q10. How do you revert a merge commit?
🧠 Simple Concept: git revert creates a new commit that reverses changes introduced by an earlier commit.
❓ Why do we need it? To undo a problematic merge while preserving shared history.
⚙️ How does it work? The -m option identifies the mainline parent against which the merge should be reverted.
🏢 Production Example: A feature merge introduces a regression after deployment.
💻 Command:
git revert -m 1 <merge-commit-hash>🚨 Common Interview Trap: Parent 1 is not automatically correct for every merge. Inspect the merge’s parent order first.
🎯 Candidate-Style Answer: “I identify the merge commit and determine the correct mainline parent. I then use git revert -m to create a new commit that reverses the merge’s changes without rewriting shared history.”
🧠 Memory Trick: Revert preserves history; reset moves a reference.
Q11. How do you compare changes between two branches?
🧠 Simple Concept: git diff compares file changes, while git log compares commit history.
❓ Why do we need it? To review changes before merging or deploying code.
⚙️ How does it work? Git compares branch tips or uses a common ancestor to determine which changes were introduced.
🏢 Production Example: Review Terraform changes before approving an infrastructure pull request.
💻 Commands:
git diff main...feature-branch
git log main..feature-branch --oneline🚨 Common Interview Trap: git diff A...B and git diff A B use different comparison points.
🎯 Candidate-Style Answer: “I use three-dot diff to review changes introduced on a feature branch since divergence, and Git log to inspect commits that are not present in the base branch.”
🧠 Memory Trick: Diff compares content; log compares history.
🐳 Docker Interview Questions
Q12. Explain Docker volumes and bind mounts.
🧠 Simple Concept: Both provide storage outside a container’s writable layer.
❓ Why do we need it? To preserve data or provide files to containers independently of their lifecycle.
⚙️ How does it work? Docker volumes are managed by Docker. Bind mounts connect a specific host path to a container path.
🏢 Production Example: Use a volume for persistent application data and a read-only bind mount for configuration files.
💻 Commands:
docker volume create app-data
docker run -v app-data:/data myapp:latest🚨 Common Interview Trap: Container data stored only in the writable layer can disappear when the container is removed. Bind mounts also expose host paths, so permissions matter.
🎯 Candidate-Style Answer: “I use volumes for Docker-managed persistent storage and bind mounts when I need to expose a specific host directory or file to a container.”
🧠 Memory Trick: Volume = Docker-managed. Bind mount = host path.
Q13. What is the difference between ENTRYPOINT and CMD?
🧠 Simple Concept: Both influence the command executed when a container starts.
❓ Why do we need it? To define a predictable application startup command while allowing configurable defaults.
⚙️ How does it work? ENTRYPOINT defines the main executable. CMD provides default arguments or a default command, depending on how the Dockerfile is written.
🏢 Production Example: Run a Python application with a default port that can be overridden when starting the container.
💻 Dockerfile:
ENTRYPOINT ["python", "app.py"]
CMD ["--port", "8080"]🚨 Common Interview Trap: The interaction differs between shell and exec forms. With an exec-form entrypoint, arguments supplied to docker run replace the default CMD arguments.
🎯 Candidate-Style Answer: “I use ENTRYPOINT to define the primary executable and CMD to supply defaults that can be overridden at runtime.”
🧠 Memory Trick: ENTRYPOINT defines the executable; CMD supplies defaults.
Q14. What is a Docker overlay network?
🧠 Simple Concept: An overlay network connects containers across multiple Docker hosts.
❓ Why do we need it? To support communication between services distributed across hosts in a Docker Swarm environment.
⚙️ How does it work? Docker creates a virtual network spanning participating hosts, allowing connected services to communicate through that network.
🏢 Production Example: Multiple services running on separate Swarm nodes communicate through a shared overlay network.
💻 Command:
docker network create --driver overlay app-networkThis command requires a Swarm-enabled Docker environment.
🚨 Common Interview Trap: Docker overlay networking is not the same as Kubernetes CNI networking.
🎯 Candidate-Style Answer: “An overlay network enables communication between containers on different Docker hosts. It is commonly used in Docker Swarm deployments.”
🧠 Memory Trick: Overlay connects Docker hosts at the network layer.
Q15. How do you scan Docker images for vulnerabilities?
🧠 Simple Concept: Image scanning identifies known vulnerabilities in operating-system packages and application dependencies.
❓ Why do we need it? To detect security issues before images are released or deployed.
⚙️ How does it work? A scanner compares discovered package versions against vulnerability databases.
🏢 Production Example: A CI pipeline identifies a vulnerable system library in an application image.
💻 Command:
trivy image myapp:latest🚨 Common Interview Trap: A scan is not a guarantee that an image is secure. Results depend on scanner coverage, package detection, database freshness, and policy configuration.
🎯 Candidate-Style Answer: “I integrate image scanning into CI/CD, define severity-based policies, review available fixes, and prevent releases that violate our agreed security requirements.”
🧠 Memory Trick: Scan, assess, fix, rescan.
Q16. How do you troubleshoot an out-of-memory container?
🧠 Simple Concept: A container can be terminated when it exceeds an applicable memory limit or the host experiences memory pressure.
❓ Why do we need it? To identify why a container is restarting or being killed.
⚙️ How does it work? Inspect container state, resource usage, logs, memory limits, and application behavior.
🏢 Production Example: A Java service repeatedly restarts under heavy traffic because its memory usage exceeds the container limit.
💻 Commands:
docker ps -a
docker stats
docker inspect <container-name>
docker logs <container-name>🚨 Common Interview Trap: Increasing the memory limit without investigating the cause can hide a memory leak or an application configuration problem.
🎯 Candidate-Style Answer: “I check the container’s termination state, inspect resource usage and limits, review logs, and investigate application memory behavior before deciding whether to tune the application or change the resource allocation.”
🧠 Memory Trick: State, usage, limits, logs, root cause.
Part 2 of 3: Kubernetes, Jenkins, and CI/CD
☸️ Kubernetes Interview Questions
Q17. What is the difference between a ReplicaSet and a ReplicationController?
🧠 Simple Concept: Both maintain a desired number of pod replicas. ReplicaSet supports more expressive label selectors.
❓ Why do we need it? To maintain application availability when pods fail or need replacement.
⚙️ How does it work? The controller compares the desired replica count with the actual matching pods and creates or removes pods as needed.
🏢 Production Example: A Deployment manages a ReplicaSet that maintains three application replicas.
💻 Command:
kubectl get replicasets
kubectl get replicationcontrollers🚨 Common Interview Trap: ReplicaSets are not usually managed directly for application rollouts. Deployments manage ReplicaSets and provide declarative rollout functionality.
🎯 Candidate-Style Answer: “ReplicationController is the older mechanism for maintaining pod replicas. ReplicaSet provides similar functionality with more expressive selectors and is normally managed by a Deployment.”
🧠 Memory Trick: Deployment manages ReplicaSets; ReplicaSets maintain pods.
Q18. Explain init containers.
🧠 Simple Concept: Init containers perform setup tasks before application containers start.
❓ Why do we need it? To prepare files, configuration, or prerequisites before launching the main application.
⚙️ How does it work? Regular init containers run sequentially and must complete successfully before the application containers start.
🏢 Production Example: An init container prepares a configuration file on a shared volume before the application starts.
💻 YAML:
initContainers:
- name: setup
image: busybox:1.36
command: ["sh", "-c", "echo setup-complete"]🚨 Common Interview Trap: An init container that fails repeatedly prevents the application containers from starting.
🎯 Candidate-Style Answer: “I use init containers for prerequisite tasks that must finish before the main application begins running.”
🧠 Memory Trick: Init first, application second.
Q19. What are sidecar containers?
🧠 Simple Concept: A sidecar is a supporting container running alongside an application container in the same Pod.
❓ Why do we need it? To separate supporting functions from the main application.
⚙️ How does it work? Containers in a Pod share the Pod network namespace and can share configured volumes.
🏢 Production Example: A proxy container provides traffic-handling functionality alongside the application.
💻 Command:
kubectl get pods
kubectl describe pod <pod-name>Use these commands to inspect the Pod’s containers and configuration.
🚨 Common Interview Trap: A sidecar is not simply any container in the cluster. It is associated with the main application Pod and provides a supporting function.
🎯 Candidate-Style Answer: “A sidecar runs alongside the main application container and handles supporting responsibilities such as proxying, telemetry, or log processing.”
🧠 Memory Trick: Main container does the work; sidecar supports it.
Q20. How do you roll back a failed Kubernetes deployment?
🧠 Simple Concept: A rollback returns a Deployment to a previous revision.
❓ Why do we need it? To restore a known-good version after a problematic release.
⚙️ How does it work? Kubernetes records rollout revisions when the relevant history is retained. The rollout undo command restores an earlier revision.
🏢 Production Example: A new application release causes errors, so the team restores the previous healthy revision.
💻 Commands:
kubectl rollout status deployment/myapp
kubectl rollout history deployment/myapp
kubectl rollout undo deployment/myapp🚨 Common Interview Trap: Rolling back application code may not reverse database schema changes or external side effects.
🎯 Candidate-Style Answer: “I inspect rollout status and history, identify a suitable earlier revision, perform the rollback, verify pod health, and investigate the root cause.”
🧠 Memory Trick: Inspect, undo, verify.
Q21. Explain Pod Disruption Budget (PDB).
🧠 Simple Concept: A PDB defines availability requirements for selected pods during supported voluntary disruptions.
❓ Why do we need it? To reduce the risk of disrupting too many replicas during operations such as node maintenance.
⚙️ How does it work? Kubernetes uses the PDB to determine whether certain voluntary evictions can proceed without violating the configured availability requirement.
🏢 Production Example: A service has three replicas and must retain at least two available during a node drain.
💻 YAML:
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: myapp-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: myapp🚨 Common Interview Trap: A PDB does not prevent all outages or all involuntary disruptions.
🎯 Candidate-Style Answer: “I configure a PDB to protect the required number of available replicas during supported voluntary disruptions, while also designing appropriate replication and failure recovery.”
🧠 Memory Trick: PDB protects availability during voluntary disruption.
Q22. What is an Ingress Controller?
🧠 Simple Concept: An Ingress Controller implements HTTP and HTTPS routing rules for Kubernetes applications.
❓ Why do we need it? To route external requests to appropriate Kubernetes services based on hostnames or URL paths.
⚙️ How does it work? The controller watches relevant Kubernetes resources and configures the routing implementation it manages.
🏢 Production Example: Requests to api.example.com are routed to an API service while requests to app.example.com reach the frontend service.
💻 Commands:
kubectl get ingress -A
kubectl get pods -A🚨 Common Interview Trap: Creating an Ingress resource does not guarantee routing. A suitable controller and its required configuration must exist.
🎯 Candidate-Style Answer: “An Ingress resource describes routing rules, while the Ingress Controller implements those rules and directs traffic to Kubernetes services.”
🧠 Memory Trick: Ingress defines; controller implements.
Q23. Explain ClusterIP, NodePort, and LoadBalancer.
🧠 Simple Concept: These are Kubernetes Service types that expose applications in different ways.
❓ Why do we need it? To provide stable network access to changing sets of pods.
⚙️ How does it work?
ClusterIP provides cluster-internal access.
NodePort exposes a service through a port on cluster nodes.
LoadBalancer requests an external load-balancing implementation.
🏢 Production Example: An internal API uses ClusterIP, while an internet-facing application uses a cloud-integrated LoadBalancer service.
💻 Command:
kubectl get services
kubectl describe service <service-name>🚨 Common Interview Trap: A LoadBalancer service’s actual behavior depends on the cluster and infrastructure integration. It does not automatically guarantee secure public access.
🎯 Candidate-Style Answer: “I choose the Service type based on whether the application needs internal access, node-level exposure, or integration with an external load balancer.”
🧠 Memory Trick: Cluster, node, external load balancer.
Q24. How do you troubleshoot a Pending Pod?
🧠 Simple Concept: A Pending Pod has not reached the stage where it is successfully running as expected. It may be waiting for scheduling or resource setup.
❓ Why do we need it? To determine why Kubernetes cannot place or prepare the workload.
⚙️ How does it work? Inspect pod events, scheduling constraints, resource requests, and storage dependencies.
🏢 Production Example: A Pod remains Pending because no node has enough available CPU to satisfy its resource request.
💻 Commands:
kubectl describe pod <pod-name>
kubectl get events --sort-by=.lastTimestamp
kubectl get nodes🚨 Common Interview Trap: Not every Pending Pod has a CPU or memory problem. Unbound PVCs, affinity, taints, and other scheduling constraints can also be responsible.
🎯 Candidate-Style Answer: “I inspect the Pod events first, then check resource availability, node selectors, affinity, taints, tolerations, and storage claims based on the reported reason.”
🧠 Memory Trick: Events first, hypothesis second.
Q25. How do you debug DNS issues inside Kubernetes?
🧠 Simple Concept: Kubernetes DNS resolves service names to the corresponding service addresses.
❓ Why do we need it? Applications commonly connect to other services by DNS name rather than hardcoded IP address.
⚙️ How does it work? A cluster DNS service, commonly CoreDNS, answers queries based on cluster DNS configuration and service records.
🏢 Production Example: A frontend cannot resolve the DNS name of its backend service.
💻 Commands:
kubectl get svc -A
kubectl get pods -n kube-system
nslookup kubernetes.default.svc.cluster.localRun the DNS test from a suitable diagnostic Pod. Check CoreDNS health, Pod DNS configuration, service names, and relevant network policies.
🚨 Common Interview Trap: A DNS failure and a connection refusal are different problems. DNS may resolve correctly while the destination service remains unreachable.
🎯 Candidate-Style Answer: “I test resolution from the affected namespace, inspect the Pod’s DNS configuration, check CoreDNS health, and then investigate service endpoints and network connectivity.”
🧠 Memory Trick: Resolve first, connect second.
Q26. Explain etcd and its role in Kubernetes.
🧠 Simple Concept: etcd is a distributed key-value store that persists Kubernetes cluster state.
❓ Why do we need it? The control plane needs durable storage for cluster configuration and resource state.
⚙️ How does it work? The Kubernetes API server reads and writes cluster state through etcd.
🏢 Production Example: An etcd availability issue can affect the control plane’s ability to process cluster state changes.
💻 Commands:
kubectl get componentstatuses
kubectl get nodesThese commands offer limited cluster-level checks and do not directly prove etcd health. For etcd itself, use the appropriate health and monitoring procedures for your cluster architecture.
🚨 Common Interview Trap: Kubernetes component-health commands are not a universal etcd diagnostic method. Managed clusters may restrict direct access to etcd.
🎯 Candidate-Style Answer: “etcd stores Kubernetes cluster state and is critical to control-plane reliability. I follow the cluster-specific monitoring, backup, and recovery procedures to protect it.”
🧠 Memory Trick: API server manages; etcd stores.
Q27. What is a service mesh? Have you worked with Istio?
🧠 Simple Concept: A service mesh provides infrastructure for managing service-to-service communication.
❓ Why do we need it? It can provide traffic management, mutual TLS, telemetry, and policy enforcement across services.
⚙️ How does it work? Depending on the architecture, mesh components and proxies handle or control traffic between participating services.
🏢 Production Example: Istio can help enforce service-to-service encryption and manage traffic routing for selected workloads.
💻 Commands:
kubectl get pods -n istio-system
kubectl get pods -A🚨 Common Interview Trap: Do not claim hands-on Istio experience if you have only studied it. Service mesh features and architectures also vary.
🎯 Candidate-Style Answer: “A service mesh manages communication between services and can provide traffic control, security, and telemetry. If using Istio, I would explain the specific configuration and operational experience I have rather than claiming features I haven’t implemented.”
🧠 Memory Trick: Mesh = traffic, security, observability.
Part 3 of 3: Jenkins, AWS, Terraform, and Scenario-Based Questions
⚙️ Jenkins / CI-CD Interview Questions
Q28. How do you trigger Jenkins jobs automatically?
🧠 Simple Concept: Jenkins jobs can be triggered by source-control events, schedules, upstream jobs, or external automation.
❓ Why do we need it? To automate build, test, security scan, and deployment workflows.
⚙️ How does it work? An event or schedule starts the pipeline, which executes the configured stages.
🏢 Production Example: A source-control webhook triggers tests when a pull request is opened.
💻 Example: Configure an appropriate repository webhook and Jenkins trigger, or use a scheduled pipeline when time-based execution is required.
🚨 Common Interview Trap: Polling a repository and receiving webhooks are different triggering mechanisms.
🎯 Candidate-Style Answer: “I use webhooks for event-driven pipelines where possible, scheduled triggers for recurring tasks, and upstream triggers when one pipeline depends on another.”
🧠 Memory Trick: Event, schedule, upstream, external trigger.
Q29. What are Shared Libraries in Jenkins?
🧠 Simple Concept: Shared Libraries provide reusable pipeline code for multiple Jenkins jobs.
❓ Why do we need it? To reduce duplication and standardize CI/CD practices across repositories.
⚙️ How does it work? Jenkins loads library code from a configured source and makes supported functions available to pipelines.
🏢 Production Example: Multiple repositories reuse a standard build, Trivy scan, and deployment function.
💻 Example:
@Library('company-pipeline-library') _The library must be configured in Jenkins, and the referenced name must match that configuration.
🚨 Common Interview Trap: A shared library is not automatically secure or reliable. Changes can affect many pipelines, so versioning and review matter.
🎯 Candidate-Style Answer: “I use Shared Libraries to standardize repeated pipeline logic and maintain reusable functions with version control, testing, and review.”
🧠 Memory Trick: One library, many pipelines.
Q30. How do you store credentials securely in Jenkins?
🧠 Simple Concept: Jenkins Credentials provides a controlled mechanism for storing and using secrets.
❓ Why do we need it? To avoid exposing passwords, tokens, and keys in source code or pipeline logs.
⚙️ How does it work? Pipelines reference stored credentials through supported credential-binding mechanisms.
🏢 Production Example: A pipeline requires cloud access to deploy infrastructure.
💻 Example:
withCredentials([string(
credentialsId: 'deployment-token',
variable: 'DEPLOY_TOKEN'
)]) {
sh 'deploy-command'
}This illustrates the binding pattern. The actual deployment command and credential type must match the environment.
🚨 Common Interview Trap: Masking does not guarantee that a secret cannot leak. Avoid printing credentials, use least privilege, and prefer short-lived credentials where possible.
🎯 Candidate-Style Answer: “I store secrets in Jenkins Credentials, restrict access, avoid logging them, rotate them regularly, and use short-lived identities where supported.”
🧠 Memory Trick: Store securely, scope narrowly, never print.
Q31. Explain Blue-Green and Canary deployments.
🧠 Simple Concept: Both strategies reduce the risk of releasing a new application version.
❓ Why do we need it? To validate releases and limit the impact of deployment failures.
⚙️ How does it work?
Blue-Green maintains two environments and switches traffic between them.
Canary gradually exposes a new version to a subset of traffic.
🏢 Production Example: A team deploys a new API version to a small traffic percentage before gradually increasing exposure.
💻 Example: Use an appropriate load balancer, ingress controller, or progressive-delivery system to manage traffic.
🚨 Common Interview Trap: Neither strategy automatically guarantees rollback safety. Database compatibility, session behavior, and external side effects still matter.
🎯 Candidate-Style Answer: “Blue-Green switches between environments, while Canary progressively shifts traffic to the new version. I choose based on risk, architecture, and the ability to monitor and recover.”
🧠 Memory Trick: Blue-Green switches; Canary gradually exposes.
Q32. How do you implement approval gates in CI/CD?
🧠 Simple Concept: An approval gate pauses a pipeline until an authorized person approves a stage.
❓ Why do we need it? To introduce controlled authorization before sensitive actions such as production deployments.
⚙️ How does it work? The pipeline waits for an approval decision before continuing.
🏢 Production Example: A production release requires approval after tests and security scans pass.
💻 Jenkins example:
stage('Production Approval') {
steps {
input message: 'Approve production deployment?'
}
}🚨 Common Interview Trap: An approval prompt alone is not a complete governance mechanism. Permissions, timeouts, auditability, and separation of duties matter.
🎯 Candidate-Style Answer: “I add an approval stage after automated validation and configure the right permissions and audit controls before production deployment.”
🧠 Memory Trick: Validate first, approve second, deploy third.
☁️ AWS Interview Questions
Q33. Explain NAT Gateway and Internet Gateway.
🧠 Simple Concept: An Internet Gateway supports internet connectivity for a VPC, while a NAT Gateway enables private-subnet resources to initiate supported outbound connections.
❓ Why do we need it? To separate public-facing infrastructure from resources that should not accept unsolicited internet connections.
⚙️ How does it work? Route tables direct traffic through the appropriate gateway. A NAT Gateway normally resides in a public subnet and uses an Internet Gateway for internet-bound traffic.
🏢 Production Example: Private application instances download updates without receiving direct inbound internet connections through the NAT path.
💻 AWS CLI example:
aws ec2 describe-route-tables🚨 Common Interview Trap: Creating a NAT Gateway alone does not provide connectivity. Routes, subnet configuration, security rules, and network ACLs also matter.
🎯 Candidate-Style Answer: “An IGW provides a VPC’s internet gateway integration, while a NAT Gateway allows private resources to initiate outbound connections without direct unsolicited inbound access through that NAT path.”
🧠 Memory Trick: IGW = internet routing; NAT = outbound connectivity for private resources.
Q34. How does Route 53 perform health checks?
🧠 Simple Concept: Route 53 health checks evaluate configured endpoints or other health checks.
❓ Why do we need it? To support health-aware DNS routing and failover.
⚙️ How does it work? Health-check results can influence routing decisions when used with compatible routing policies.
🏢 Production Example: A failover routing policy directs DNS responses toward a secondary endpoint when the primary endpoint is unhealthy.
💻 AWS CLI example:
aws route53 list-health-checks🚨 Common Interview Trap: DNS failover is not instantaneous for every client. DNS caching and TTLs affect how quickly clients observe changes.
🎯 Candidate-Style Answer: “Route 53 health checks monitor configured endpoints or health-check conditions, and compatible routing policies can use the results to support failover.”
🧠 Memory Trick: Check health, influence DNS routing.
Q35. Explain cross-account IAM access.
🧠 Simple Concept: Cross-account access allows an identity in one AWS account to access resources in another account through explicitly configured trust and permissions.
❓ Why do we need it? To separate environments and centralize deployment or administrative access.
⚙️ How does it work? A source identity assumes a role in the target account using AWS STS, provided the trust policy and identity permissions allow it.
🏢 Production Example: A central CI/CD account deploys to separate development and production accounts using dedicated roles.
💻 Command:
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/DeploymentRole \
--role-session-name ci-deploymentUse your actual account ID and role name.
🚨 Common Interview Trap: A target role’s trust policy and its permissions policy serve different purposes. Both must be configured correctly, along with source-side permissions.
🎯 Candidate-Style Answer: “I configure a trusted target role, grant the source identity permission to assume it, and apply least-privilege permissions to the role.”
🧠 Memory Trick: Trust permits assumption; permissions govern actions.
Q36. How do you secure S3 buckets?
🧠 Simple Concept: S3 security combines identity permissions, bucket policies, encryption, and access controls.
❓ Why do we need it? To protect sensitive files and prevent unauthorized access or modification.
⚙️ How does it work? AWS evaluates applicable identity and resource policies alongside other access controls.
🏢 Production Example: A bucket stores deployment artifacts and should only be accessible to approved CI/CD identities.
💻 AWS CLI example:
aws s3api get-public-access-block \
--bucket my-example-bucket🚨 Common Interview Trap: Encryption alone does not prevent unauthorized access. Public access controls and least-privilege policies remain essential.
🎯 Candidate-Style Answer: “I enable Block Public Access where appropriate, apply least-privilege policies, enforce secure transport, configure encryption, and monitor access according to the data’s sensitivity.”
🧠 Memory Trick: Access, encryption, transport, monitoring.
Q37. How do you achieve high availability in AWS?
🧠 Simple Concept: High availability reduces service disruption by designing for failures.
❓ Why do we need it? To keep applications accessible when individual components or infrastructure fail.
⚙️ How does it work? Architecture may use multiple Availability Zones, health checks, load balancing, redundancy, scaling, and tested recovery procedures.
🏢 Production Example: An application runs across multiple Availability Zones behind a load balancer, with health checks removing unhealthy targets.
💻 Example: Review the health of load balancer targets and the application’s deployment distribution across Availability Zones.
🚨 Common Interview Trap: Deploying multiple instances in the same failure domain does not protect against every infrastructure failure.
🎯 Candidate-Style Answer: “I identify the failures the application must tolerate, remove single points of failure, deploy across suitable failure domains, and validate recovery through monitoring and testing.”
🧠 Memory Trick: Redundancy plus detection plus recovery.
🏗️ Terraform Interview Questions
Q38. What are Terraform modules and workspaces?
🧠 Simple Concept: Modules organize reusable configuration. Workspaces provide separate state instances for the same configuration.
❓ Why do we need it? To reduce duplication and manage infrastructure instances.
⚙️ How does it work? A module groups Terraform resources and inputs. Workspaces allow the same configuration to be associated with different state instances.
🏢 Production Example: A reusable network module provisions consistent VPC components for multiple environments.
💻 Commands:
terraform workspace new dev
terraform workspace select dev🚨 Common Interview Trap: Workspaces are not a complete security boundary. Strongly isolated environments may need separate configurations, state backends, credentials, and access controls.
🎯 Candidate-Style Answer: “I use modules to reuse infrastructure patterns and workspaces where separate state instances are appropriate. For strict production isolation, I also evaluate backend and access-control boundaries.”
🧠 Memory Trick: Modules reuse configuration; workspaces separate state instances.
Q39. What is the difference between count and for_each?
🧠 Simple Concept: Both create multiple instances of a resource.
❓ Why do we need it? To manage repeated infrastructure without duplicating resource blocks.
⚙️ How does it work? count uses numeric indexes, while for_each identifies instances using map keys or set elements.
🏢 Production Example: Manage a known list of named environments with for_each to make resource identity easier to understand.
💻 Example:
resource "aws_s3_bucket" "example" {
for_each = toset(["dev", "test"])
bucket = "example-${each.key}"
}🚨 Common Interview Trap: Changing a count list can shift instance indexes and cause unexpected changes. Review the plan before applying either approach.
🎯 Candidate-Style Answer: “I use count for index-based repetition and for_each when each resource should have a stable, meaningful key.”
🧠 Memory Trick: Count = index; for_each = key.
Q40. What is the Terraform lifecycle block?
🧠 Simple Concept: The lifecycle block controls selected behaviors during resource changes.
❓ Why do we need it? To influence replacement order, guard against certain deletions, and manage selected change behavior.
⚙️ How does it work? Lifecycle arguments tell Terraform how to handle specific changes during planning and applying.
🏢 Production Example: A critical resource uses prevent_destroy to help guard against accidental destruction while the lifecycle rule remains in configuration.
💻 Example:
lifecycle {
prevent_destroy = true
}🚨 Common Interview Trap: prevent_destroy is not a backup, and removing the lifecycle rule can remove that safeguard.
🎯 Candidate-Style Answer: “I use lifecycle rules when their behavior matches the resource’s operational requirements, but I still rely on plan reviews, permissions, and recovery procedures.”
🧠 Memory Trick: Lifecycle controls how changes are handled.
Q41. How do you import existing AWS resources into Terraform?
🧠 Simple Concept: Terraform import associates an existing infrastructure resource with a Terraform resource address in state.
❓ Why do we need it? To bring manually created infrastructure under Terraform management.
⚙️ How does it work? Define the corresponding resource configuration, import the resource, then reconcile configuration with the actual infrastructure.
🏢 Production Example: A manually created S3 bucket must be managed through the infrastructure repository.
💻 Command:
terraform import aws_s3_bucket.example my-existing-bucket
terraform plan🚨 Common Interview Trap: Importing a resource does not automatically create a complete configuration or guarantee that the next plan is safe.
🎯 Candidate-Style Answer: “I define the resource block, import the existing resource using its provider-specific identifier, and review the plan until configuration and state match the intended infrastructure.”
🧠 Memory Trick: Define, import, reconcile, plan.
Q42. What are Terraform provisioners, and when should they be avoided?
🧠 Simple Concept: Provisioners run commands or scripts during resource creation or destruction.
❓ Why do we need it? They can handle certain tasks that cannot be managed conveniently through native resources or other mechanisms.
⚙️ How does it work? Terraform invokes a configured local or remote command as part of the resource operation.
🏢 Production Example: A legacy setup depends on a remote command that has not yet been migrated to configuration management.
💻 Example:
provisioner "local-exec" {
command = "echo Resource created"
}🚨 Common Interview Trap: Provisioners are not the preferred way to manage ordinary application configuration or infrastructure. They can introduce timing, connectivity, and repeatability problems.
🎯 Candidate-Style Answer: “I avoid provisioners when native Terraform resources, cloud-init, image building, or configuration management can solve the problem more reliably.”
🧠 Memory Trick: Declarative resources first; provisioners only when justified.
🔥 Scenario-Based Interview Questions
Q43. A deployment completed successfully, but users are receiving HTTP 502 errors. How will you troubleshoot?
🧠 Simple Concept: HTTP 502 generally indicates that a gateway or proxy received an invalid response from an upstream server.
❓ Why do we need it? Successful deployment execution does not guarantee that the application is healthy or reachable.
⚙️ How does it work? Trace the request path from the external load balancer or ingress to the service and application container.
🏢 Production Example: The new application version is running, but the configured service target port does not match the application’s listening port.
💻 Commands:
kubectl get pods
kubectl get svc
kubectl get endpoints
kubectl describe ingress <ingress-name>
kubectl logs <pod-name>🚨 Common Interview Trap: Restarting every Pod without investigating the request path can hide evidence and prolong the incident.
🎯 Candidate-Style Answer: “I identify where the 502 originates, check load-balancer target health, inspect ingress and service configuration, verify endpoints and application ports, and review logs. I restore a known-good release if necessary and then investigate the root cause.”
🧠 Memory Trick: Entry point, routing, endpoints, application.
Q44. One Kubernetes worker node becomes NotReady. What actions will you take?
🧠 Simple Concept: NotReady means Kubernetes is not considering the node healthy and ready for normal workload scheduling.
❓ Why do we need it? To protect workloads and determine whether the issue is caused by node health, networking, or the underlying infrastructure.
⚙️ How does it work? Kubernetes evaluates node conditions and heartbeats to determine readiness.
🏢 Production Example: A worker node becomes unreachable after running out of disk space.
💻 Commands:
kubectl get nodes
kubectl describe node <node-name>
kubectl get pods -A -o wide🚨 Common Interview Trap: Immediately deleting or rebooting the node may worsen the situation if workloads are already unhealthy or the failure is systemic.
🎯 Candidate-Style Answer: “I inspect node conditions and events, verify workload impact, investigate kubelet, runtime, network, disk, and instance health, and follow a controlled recovery procedure.”
🧠 Memory Trick: Node health, workload impact, root cause, recovery.
Q45. Terraform accidentally deleted a production resource. How would you recover?
🧠 Simple Concept: Recovery depends on the resource type, the data it contains, and the available backup or restoration mechanisms.
❓ Why do we need it? To restore service safely without causing additional infrastructure damage.
⚙️ How does it work? Stop further destructive changes, assess the actual state, use the appropriate recovery mechanism, and reconcile Terraform configuration and state.
🏢 Production Example: A deleted storage resource must be restored from a service-specific backup or recovery mechanism.
💻 Commands:
terraform plan
terraform state listThese commands help inspect the configuration plan and state. They do not restore deleted infrastructure or data by themselves.
🚨 Common Interview Trap: Terraform state is not a backup of the underlying production data.
🎯 Candidate-Style Answer: “I stop further destructive applies, assess the impact, check backups and resource-specific recovery options, restore the resource through a controlled procedure, reconcile Terraform state and configuration, and validate the application.”
🧠 Memory Trick: Stop, assess, restore, reconcile, validate.
Q46. A Jenkins agent suddenly goes offline during a build. What will you check?
🧠 Simple Concept: An agent can go offline because of connectivity, process failure, resource exhaustion, or underlying infrastructure issues.
❓ Why do we need it? To restore build capacity and determine whether the failure is isolated or recurring.
⚙️ How does it work? Jenkins relies on configured agent connectivity and the health of the machine or container running the build.
🏢 Production Example: An ephemeral cloud agent is terminated because its host runs out of resources.
💻 Checks:
free -h
df -h
ps auxRun these on a Linux agent where appropriate, alongside Jenkins node status and agent logs.
🚨 Common Interview Trap: Retrying the build does not fix a persistent connectivity or resource issue.
🎯 Candidate-Style Answer: “I inspect Jenkins agent status and logs, verify network connectivity and credentials, check CPU, memory, and disk, and investigate the agent’s lifecycle or underlying infrastructure before reconnecting or replacing it.”
🧠 Memory Trick: Connectivity, process, resources, infrastructure.
Q47. Docker images are becoming very large. How will you optimize them?
🧠 Simple Concept: Image optimization removes unnecessary layers, dependencies, and files while preserving required runtime behavior.
❓ Why do we need it? To reduce image transfer time, storage consumption, and unnecessary software in the runtime environment.
⚙️ How does it work? Inspect image layers, review build instructions, and separate build-time dependencies from runtime dependencies.
🏢 Production Example: A final application image contains compilers and caches that are needed only during the build.
💻 Commands:
docker images
docker history myapp:latestIf installed:
dive myapp:latest🚨 Common Interview Trap: Smaller is not automatically safer. Use supported base images, preserve required runtime dependencies, and scan the final image.
🎯 Candidate-Style Answer: “I inspect image layers, use multi-stage builds, optimize the base image and .dockerignore, remove unnecessary dependencies, and compare image size while validating functionality and security.”
🧠 Memory Trick: Inspect, reduce, rebuild, test, scan.
🎯 Final Interview Preparation Checklist
Before your interview, practice explaining each topic without reading the answer word for word.
Linux permissions, process management, text processing, and cron.
Git history, cherry-pick, squash, recovery, and merge reverts.
Docker storage, networking, startup commands, and image security.
Kubernetes controllers, networking, scheduling, DNS, and rollbacks.
Jenkins triggers, shared libraries, credentials, and deployment strategies.
AWS networking, IAM, S3 security, and high availability.
Terraform modules, workspaces, lifecycle rules, import, and provisioners.
Production troubleshooting using evidence, safe recovery, and root-cause analysis.
Conclusion
The strongest DevOps interview answers connect concepts to operational decisions.
Don’t just say you know Kubernetes. Explain how you investigate a Pending Pod. Don’t just define Terraform state. Explain what you would do after an accidental production deletion. Don’t just describe CI/CD. Explain how you protect secrets and control production releases.
My friend shared these questions after attending a Wipro DevOps interview. Use them as a practical preparation resource, validate commands in a safe environment, and build your answers around real engineering reasoning.
Understand the concept. Practice the command. Explain the production impact. Learn the interview trap.
That’s how you move beyond memorized answers and prepare to think like a DevOps engineer. 🚀
Hashtags
#Wipro #WiproInterview #DevOpsInterview #DevOps #Linux #Git #Docker #Kubernetes #Jenkins #CICD #AWS #Terraform #CloudComputing #DevSecOps #PlatformEngineering #SRE #InterviewPreparation #DevOpsEngineer
Follow Me
If you enjoyed this article and would like more practical DevOps tutorials, interview preparation, AWS, Kubernetes, Terraform, CI/CD, and production troubleshooting 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