🚀 Capgemini DevOps Interview Questions and Answers: 50+ Practical Questions for Interview Preparation
🚀 Capgemini DevOps Interview Questions and Answers: 50+ Practical Questions for Interview Preparation
Linux, Git, Docker, Kubernetes, Jenkins, AWS, Terraform, and Real Production Scenarios
Preparing for a Capgemini DevOps interview? Here’s something worth understanding before you start memorizing commands.
Knowing kubectl get pods, docker build, terraform plan, and git pull is useful. But knowing the commands is only the beginning.
Imagine an interviewer asks:
“Your application was deployed successfully, but users are receiving intermittent HTTP 502 errors. How would you troubleshoot the issue?”
A weak answer might be: “I will check the Kubernetes Pods.”
A stronger answer explains the request flow, identifies the possible failure points, describes the commands used to investigate them, and explains how the engineer would restore service safely.
That is the difference between remembering DevOps concepts and demonstrating practical engineering knowledge.
This guide covers the major questions from a Capgemini DevOps interview preparation checklist, with simple explanations, production examples, commands, common interview traps, and candidate-style answers.
Note: These are practice questions for interview preparation, not a verified or official Capgemini interview questionnaire.
PART 1: Linux, Git, and Docker 🐧
SECTION 1: Linux Interview Questions
Q1. How do you create users and groups in Linux?
🧠 Simple Concept: Users represent individual accounts. Groups allow administrators to manage permissions for multiple users together.
❓ Why do we need it? To provide controlled access to servers and applications without giving everyone administrative privileges.
⚙️ How does it work? Create a group, create the user, assign the user to the group, and configure appropriate permissions.
🏢 Production Example: Developers need access to application logs but must not be allowed to modify system configuration.
💻 Commands:
sudo groupadd developers
sudo useradd -m -s /bin/bash arvind
sudo usermod -aG developers arvind
id arvind🚨 Common Interview Trap: Use usermod -aG when adding supplementary groups. Omitting -a can replace the user’s existing supplementary group memberships.
🎯 Candidate-Style Answer: “I create users and groups according to access requirements, assign users to appropriate groups, and follow least-privilege principles.”
🧠 Memory Trick: User = identity. Group = shared access.
Q2. Explain file permissions and ownership.
🧠 Simple Concept: Linux permissions determine who can read, write, or execute a file.
❓ Why do we need it? To protect application files, scripts, credentials, and system resources from unauthorized access.
⚙️ How does it work? Permissions are assigned to the owner, group, and others. The numeric values are read = 4, write = 2, execute = 1.
🏢 Production Example: A deployment script must be executable by the deployment user but should not be writable by every user on the server.
💻 Commands:
ls -l deploy.sh
chmod 750 deploy.sh
chown deployuser:developers deploy.sh🚨 Common Interview Trap: chmod 755 gives the owner read/write/execute and group and others read/execute. It does not grant write access to everyone.
🎯 Candidate-Style Answer: “I manage file ownership and permissions based on the application’s requirements and avoid unnecessarily broad permissions.”
🧠 Memory Trick: rwx = 4 + 2 + 1.
Q3. What is umask?
🧠 Simple Concept: umask controls which permissions are removed from the default permissions when new files and directories are created.
❓ Why do we need it? To establish safer default permissions.
⚙️ How does it work? The system starts with default creation permissions, then applies the mask. Typical base modes are 666 for files and 777 for directories, subject to application behavior.
🏢 Production Example: A shared server should not create new files that are writable by every user.
💻 Commands:
umask
umask 027With umask 027, typical new files receive 640 and directories receive 750, assuming the usual base modes.
🚨 Common Interview Trap: umask does not directly set the final permissions. It removes permissions from the defaults.
🎯 Candidate-Style Answer: “I use umask to control default permissions and reduce unintended access to newly created files and directories.”
🧠 Memory Trick: umask masks permissions.
Q4. How do you troubleshoot high CPU, memory, and disk usage?
🧠 Simple Concept: Investigate which process or resource is causing the problem before changing the system.
❓ Why do we need it? Resource exhaustion can cause application latency, crashes, and service outages.
⚙️ How does it work? Check system-level utilization, identify the affected process, inspect logs, and compare findings with recent changes.
🏢 Production Example: A Java application becomes slow after a release. You discover sustained CPU utilization and investigate application threads and recent code changes.
💻 Commands:
top
free -h
df -h
du -sh /var/log/*
ps aux --sort=-%cpu | head
ps aux --sort=-%mem | head🚨 Common Interview Trap: df -h checks filesystem space, while du estimates space used by files and directories. They answer different questions.
🎯 Candidate-Style Answer: “I identify the affected resource, find the responsible process or filesystem, correlate the issue with logs and recent changes, and then apply a targeted fix.”
🧠 Memory Trick: CPU = processing, memory = working space, disk = storage.
Q5. Write a Bash script to monitor disk utilization.
🧠 Simple Concept: A script can automatically check disk usage and alert when utilization crosses a threshold.
❓ Why do we need it? A full filesystem can prevent applications from writing logs, temporary files, or business data.
💻 Example script:
#!/usr/bin/env bash
THRESHOLD=80
df -P -x tmpfs -x devtmpfs |
awk -v threshold="$THRESHOLD" '
NR > 1 {
gsub(/%/, "", $5)
if ($5 >= threshold) {
printf "WARNING: %s is %s%% full\n", $6, $5
}
}'Save it as disk_monitor.sh and run:
chmod +x disk_monitor.sh
./disk_monitor.sh🏢 Production Example: Schedule the script through cron or integrate disk metrics with a monitoring platform that sends alerts.
🚨 Common Interview Trap: Printing a warning is not the same as sending an alert. Real alerting needs an integration with email, messaging, or monitoring systems.
🎯 Candidate-Style Answer: “I automate disk checks, define a utilization threshold, and integrate the result with monitoring so the team can act before the filesystem becomes full.”
🧠 Memory Trick: Measure → Compare → Alert.
Q6. What is the difference between cron and systemd timers?
🧠 Simple Concept: Both schedule tasks, but they use different mechanisms.
How they differ:
Cron: Uses scheduled entries to run commands at specified times.
systemd timers: Schedule systemd services and can integrate with service dependencies, logging, and system management.
💻 Examples:
Cron entry:
0 2 * * * /opt/scripts/backup.shA systemd timer is typically configured with a .timer unit and a corresponding .service unit.
🏢 Production Example: A simple nightly cleanup job may use cron. A managed system task that needs service dependencies and systemd journal integration may benefit from a systemd timer.
🚨 Common Interview Trap: Neither mechanism automatically guarantees a task completed successfully. Monitoring and failure handling still matter.
🎯 Candidate-Style Answer: “I use cron for straightforward recurring jobs and systemd timers when service integration and system-level management are useful.”
🧠 Memory Trick: Cron schedules commands; systemd timers schedule units.
SECTION 2: Git Interview Questions
Q7. Explain Git Fetch vs Pull vs Merge vs Rebase.
🧠 Simple Concept: These commands help synchronize and integrate code changes.
git fetch: Downloads remote updates without integrating them into your current branch.git pull: Fetches and integrates remote changes, usually through merge or rebase depending on configuration.git merge: Combines branch histories.git rebase: Replays commits onto a different base, creating new commit identities.
💻 Commands:
git fetch origin
git pull origin main
git merge feature/login
git rebase main🏢 Production Example: Before merging a feature branch, you fetch the latest main branch and review whether your changes need updating.
🚨 Common Interview Trap: Rebasing shared branches can rewrite history. Coordinate before doing it.
🎯 Candidate-Style Answer: “I use fetch to inspect remote changes, pull to synchronize my branch, merge when I want to combine histories, and rebase when I need a linear history and rewriting the relevant commits is appropriate.”
🧠 Memory Trick: Fetch downloads, pull integrates, merge combines, rebase replays.
Q8. Explain Git Reset vs Git Revert.
🧠 Simple Concept: Both can undo changes, but they affect history differently.
git reset: Moves the current branch reference and can change the staging area or working tree.git revert: Creates a new commit that reverses the changes introduced by an earlier commit.
💻 Commands:
git reset --soft HEAD~1
git revert <commit-id>🏢 Production Example: A faulty commit has already been pushed to a shared production branch. Revert is usually safer because it preserves history and records the correction.
🚨 Common Interview Trap: git reset --hard can discard uncommitted work. Do not use it casually.
🎯 Candidate-Style Answer: “For a shared branch, I generally prefer revert to preserve the audit trail. I use reset when rewriting local history is appropriate and I understand which changes may be lost.”
🧠 Memory Trick: Reset moves history; revert adds an undo commit.
Q9. How do you resolve merge conflicts?
🧠 Simple Concept: A conflict occurs when Git cannot automatically reconcile overlapping changes.
⚙️ How it works: Inspect conflicted files, decide the correct combined result, remove conflict markers, test the code, and complete the merge or rebase.
💻 Commands:
git status
git diff
# Edit the conflicted files
git add <file>
git commitFor a rebase, use git rebase --continue after resolving and staging conflicts.
🏢 Production Example: Two developers modify the same deployment configuration. You review both changes and ensure the final YAML remains valid.
🚨 Common Interview Trap: Do not blindly accept “ours” or “theirs” without checking the intended behavior.
🎯 Candidate-Style Answer: “I inspect the conflict, understand both changes, resolve them according to the requirement, run the relevant tests, and then complete the integration.”
🧠 Memory Trick: Inspect → Resolve → Test → Complete.
Q10. Explain your Git branching strategy.
🧠 Simple Concept: A branching strategy defines how teams develop, review, and release changes.
🏢 Production Example: A team may use short-lived feature branches, pull requests, required reviews, automated tests, and a protected main branch. Release branches or tags can be used when the release process requires them.
🚨 Common Interview Trap: Do not claim that Git Flow, trunk-based development, or any single strategy is universally best. Explain why the selected approach suits the team.
🎯 Candidate-Style Answer: “I follow a controlled branching workflow with short-lived feature branches, pull-request reviews, automated checks, and a protected main branch. The exact strategy depends on release requirements and team practices.”
🧠 Memory Trick: Branch → Review → Test → Merge → Release.
Q11. How do you roll back a bad commit in production?
🧠 Simple Concept: Restore a known-good state without losing track of what happened.
💻 Commands:
git log --oneline
git revert <bad-commit-id>
git push origin main🏢 Production Example: A code change introduces a payment calculation defect. The team reverts the change, runs validation, and redeploys through the approved pipeline.
🚨 Common Interview Trap: Reverting Git history does not automatically undo database migrations or external side effects.
🎯 Candidate-Style Answer: “I identify the faulty change, assess its impact, revert it through the team’s review process, and deploy the correction through CI/CD. I also verify application health and consider any data changes that need separate recovery.”
🧠 Memory Trick: Identify → Revert → Redeploy → Validate.
SECTION 3: Docker Interview Questions 🐳
Q12. Explain Docker architecture.
🧠 Simple Concept: Docker uses a client-server model to build and manage containerized applications.
⚙️ Main components:
Docker client: accepts commands.
Docker daemon: manages images, containers, networks, and volumes.
Images: templates for creating containers.
Containers: running instances of images.
Registry: stores and distributes images.
🏢 Production Example: A CI pipeline builds an application image, pushes it to a registry, and a deployment platform pulls that image to run the application.
🚨 Common Interview Trap: An image is not the same thing as a running container.
🎯 Candidate-Style Answer: “The Docker client sends requests to the Docker daemon, which manages container resources. Images are stored locally or in registries and used to create containers.”
🧠 Memory Trick: Client → Daemon → Image → Container.
Q13. What is the difference between an image, container, and volume?
Simple Concept:
Image: The packaged template.
Container: The running instance.
Volume: Persistent storage managed separately from a container’s writable layer.
🏢 Production Example: A database container can be replaced during an update while its data remains in a properly configured persistent volume.
💻 Commands:
docker images
docker ps -a
docker volume ls🚨 Common Interview Trap: Container storage is not automatically persistent. Data in the writable layer can be lost when a container is removed.
🎯 Candidate-Style Answer: “Images package the application, containers run it, and volumes preserve data independently of the container lifecycle.”
🧠 Memory Trick: Image = template, container = process, volume = data.
Q14. What are Docker multi-stage builds?
🧠 Simple Concept: Multi-stage builds separate the build environment from the final runtime image.
💻 Example:
FROM golang:1.24 AS builder
WORKDIR /app
COPY . .
RUN go build -o app .
FROM debian:bookworm-slim
WORKDIR /app
COPY --from=builder /app/app .
CMD ["./app"]🏢 Production Example: The final image contains the compiled application rather than the full compiler and build toolchain.
🚨 Common Interview Trap: A smaller image is not automatically secure. You must still update dependencies, scan images, and minimize runtime privileges.
🎯 Candidate-Style Answer: “I use multi-stage builds to separate compilation from runtime and reduce unnecessary files and tools in the final image.”
🧠 Memory Trick: Build big, run lean.
Q15. How do you optimize Docker image size?
Simple Concept: Remove unnecessary files, layers, dependencies, and build tools.
Practical methods:
Choose suitable base images.
Use multi-stage builds.
Add a
.dockerignorefile.Install only runtime dependencies.
Avoid copying secrets and local build artifacts.
Use image scanning and maintenance practices.
💻 Commands:
docker images
docker history <image-name>🏢 Production Example: Smaller images can reduce registry storage, transfer time, and deployment delays.
🚨 Common Interview Trap: Do not remove required runtime dependencies just to achieve a smaller image.
🎯 Candidate-Style Answer: “I inspect image layers, use appropriate base images, exclude unnecessary files, and separate build dependencies from runtime dependencies.”
🧠 Memory Trick: Inspect → Exclude → Minimize → Scan.
Q16. Explain Docker networking.
🧠 Simple Concept: Docker networking lets containers communicate with each other and with external systems.
Common network types:
Bridge: Common for containers on a single Docker host.
Host: Shares the host network namespace on supported platforms.
None: Disables normal container networking.
Overlay: Connects containers across multiple Docker hosts in supported swarm configurations.
💻 Commands:
docker network ls
docker network inspect <network-name>🏢 Production Example: A web container communicates with an application container over a private Docker network instead of exposing every service publicly.
🚨 Common Interview Trap: Docker bridge networking and Kubernetes networking are not the same system.
🎯 Candidate-Style Answer: “I choose the network based on communication and isolation requirements, exposing only the ports that need external access.”
🧠 Memory Trick: Network = connectivity plus isolation.
Q17. How do you troubleshoot a container that keeps restarting?
Simple Concept: Find why the process exits rather than repeatedly restarting the container.
💻 Commands:
docker ps -a
docker logs <container-name>
docker inspect <container-name>
docker stats🏢 Production Example: A container exits because a required environment variable is missing or the application cannot connect to its database.
🚨 Common Interview Trap: Restarting the container may temporarily change the symptom without fixing the cause.
🎯 Candidate-Style Answer: “I inspect the exit status, logs, configuration, resource usage, and dependencies. Then I fix the root cause and verify that the container remains healthy.”
🧠 Memory Trick: Status → Logs → Config → Resources → Dependencies.
PART 2: Kubernetes, Jenkins, and AWS ☸️
SECTION 4: Kubernetes Interview Questions
Q18. Explain Kubernetes architecture.
🧠 Simple Concept: Kubernetes orchestrates containers across a cluster of machines.
⚙️ Main components:
API server: Entry point for Kubernetes API requests.
Scheduler: Selects suitable nodes for Pods.
Controller manager: Runs controllers that reconcile actual state with desired state.
etcd: Stores Kubernetes cluster state.
Kubelet: Manages Pods on a node.
Container runtime: Runs containers.
Network components: Enable cluster and Service connectivity.
🏢 Production Example: You request three application replicas. Kubernetes controllers work to maintain the desired replica count as Pods or nodes fail.
🚨 Common Interview Trap: The scheduler selects nodes; the kubelet on each node manages assigned Pods.
🎯 Candidate-Style Answer: “The control plane manages the cluster’s desired state, while worker nodes run the workloads. Kubernetes controllers continually work to reconcile actual state with the configuration.”
🧠 Memory Trick: Control plane decides; worker nodes run.
Q19. Deployment vs StatefulSet vs DaemonSet vs Job
Simple Concept:
Deployment: Manages interchangeable replicas, commonly for stateless applications.
StatefulSet: Manages workloads needing stable identities and/or persistent storage.
DaemonSet: Runs a Pod on each eligible node.
Job: Runs a task to completion.
🏢 Production Example: An API can use a Deployment, a stateful database may use a StatefulSet, a node logging agent can use a DaemonSet, and a database migration can run as a Job.
🚨 Common Interview Trap: StatefulSet does not automatically make a database highly available. The application still needs suitable replication and recovery design.
🎯 Candidate-Style Answer: “I select the workload controller according to application behavior: Deployment for interchangeable replicas, StatefulSet for stable identity, DaemonSet for node-level agents, and Job for finite tasks.”
🧠 Memory Trick: Deployment = replicas; StatefulSet = identity; DaemonSet = nodes; Job = completion.
Q20. Explain Kubernetes Services and Ingress.
🧠 Simple Concept: A Service provides stable network access to selected Pods. Ingress defines HTTP/HTTPS routing rules that an Ingress Controller implements.
🏢 Production Example: Requests for shop.example.com reach the frontend Service, while api.example.com reaches the API Service through configured ingress routing.
💻 Commands:
kubectl get svc
kubectl get ingress
kubectl describe ingress <name>🚨 Common Interview Trap: Creating an Ingress resource alone does not guarantee routing works. An appropriate Ingress Controller and correct networking configuration are required.
🎯 Candidate-Style Answer: “Services provide stable access to Pods, while Ingress and its controller manage supported HTTP/HTTPS routing into the cluster.”
🧠 Memory Trick: Service reaches Pods; Ingress routes web traffic.
Q21. How do you troubleshoot CrashLoopBackOff?
Simple Concept: The container repeatedly exits and Kubernetes backs off before restarting it again.
💻 Commands:
kubectl get pods
kubectl describe pod <pod-name>
kubectl logs <pod-name>
kubectl logs <pod-name> --previous
kubectl get events🏢 Production Example: Logs reveal that the application cannot connect to its database because a secret contains an incorrect endpoint.
🚨 Common Interview Trap: CrashLoopBackOff is a status describing restart behavior, not the root cause itself.
🎯 Candidate-Style Answer: “I inspect events, current and previous logs, exit codes, probes, resource limits, configuration, and dependencies to determine why the process exits.”
🧠 Memory Trick: Events → Logs → Configuration → Dependencies.
Q22. Explain Kubernetes requests vs limits.
Simple Concept: Requests help the scheduler place Pods; limits constrain resource consumption.
💻 YAML:
resources:
requests:
cpu: "250m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"🏢 Production Example: Oversized requests can leave insufficient schedulable capacity. Excessive memory use beyond the container’s memory limit can lead to termination due to an out-of-memory condition.
🚨 Common Interview Trap: CPU limits can throttle workloads. Memory limits can lead to OOM kills. Requests are not simply guaranteed performance.
🎯 Candidate-Style Answer: “I set requests based on scheduling needs and tune limits according to workload behavior, while monitoring throttling, memory pressure, and application performance.”
🧠 Memory Trick: Request = scheduling; limit = maximum permitted use.
Q23. Explain ConfigMaps and Secrets.
Simple Concept: ConfigMaps store non-sensitive configuration. Secrets are intended for sensitive values such as credentials and tokens.
🏢 Production Example: An application reads its log level from a ConfigMap and obtains a database credential through an approved secret-management mechanism.
🚨 Common Interview Trap: Kubernetes Secrets are not automatically secure merely because they are called Secrets. Access control, encryption at rest, and safe handling are important.
🎯 Candidate-Style Answer: “I separate configuration from application images, use ConfigMaps for non-sensitive values, and protect credentials through controlled Secret access or an integrated secret manager.”
🧠 Memory Trick: ConfigMap = configuration; Secret = sensitive data.
Q24. What are liveness and readiness probes?
Simple Concept:
Liveness: Determines whether a container should be restarted.
Readiness: Determines whether a Pod should receive normal Service traffic.
Startup probe: Gives a slow-starting application time to initialize before liveness checks take effect.
🏢 Production Example: An application needs 60 seconds to start. A suitable startup probe prevents premature liveness failures, while readiness keeps it out of traffic until it can serve requests.
🚨 Common Interview Trap: An overly aggressive liveness probe can create restart loops during temporary slowdowns.
🎯 Candidate-Style Answer: “I configure probes according to application behavior. Readiness controls traffic eligibility, while liveness detects a process that needs restarting.”
🧠 Memory Trick: Startup = initialize; readiness = receive traffic; liveness = stay alive.
Q25. Explain node affinity, taints, and tolerations.
Simple Concept: These features influence where Kubernetes schedules workloads.
Node affinity: Attracts Pods to nodes that match specified conditions.
Taint: Marks a node so Pods are rejected unless they tolerate the taint.
Toleration: Allows a Pod to be scheduled onto a node with a matching taint, but does not guarantee placement.
🏢 Production Example: GPU workloads need specialized nodes. Node labels and affinity help select those nodes, while taints can keep unrelated workloads away.
🚨 Common Interview Trap: A toleration does not itself force a Pod onto a particular node.
🎯 Candidate-Style Answer: “I use affinity to express placement preferences or requirements and taints with tolerations to control which workloads can use particular nodes.”
🧠 Memory Trick: Affinity attracts; taint repels; toleration permits.
Q26. How do you perform an EKS cluster upgrade?
Simple Concept: Upgrade the cluster in a planned sequence while checking compatibility and workload health.
⚙️ Typical approach:
Review the target Kubernetes version and supported upgrade path.
Inspect deprecated APIs and add-on compatibility.
Back up important configurations and verify recovery procedures.
Upgrade the EKS control plane according to AWS guidance.
Upgrade compatible add-ons and node groups.
Validate scheduling, networking, storage, and application health.
Monitor workloads and address issues before continuing.
🏢 Production Example: A node upgrade disrupts a critical service because too few replicas are available. Pod disruption budgets, capacity planning, and rollout validation help reduce the risk.
🚨 Common Interview Trap: A Pod disruption budget does not guarantee availability if the application has insufficient replicas or other failure modes.
🎯 Candidate-Style Answer: “I plan the version upgrade, verify compatibility, upgrade components in the supported sequence, maintain sufficient capacity, and validate workloads throughout the process.”
🧠 Memory Trick: Plan → Check → Upgrade → Validate.
SECTION 5: Jenkins and CI/CD
Q27. Explain your Jenkins pipeline.
Simple Concept: A pipeline automates the steps required to build, test, package, and deploy software.
🏢 Production Example:
Developer → Git → Build → Tests → Code Scan → Docker Build → Image Scan → Registry → Deployment → Validation
💻 Example stages:
pipeline {
agent any
stages {
stage('Checkout') {
steps {
checkout scm
}
}
stage('Test') {
steps {
sh 'make test'
}
}
stage('Build Image') {
steps {
sh 'docker build -t app:${BUILD_NUMBER} .'
}
}
}
}This is a simplified example. A real pipeline must also handle credentials, image publishing, security checks, deployment, and failure reporting.
🚨 Common Interview Trap: A successful image build does not prove that the application works correctly in production.
🎯 Candidate-Style Answer: “My pipeline automates source checkout, testing, building, security validation, artifact publishing, deployment, and post-deployment checks according to the team’s release process.”
🧠 Memory Trick: Code → Test → Build → Scan → Deploy → Verify.
Q28. Declarative vs Scripted Jenkins Pipelines
Simple Concept: Both define Jenkins workflows but use different syntax and levels of flexibility.
Declarative: Structured syntax with defined sections such as
pipeline,stages, andsteps.Scripted: More flexible Groovy-based syntax, often useful for complex programmatic logic.
🏢 Production Example: A standard build-and-deploy workflow can use Declarative Pipeline. More complex dynamic logic may justify Scripted Pipeline or shared-library abstractions.
🚨 Common Interview Trap: Declarative pipelines can still include scripted sections, so the distinction is not absolute.
🎯 Candidate-Style Answer: “I prefer Declarative Pipeline for standard workflows because its structure is easy to review and maintain. I use scripted logic when the requirements genuinely need additional flexibility.”
🧠 Memory Trick: Declarative = structured; Scripted = flexible.
Q29. How do you implement CI/CD for microservices?
Simple Concept: Automate the delivery process while allowing services to be built and deployed independently when the architecture supports it.
🏢 Production Example: A change to the payment service triggers its tests, image build, security scans, and deployment without forcing unrelated services to be released.
🚨 Common Interview Trap: Independent pipelines do not remove the need for API compatibility, integration testing, or coordinated changes when services depend on one another.
🎯 Candidate-Style Answer: “I design service-specific build and deployment workflows, reuse common pipeline templates, and include automated testing, image scanning, controlled releases, and post-deployment validation.”
🧠 Memory Trick: Standardize the pipeline; isolate the release.
Q30. How do you secure Jenkins?
Simple Concept: Protect Jenkins credentials, users, agents, plugins, and pipeline execution.
Practical measures:
Use role-based access control and least privilege.
Store credentials in Jenkins Credentials or an approved external secret manager.
Restrict agent permissions and network access.
Maintain and update Jenkins and plugins.
Protect pipeline definitions and shared libraries.
Avoid exposing secrets in logs.
Audit sensitive actions.
🏢 Production Example: A pipeline needs permission to publish an image but should not have unrestricted administrator access to the cloud account.
🚨 Common Interview Trap: Hiding credentials in a pipeline file is not secure secret management.
🎯 Candidate-Style Answer: “I secure Jenkins using least-privilege access, managed credentials, protected pipeline code, restricted agents, plugin maintenance, and audit controls.”
🧠 Memory Trick: Users + Credentials + Agents + Plugins + Auditing.
Q31. What would you do if a Jenkins pipeline suddenly starts failing?
Simple Concept: Compare the failing run with the last successful run and isolate the stage that changed.
💻 Investigation:
Review the failed stage and console output.
Check recent code, pipeline, plugin, and agent changes.
Verify credentials, network access, dependencies, and available disk space.
Reproduce the issue when practical.
Restore a known-good configuration if needed.
🏢 Production Example: A previously working build starts failing because a package repository changed or a Jenkins agent ran out of disk space.
🚨 Common Interview Trap: Do not immediately rerun the pipeline repeatedly without understanding the error.
🎯 Candidate-Style Answer: “I identify the failing stage, compare it with a successful run, inspect logs and recent changes, isolate the cause, and apply the smallest safe correction before validating the pipeline.”
🧠 Memory Trick: Stage → Logs → Changes → Cause → Fix.
PART 3: AWS, Terraform, and Production Scenarios ☁️
SECTION 6: AWS Interview Questions
Q32. Explain VPC architecture.
Simple Concept: A VPC is a logically isolated network for AWS resources.
⚙️ Main components: Subnets, route tables, Internet Gateways, NAT Gateways, security groups, network ACLs, and connectivity options such as VPN or Direct Connect.
🏢 Production Example: Public-facing load balancers are placed in public subnets, while application servers and databases can run in private subnets with controlled network access.
🚨 Common Interview Trap: A subnet is not public simply because of its name. Its route table and connectivity configuration determine its behavior.
🎯 Candidate-Style Answer: “I design VPCs around network segmentation, routing, controlled ingress and egress, and availability across multiple Availability Zones where required.”
🧠 Memory Trick: VPC = network; subnet = segment; route table = path.
Q33. Security Groups vs Network ACLs
Simple Concept:
Security Groups: Stateful controls attached to supported resources or network interfaces.
Network ACLs: Stateless subnet-level traffic controls.
🏢 Production Example: A security group permits HTTPS to a load balancer and database access only from the application tier. A network ACL provides an additional subnet-level traffic control layer.
🚨 Common Interview Trap: Because network ACLs are stateless, inbound and outbound rules must account for return traffic.
🎯 Candidate-Style Answer: “I use security groups for resource-level traffic control and network ACLs for subnet-level filtering where needed. I validate both layers when troubleshooting connectivity.”
🧠 Memory Trick: Security Group = stateful; NACL = stateless.
Q34. Explain IAM roles and policies.
Simple Concept: IAM policies define permissions. Roles provide an identity that an authorized principal can assume.
🏢 Production Example: An application running on AWS should access an S3 bucket using an appropriate role rather than hardcoded access keys.
🚨 Common Interview Trap: An IAM role does not automatically grant every permission. Its trust policy and attached permissions must allow the required access.
🎯 Candidate-Style Answer: “I use roles for workload and cross-account access where appropriate, define narrowly scoped permissions, and avoid long-lived credentials whenever possible.”
🧠 Memory Trick: Trust policy = who can assume; permissions policy = what they can do.
Q35. EC2 vs Auto Scaling Group vs Load Balancer
Simple Concept:
EC2: A virtual server.
Auto Scaling Group: Maintains a configured fleet of instances and can adjust capacity.
Load Balancer: Distributes incoming traffic across targets.
🏢 Production Example: A load balancer sends traffic to healthy EC2 instances managed by an Auto Scaling Group. The group adds or removes capacity according to its configuration and scaling policies.
🚨 Common Interview Trap: Auto Scaling does not automatically fix an application-level defect, and a load balancer cannot make an unhealthy target healthy.
🎯 Candidate-Style Answer: “EC2 provides compute, Auto Scaling manages instance capacity, and a load balancer distributes traffic to healthy targets.”
🧠 Memory Trick: Compute → Scale → Distribute.
Q36. EBS vs EFS vs S3
Simple Concept:
EBS: Block storage commonly attached to EC2 instances.
EFS: Managed shared file storage.
S3: Object storage for files and objects accessed through APIs.
🏢 Production Example: Use EBS for a supported server disk, EFS when workloads need shared file access, and S3 for backups, artifacts, and object data.
🚨 Common Interview Trap: S3 is not a conventional mounted block disk, and EBS is not the same as shared file storage.
🎯 Candidate-Style Answer: “I choose storage based on access patterns: EBS for block storage, EFS for shared files, and S3 for durable object storage.”
🧠 Memory Trick: EBS = block; EFS = files; S3 = objects.
Q37. How do private subnet instances access the internet?
Simple Concept: Private instances commonly use a NAT Gateway for outbound IPv4 internet access without receiving unsolicited inbound internet connections through that path.
🏢 Production Example:
Private EC2 → Private Route Table → NAT Gateway → Internet Gateway → Internet
The NAT Gateway is placed in a public subnet with a route to an Internet Gateway. The private subnet routes appropriate outbound traffic through the NAT Gateway.
🚨 Common Interview Trap: A NAT Gateway does not make a private instance directly reachable from the public internet.
🎯 Candidate-Style Answer: “I route outbound IPv4 internet traffic from the private subnet through a NAT Gateway in a public subnet. I also consider NAT availability, routing, and cost.”
🧠 Memory Trick: Internet Gateway = direct public connectivity path; NAT Gateway = outbound path for private IPv4 resources.
Q38. Which AWS services have you used in your project?
🧠 Simple Concept: Interviewers want to understand your actual hands-on experience and how the services fit together.
🏢 Example architecture: VPC → EKS → ECR → IAM roles → Load Balancer → CloudWatch.
Terraform may provision the infrastructure, while CI/CD automates image publishing and deployment.
🚨 Common Interview Trap: Do not list services you have only read about as if you implemented them in production.
🎯 Candidate-Style Answer: “In my project, I used the services relevant to the platform architecture. I can explain each service’s role, how it connects to the others, how access is controlled, and how I would troubleshoot failures.”
🧠 Memory Trick: Service → Purpose → Integration → Troubleshooting.
SECTION 7: Terraform Interview Questions
Q39. Explain the Terraform lifecycle.
Simple Concept: Terraform compares configuration and state with observed infrastructure, then proposes and applies changes.
💻 Typical workflow:
terraform init
terraform fmt
terraform validate
terraform plan
terraform apply🏢 Production Example: A change to an infrastructure module produces a plan. The team reviews the proposed modifications before applying them to production.
🚨 Common Interview Trap: terraform apply should not be treated as a harmless command. Review the plan and understand destructive changes before applying them.
🎯 Candidate-Style Answer: “I initialize the working directory, validate configuration, review the execution plan, apply approved changes, and verify the resulting infrastructure.”
🧠 Memory Trick: Initialize → Validate → Plan → Apply → Verify.
Q40. What is Terraform state?
Simple Concept: State maps Terraform configuration resources to the real infrastructure Terraform manages.
❓ Why do we need it? Terraform uses state to track resource identities and understand what it manages between runs.
🏢 Production Example: A team uses a remote state backend so authorized engineers and CI/CD jobs can work with the same infrastructure state.
🚨 Common Interview Trap: State is not simply a backup copy of the configuration. It can contain sensitive values and must be protected.
🎯 Candidate-Style Answer: “Terraform state tracks managed resources and supports planning changes. I protect it with access controls, secure storage, and suitable collaboration mechanisms.”
🧠 Memory Trick: Configuration describes; state tracks.
Q41. Why use a remote backend?
Simple Concept: A remote backend stores Terraform state outside the engineer’s local machine.
🏢 Production Example: Multiple engineers and an automated pipeline need to manage shared infrastructure without relying on a state file on one laptop.
Benefits: Centralized access, collaboration, durable storage, and backend-supported locking where available.
🚨 Common Interview Trap: Remote storage alone does not guarantee locking, encryption, or correct access control. These capabilities depend on the backend and its configuration.
🎯 Candidate-Style Answer: “I use a suitable remote backend to centralize state and support team collaboration, with encryption, permissions, versioning, and locking where supported.”
🧠 Memory Trick: Remote state = shared and protected state.
Q42. Explain Terraform state locking.
Simple Concept: Locking helps prevent concurrent operations from modifying the same state simultaneously.
🏢 Production Example: Two engineers attempt to apply infrastructure changes at the same time. Supported backend locking helps serialize the state-changing operations.
🚨 Common Interview Trap: Do not manually remove a lock just because an operation appears slow. Verify whether a legitimate process is still running before attempting recovery.
🎯 Candidate-Style Answer: “I use backend-supported state locking to reduce concurrent modification risks. If locking fails, I investigate the active operation and backend status before taking recovery action.”
🧠 Memory Trick: One state, one active writer.
Q43. What is Terraform drift?
Simple Concept: Drift occurs when real infrastructure differs from the configuration or state Terraform expects.
🏢 Production Example: Someone manually changes a security group rule in AWS. The next Terraform plan detects a difference that needs investigation.
💻 Command:
terraform plan🚨 Common Interview Trap: Do not automatically apply every drift correction. A manual change may represent a legitimate operational requirement or an unauthorized modification.
🎯 Candidate-Style Answer: “I use plans and refresh behavior to identify drift, investigate why the resource changed, and then reconcile configuration and infrastructure through an approved process.”
🧠 Memory Trick: Desired state vs actual state.
Q44. Resource vs data source in Terraform
Simple Concept:
Resource: Defines infrastructure Terraform manages.
Data source: Reads information about an existing resource or external data source.
💻 Example:
data "aws_vpc" "existing" {
id = var.vpc_id
}🏢 Production Example: A platform module creates a new EKS cluster while reading an existing VPC through a data source.
🚨 Common Interview Trap: A data source does not ordinarily create or manage the lifecycle of the infrastructure it reads.
🎯 Candidate-Style Answer: “I use resources to create and manage infrastructure and data sources to retrieve information about existing resources needed by the configuration.”
🧠 Memory Trick: Resource manages; data source reads.
Q45. How do you manage secrets in Terraform?
Simple Concept: Sensitive credentials must be protected from exposure through configuration, state, logs, and outputs.
Practical methods:
Retrieve credentials from an approved secret manager.
Use least-privilege IAM permissions.
Avoid committing credentials to Git.
Mark sensitive values appropriately to reduce display exposure.
Secure state storage and restrict access.
Rotate credentials when required.
🏢 Production Example: Terraform obtains an approved secret reference for an application rather than hardcoding a database password in the module.
🚨 Common Interview Trap: Marking a Terraform variable as sensitive does not automatically remove its value from state.
🎯 Candidate-Style Answer: “I avoid hardcoded secrets, use a secret manager and restricted access, and protect Terraform state because sensitive values may still be stored there.”
🧠 Memory Trick: Do not commit it, expose it, or ignore state.
SECTION 8: Scenario-Based Production Questions 🔥
Q46. A Kubernetes Pod is in CrashLoopBackOff. How will you troubleshoot it?
🧠 Simple Concept: Identify why the container repeatedly exits.
💻 Commands:
kubectl describe pod <pod-name>
kubectl logs <pod-name> --previous
kubectl get events🏢 Investigation: Check exit codes, application logs, configuration, secrets, dependencies, probes, and resource constraints.
🚨 Common Interview Trap: Increasing memory or restarting the Pod without evidence may hide the symptom temporarily.
🎯 Candidate-Style Answer: “I inspect the previous logs and events, determine why the container exited, check dependencies and resource limits, then fix the root cause and validate recovery.”
🧠 Memory Trick: Find the exit reason before changing resources.
Q47. Jenkins pipeline fails after a recent code change. What do you check?
Simple Concept: Find the first failing stage and compare it with the last successful run.
🏢 Investigation:
Inspect console output.
Identify the first failure.
Compare code and pipeline changes.
Check dependencies, credentials, agent health, and disk space.
Reproduce the issue and validate the correction.
🚨 Common Interview Trap: A failed pipeline is not always caused by the code. Infrastructure, credentials, plugins, and external dependencies can also fail.
🎯 Candidate-Style Answer: “I isolate the failing stage, compare the run with a successful build, inspect recent changes and logs, and apply a targeted fix before rerunning the relevant checks.”
🧠 Memory Trick: First failure, then root cause.
Q48. Terraform deployment failed halfway. How do you recover?
Simple Concept: Determine what was actually created or changed before attempting another apply.
💻 Commands:
terraform plan
terraform state list
terraform state show <resource-address>🏢 Investigation: Review the error, state, cloud resources, dependencies, and whether any operation is still running. Resolve the underlying issue and review the next plan carefully.
🚨 Common Interview Trap: Do not delete the state file or manually recreate everything. Some infrastructure changes may have succeeded even though the overall operation failed.
🎯 Candidate-Style Answer: “I inspect the error and current state, verify actual cloud resources, fix the cause, and review a new plan before continuing. If state reconciliation is needed, I follow a controlled recovery process.”
🧠 Memory Trick: Inspect → Reconcile → Plan → Continue.
Q49. Production application is not accessible after deployment. What do you check?
Simple Concept: Trace the request from the user-facing entry point to the application and its dependencies.
🏢 Troubleshooting flow:
DNS → Load Balancer → Ingress → Service → Pod → Application → Dependencies
The exact path depends on the architecture.
💻 Commands:
kubectl get pods,svc,ingress
kubectl describe pod <pod-name>
kubectl logs <pod-name>
kubectl get events🚨 Common Interview Trap: A healthy Pod does not guarantee the application is reachable. DNS, routing, target health, Service selectors, ports, and application listeners can all cause failures.
🎯 Candidate-Style Answer: “I reproduce the issue, check DNS and network routing, validate load-balancer and Ingress health, inspect Service endpoints and Pod readiness, then review application logs and dependencies.”
🧠 Memory Trick: Follow the request path.
Q50. CPU utilization suddenly reaches 100% on production servers. How do you investigate?
Simple Concept: Determine which process is consuming CPU and what changed around the time of the spike.
💻 Commands:
top
ps aux --sort=-%cpu | head
uptime
vmstat 1🏢 Investigation: Correlate CPU with traffic, recent deployments, background jobs, application threads, and downstream latency. Determine whether the issue is isolated to one host or affects the fleet.
🚨 Common Interview Trap: Adding servers may help with a traffic-driven problem but may not fix an infinite loop or inefficient code path.
🎯 Candidate-Style Answer: “I identify the top CPU consumers, correlate utilization with traffic and recent changes, check application and system metrics, and choose a fix based on the evidence.”
🧠 Memory Trick: Identify → Correlate → Diagnose → Mitigate.
Q51. One Availability Zone goes down. How does the application continue serving users?
🧠 Simple Concept: Multi-AZ architecture spreads critical components across independent Availability Zones to reduce the impact of a single-zone failure.
🏢 Production Example: A load balancer distributes traffic across healthy application instances in multiple AZs. If one AZ becomes unavailable, health checks and routing can direct traffic to healthy targets elsewhere, provided sufficient capacity remains.
⚙️ Important considerations:
Run sufficient application capacity across multiple AZs.
Configure health checks and traffic routing.
Ensure databases and storage meet availability requirements.
Check dependencies that may still be single-zone.
Monitor capacity after the failure.
Test recovery procedures.
🚨 Common Interview Trap: Multi-AZ deployment does not guarantee uninterrupted service. Capacity, stateful dependencies, configuration, and failover behavior all matter.
🎯 Candidate-Style Answer: “I design the application across multiple Availability Zones, use health checks and load balancing, and ensure critical dependencies have suitable redundancy. I also test failure scenarios and confirm that remaining capacity can handle the workload.”
🧠 Memory Trick: Redundancy + Health Checks + Capacity + Tested Recovery.
🎯 How to Prepare for Your Capgemini DevOps Interview
Do not try to memorize all 51 answers word for word. Interviewers can change the wording, add a production scenario, or ask you to explain why you chose a particular solution.
Instead, prepare each topic using this eight-step framework:
🧠 Simple Concept: Explain it in plain language.
❓ Why We Need It: Identify the problem it solves.
⚙️ How It Works: Explain the basic mechanism.
🏢 Production Example: Connect it to a real engineering situation.
💻 Command / YAML: Demonstrate how you would use it.
🚨 Common Interview Trap: Explain a misconception or risk.
🎯 Candidate-Style Answer: Practise a clear, natural response.
🧠 Memory Trick: Use a short reminder to reinforce the concept.
Final Takeaways 🚀
The strongest DevOps candidates don’t just list technologies. They explain the architecture, justify their decisions, investigate failures systematically, and understand the risks of their fixes.
For every tool on your resume, be ready to explain:
What you used it for.
Why you selected it.
How it connected to other components.
What failed and how you investigated it.
How you validated the fix.
What you changed to prevent recurrence.
Learn the concepts. Practise the commands. Build real projects. Explain your reasoning.
That is how you move from memorizing interview answers to demonstrating practical DevOps engineering skills.
🔖Hashtags
#Capgemini #CapgeminiInterview #DevOps #DevOpsEngineer #DevOpsInterview #Linux #Git #Docker #Kubernetes #Jenkins #AWS #Terraform #CI_CD #CloudComputing #DevSecOps #SRE #InterviewPreparation #PlatformEngineering
👨💻 Follow Me
If you enjoyed this article and want 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