mailwal

PTC Senior DevOps Engineer Interview Preparation: 24 Questions With Real-World Scenarios, Commands & Answers

Arvind Verma

PTC Senior DevOps Engineer Interview Preparation: 24 Questions With Real-World Scenarios, Commands & Answers

AWS | Kubernetes | EKS | Docker | Terraform | CI/CD | DevSecOps | Production Troubleshooting

Preparing for a Senior DevOps Engineer interview at PTC?

Knowing definitions is only the beginning. At the senior level, interviewers want to understand how you design infrastructure, troubleshoot production failures, secure cloud environments, and make decisions when things go wrong.

This guide covers 24 PTC-style interview practice questions across two rounds. Every question follows a consistent learning framework with simple explanations, practical implementation, production examples, common interview traps, spoken answers, and memory tricks.

Disclaimer: These are practice questions based on the supplied question list, not independently verified questions from an official PTC interview.

Round 1: Fundamentals, Architecture & DevOps Tools

Q1. Explain your project architecture and CI/CD pipeline.

Simple Concept

Project architecture explains how application components, infrastructure, networking, security, and deployment processes work together. CI/CD automates the journey from source code to a tested and deployed application.

Why Do We Need It?

A repeatable pipeline reduces manual errors, improves release consistency, and makes deployments easier to audit and troubleshoot.

How Does It Work?

Developer → Git → CI Pipeline → Tests → Security Scans → Docker Image → Amazon ECR → Kubernetes → Monitoring.

Terraform can provision infrastructure, while Argo CD can manage Kubernetes deployments using GitOps.

Production Example

A developer submits a pull request. After review, the pipeline runs tests, scans the code, builds a Docker image, pushes it to ECR, and deploys the approved version to EKS. Monitoring verifies application health.

Command / YAML

git push origin feature/payment-api
docker build -t payment-api:v1 .
docker push <registry-url>/payment-api:v1
kubectl rollout status deployment/payment-api

Common Interview Trap

Listing tools without explaining how they connect. Be ready to discuss failed builds, security checks, rollback strategies, and your personal contribution.

Candidate-Style Answer

“In my project, developers commit code to Git, which triggers the CI pipeline. We run tests and security checks, build a Docker image, and push it to the container registry. The deployment process updates Kubernetes, and monitoring helps us validate the release. Terraform manages infrastructure, while access controls and rollback procedures improve reliability.”

Adapt this answer to your actual experience.

Memory Trick

CODE → TEST → SECURE → PACKAGE → DEPLOY → MONITOR.

Q2. What is Docker? What is the difference between an image and a container?

Simple Concept

A Docker image is a packaged template containing an application and its dependencies. A container is an instance created from that image.

Why Do We Need It?

Containers help applications run consistently across development, testing, and production environments.

How Does It Work?

A Dockerfile defines build instructions. Docker creates an image, and a container runtime starts a container from that image.

Production Example

An application works on a developer’s laptop but fails on a server because dependencies differ. Packaging the application and its dependencies into an image reduces these inconsistencies.

Command / YAML

docker build -t payment-api:v1 .
docker run -d --name payment-api payment-api:v1
docker ps
docker logs payment-api
docker inspect payment-api

Common Interview Trap

A container is not a full virtual machine. Containers share the host operating system kernel, with isolation provided by operating-system and runtime mechanisms.

Candidate-Style Answer

“An image is a versioned package containing the application and its dependencies. A container is an instance created from that image. I build images using Dockerfiles, store them in a registry, and deploy them through a platform such as Kubernetes.”

Memory Trick

Image = Package. Container = Instance.

Q3. What is Kubernetes? Explain its architecture.

Simple Concept

Kubernetes orchestrates containerized applications by managing scheduling, scaling, networking, and workload recovery.

Why Do We Need It?

Manually managing containers becomes difficult when applications have multiple replicas, many services, and changing traffic.

How Does It Work?

The control plane includes the API server, scheduler, controller manager, and etcd. Worker nodes run workloads using kubelet, a container runtime, and networking components.

Production Example

An EKS cluster runs multiple replicas of an API. If a pod fails, Kubernetes attempts to restore the desired replica count, provided capacity and other requirements are available.

Command / YAML

kubectl get nodes
kubectl get pods -A
kubectl get deployments
kubectl describe pod <pod-name>
kubectl get events --sort-by=.lastTimestamp

Common Interview Trap

Kubernetes does not guarantee that an application will always be healthy. Bad configuration, insufficient capacity, failing dependencies, and incorrect probes can still cause outages.

Candidate-Style Answer

“Kubernetes maintains the desired state of containerized workloads. The API server receives configuration, the scheduler places pods on suitable nodes, and controllers reconcile actual state with the desired state. With EKS, AWS manages the control plane, while we manage workloads, access, and operational reliability.”

Memory Trick

API Server → Scheduler → Node → Pod → Application.

Q4. What are a Pod, Service, and Deployment?

Simple Concept

A Pod runs containers. A Deployment manages replicated stateless pods and updates. A Service provides a stable network endpoint for accessing selected pods.

Why Do We Need It?

Pods can be recreated and receive different IP addresses. Deployments maintain replicas, while Services provide stable discovery and connectivity.

How Does It Work?

A Deployment manages ReplicaSets that maintain the required pods. A Service selects matching pods using labels and routes traffic to eligible endpoints.

Production Example

A payment API has three replicas. The Deployment maintains the replicas, while a ClusterIP Service provides a stable endpoint for internal requests.

Command / YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: payment-api
  template:
    metadata:
      labels:
        app: payment-api
    spec:
      containers:
        - name: api
          image: nginx:stable
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: payment-api
spec:
  selector:
    app: payment-api
  ports:
    - port: 80
      targetPort: 80

The image is a demonstration placeholder, not a payment application.

Common Interview Trap

A Service does not automatically make an application publicly accessible. External access may require an Ingress, Gateway, LoadBalancer Service, or another networking configuration.

Candidate-Style Answer

“A Pod runs the container, a Deployment manages replicas and updates, and a Service provides a stable endpoint to access matching pods. I troubleshoot connectivity by checking labels, selectors, ports, readiness, and endpoints.”

Memory Trick

Deployment manages. Pod runs. Service connects.

Q5. Explain Rolling, Blue-Green, and Canary deployments.

Simple Concept

These strategies control how a new application version replaces or coexists with the existing version.

Why Do We Need It?

They reduce release risk and provide different ways to control traffic, validate releases, and recover from failures.

How Does It Work?

  • Rolling: replaces instances gradually.

  • Blue-Green: switches traffic between two environments.

  • Canary: exposes a small portion of traffic to the new version before expanding.

Production Example

A payment service releases a canary version to a small portion of traffic. Engineers compare latency and errors before increasing exposure.

Command / YAML

kubectl rollout status deployment/payment-api
kubectl rollout history deployment/payment-api
kubectl rollout undo deployment/payment-api

Common Interview Trap

Rolling back application containers does not automatically reverse database migrations or external side effects. Compatibility and data recovery require separate planning.

Candidate-Style Answer

“I choose the deployment strategy based on risk, traffic, and recovery requirements. Rolling deployments are straightforward, blue-green provides a controlled traffic switch, and canary releases help validate changes with limited exposure. I monitor health metrics and ensure rollback is safe.”

Memory Trick

Rolling = Gradual. Blue-Green = Switch. Canary = Limited Exposure First.

Q6. What is Terraform? What is a state file?

Simple Concept

Terraform manages infrastructure through declarative configuration. Its state file records the relationship between Terraform-managed resources and real infrastructure.

Why Do We Need It?

Infrastructure becomes repeatable, reviewable, and easier to manage across environments.

How Does It Work?

Terraform reads configuration and state, calculates a plan, and applies approved changes.

Production Example

A team provisions VPCs, subnets, security groups, and EKS infrastructure using reusable Terraform modules and a protected remote backend.

Command / YAML

terraform init
terraform fmt
terraform validate
terraform plan
terraform apply
terraform state list

Common Interview Trap

State may contain sensitive information. Protect it with access controls, encryption, secure storage, and locking where supported.

Candidate-Style Answer

“Terraform allows us to manage infrastructure as code. The state file tracks managed resources and helps calculate changes. In team environments, I use a secure remote backend, controlled access, and state locking where supported.”

Memory Trick

Configuration = Desired State. State File = Resource Record. Plan = Proposed Changes.

Q7. What is the difference between public and private subnets in AWS?

Simple Concept

A public subnet has a route to an Internet Gateway. A private subnet does not have direct internet routing through an Internet Gateway.

Why Do We Need It?

Subnet design helps control exposure and separates public entry points from internal workloads.

How Does It Work?

Public resources may be internet reachable when routing, addressing, and security controls permit it. Private resources may use a NAT Gateway or another controlled path for outbound access.

Production Example

An internet-facing Application Load Balancer uses public subnets, while application workloads and databases run in private subnets.

Command / YAML

aws ec2 describe-route-tables
aws ec2 describe-subnets
aws ec2 describe-security-groups

Common Interview Trap

A subnet being called public does not automatically make every resource publicly accessible. Addressing, routes, and security controls also matter.

Candidate-Style Answer

“I use public subnets for approved internet-facing entry points and private subnets for internal workloads. I control traffic through route tables, security groups, network ACLs, and appropriate egress paths.”

Memory Trick

Public = Internet Route. Private = No Direct Internet Gateway Route.

Q8. What is IAM? What is the difference between a role and a policy?

Simple Concept

AWS Identity and Access Management controls access to AWS resources. A policy defines permissions, while a role is an identity that trusted principals can assume.

Why Do We Need It?

Least-privilege access reduces the risk of unauthorized operations and compromised credentials.

How Does It Work?

A role has a trust policy defining who can assume it and permission policies defining what the role can do.

Production Example

An application running on EC2 assumes an IAM role to access a specific S3 bucket without storing long-lived access keys in its code.

Command / YAML

aws sts get-caller-identity
aws iam get-role --role-name AppRole
aws iam list-attached-role-policies --role-name AppRole

Common Interview Trap

A role and a policy are not interchangeable. Trust controls who can assume a role; permission policies control allowed actions.

Candidate-Style Answer

“I use IAM roles to provide identities to trusted users and workloads, and policies to define permissions. I follow least privilege and prefer temporary credentials over hardcoded access keys.”

Memory Trick

Trust Policy = Who Can Assume. Permission Policy = What They Can Do.

Q9. What is a load balancer, and how does it work?

Simple Concept

A load balancer distributes incoming traffic across eligible targets.

Why Do We Need It?

It supports traffic distribution, health-based routing, and application availability.

How Does It Work?

The load balancer receives requests, applies listener and routing rules, and forwards eligible traffic to healthy targets.

Production Example

An AWS Application Load Balancer terminates HTTPS and routes requests to healthy application targets.

Command / YAML

aws elbv2 describe-load-balancers
aws elbv2 describe-target-health \
  --target-group-arn <target-group-arn>

Common Interview Trap

A healthy load balancer does not guarantee that the entire application is healthy. Downstream services can still fail.

Candidate-Style Answer

“A load balancer distributes requests across targets based on routing configuration and health checks. I investigate listener rules, target health, security groups, response codes, and access logs when traffic fails.”

Memory Trick

Receive → Evaluate → Route → Check Health.

Q10. What is a Git branching strategy?

Simple Concept

A branching strategy defines how code changes are developed, reviewed, integrated, and released.

Why Do We Need It?

It helps teams collaborate, manage releases, and reduce integration problems.

How Does It Work?

Teams may use short-lived feature branches, trunk-based development, or Git Flow depending on release and compliance requirements.

Production Example

A team uses protected main branches, mandatory reviews, automated tests, and short-lived feature branches to reduce merge conflicts.

Command / YAML

git switch -c feature/payment-api
git add .
git commit -m "Add payment API"
git push -u origin feature/payment-api

Common Interview Trap

There is no single branching strategy for every team. Long-lived branches can increase merge conflicts and delay integration.

Candidate-Style Answer

“I choose a branching model based on release frequency and team needs. I use pull requests, automated tests, and branch protections to maintain quality. For frequent releases, I prefer small changes and short-lived branches.”

Memory Trick

Branch → Review → Test → Merge → Release.

Q11. How do you monitor applications in production?

Simple Concept

Monitoring measures system health and helps teams detect failures, performance degradation, and capacity problems.

Why Do We Need It?

Without monitoring, teams may discover problems only after customers report them.

How Does It Work?

Metrics show trends, logs record events, traces follow requests across components, and alerts notify teams when defined conditions occur.

Production Example

An application has normal CPU utilization but increasing p95 latency. Distributed tracing reveals that database queries are taking longer.

Command / YAML

kubectl top nodes
kubectl top pods -A
kubectl get events -A --sort-by=.lastTimestamp
kubectl logs deployment/my-app --since=15m

Common Interview Trap

A green dashboard does not prove that users are having a good experience. Monitor latency percentiles, error rates, and important user journeys.

Candidate-Style Answer

“I monitor availability, request rate, latency, error rates, and resource utilization. I use metrics, logs, and traces together to investigate issues, then configure actionable alerts around service-level objectives.”

Memory Trick

Metrics = Trends. Logs = Events. Traces = Request Journey.

Q12. What is DNS, and how does it work?

Simple Concept

DNS translates domain names into records such as IP addresses.

Why Do We Need It?

Users and applications can access services through stable names instead of relying on manually managed IP addresses.

How Does It Work?

A resolver checks its cache and, when necessary, queries DNS servers to obtain the requested record. TTL values influence how long answers may be cached.

Production Example

After a migration, users cannot reach an application because a DNS record points to the wrong destination or cached records have not expired.

Command / YAML

dig example.com
nslookup example.com

Common Interview Trap

Successful DNS resolution does not prove that the destination application is healthy or reachable.

Candidate-Style Answer

“DNS resolves names to records used by clients to locate services. When troubleshooting, I check the returned record, TTL, resolver behavior, target address, and connectivity to the destination.”

Memory Trick

Name → DNS Resolution → Record → Destination.

Round 2: AWS, EKS, CI/CD, Security & Troubleshooting

Q13. How do you scale an application in Kubernetes?

Simple Concept

Kubernetes can scale an application by increasing pod replicas or adjusting them automatically based on metrics.

Why Do We Need It?

Scaling helps applications handle changing workloads while maintaining responsiveness.

How Does It Work?

The Horizontal Pod Autoscaler adjusts replica counts based on configured metrics. Cluster autoscaling mechanisms can add or remove node capacity when needed.

Production Example

A web application experiences a traffic spike. HPA increases replicas, while the cluster’s capacity-management mechanism ensures additional pods can be scheduled.

Command / YAML

kubectl autoscale deployment my-app \
  --cpu-percent=70 \
  --min=2 \
  --max=10

kubectl get hpa
kubectl describe hpa my-app

CPU-based scaling requires appropriate resource requests, metrics availability, and sufficient cluster capacity.

Common Interview Trap

HPA scales pods, not nodes. More replicas will not help if the cluster cannot schedule them or the bottleneck is a database.

Candidate-Style Answer

“I use HPA to scale replicas based on workload metrics and ensure that node capacity can accommodate additional pods. I also check resource requests, limits, application latency, and downstream dependencies to confirm that scaling actually improves performance.”

Memory Trick

HPA = Pod Replicas. Node Autoscaling = Cluster Capacity.

Q14. How do you secure container images in Kubernetes?

Simple Concept

Container security covers image creation, vulnerability detection, deployment controls, and runtime restrictions.

Why Do We Need It?

Vulnerable images, embedded secrets, and excessive container privileges can expose production workloads.

How Does It Work?

Use trusted base images, scan vulnerabilities, pin versions, verify provenance where supported, restrict privileges, and enforce admission policies.

Production Example

A critical vulnerability is discovered in a deployed image. The team identifies affected workloads, builds a patched image, tests it, deploys it safely, and verifies that vulnerable instances are replaced.

Command / YAML

trivy image my-app:v1
kubectl get pods -A -o wide
kubectl rollout status deployment/my-app

Common Interview Trap

A vulnerability scan alone does not secure production. Detection must be connected to remediation and verification.

Candidate-Style Answer

“I use trusted base images, scan images in CI/CD, avoid embedding secrets, and apply least-privilege runtime settings. If a critical vulnerability appears, I identify affected workloads, patch and test the image, deploy through a controlled rollout, and verify the replacement.”

Memory Trick

Build Secure → Scan → Verify → Deploy → Monitor.

Q15. What is the role of Amazon CloudFront?

Simple Concept

Amazon CloudFront is a content delivery network that serves content through edge locations closer to users.

Why Do We Need It?

It can reduce latency, cache eligible content, lower origin request volume, and improve content delivery.

How Does It Work?

CloudFront receives requests, applies cache behavior and routing rules, and serves cached content or retrieves it from the configured origin.

Production Example

A web application delivers images, stylesheets, and JavaScript through CloudFront while the origin remains hosted in AWS.

Command / YAML

aws cloudfront list-distributions
aws cloudfront get-distribution \
  --id <distribution-id>

Common Interview Trap

CloudFront does not automatically make every request faster. Cacheability, origin latency, request patterns, and configuration all matter.

Candidate-Style Answer

“I use CloudFront to deliver eligible content closer to users and reduce repeated origin requests. I configure cache behaviors, origin access, HTTPS, and security controls, then monitor cache performance and origin latency.”

Memory Trick

User → Edge Location → Cache or Origin.

Q16. How would you design disaster recovery for Amazon RDS?

Simple Concept

Disaster recovery prepares a database environment to recover from failures, data loss, or regional outages.

Why Do We Need It?

Organizations need to limit downtime and data loss when a database becomes unavailable or data is corrupted.

How Does It Work?

Start with Recovery Time Objective (RTO) and Recovery Point Objective (RPO). Use automated backups and point-in-time recovery, Multi-AZ for availability, and cross-Region backups or replicas when required.

Production Example

A critical application requires regional recovery. The team maintains cross-Region recovery resources, documents promotion or restoration steps, and regularly tests recovery.

Command / YAML

aws rds describe-db-instances

aws rds describe-db-snapshots \
  --db-instance-identifier <db-identifier>

Common Interview Trap

Multi-AZ improves availability but is not a complete regional disaster recovery plan or a replacement for backups.

Candidate-Style Answer

“I would establish RTO and RPO requirements, then choose backups, Multi-AZ, cross-Region recovery, or a combination. I would secure recovery resources, document the procedure, and test restoration and failover regularly.”

Memory Trick

RTO = Recovery Time. RPO = Acceptable Data Loss.

Q17. A developer cannot access an S3 bucket. What will you check?

Simple Concept

S3 access depends on identity, permissions, bucket configuration, encryption, and network restrictions.

Why Do We Need It?

Correct diagnosis prevents unnecessary permission changes and avoids granting excessive access.

How Does It Work?

AWS evaluates the request using applicable identity and resource policies, organizational controls, permissions boundaries, session policies, encryption permissions, and other restrictions.

Production Example

A developer can list a bucket but cannot download an encrypted object because the identity lacks the necessary KMS permissions.

Command / YAML

aws sts get-caller-identity
aws s3 ls s3://my-example-bucket/

Then inspect the relevant IAM and bucket policies, KMS permissions, VPC endpoint policy, and access-denied logs where available.

Common Interview Trap

Listing a bucket and downloading an object require different permissions. Do not grant broad access simply to remove an error.

Candidate-Style Answer

“I would confirm the developer’s identity and reproduce the exact failing operation. Then I would check IAM permissions, bucket policy, explicit denies, KMS access, and network restrictions. I would apply the smallest required permission change and verify the fix.”

Memory Trick

Identity → Permissions → Resource Policy → Encryption → Network.

Q18. You are facing latency issues in an EKS cluster. How do you troubleshoot?

Simple Concept

Latency can originate from the application, pods, nodes, networking, or downstream dependencies.

Why Do We Need It?

Finding the correct layer prevents ineffective changes, such as adding nodes when the real problem is a slow database.

How Does It Work?

Correlate latency metrics, traces, logs, resource usage, scheduling events, network behavior, and recent deployments.

Production Example

Pods are running, but application response time increases because CPU throttling or slow database queries delay requests.

Command / YAML

kubectl get nodes
kubectl get pods -A -o wide
kubectl top nodes
kubectl top pods -A
kubectl get events -A --sort-by=.lastTimestamp
kubectl get services -A
kubectl get endpointslices -A

Common Interview Trap

Increasing node count before identifying the bottleneck. More nodes will not automatically fix inefficient code, incorrect probes, or slow downstream services.

Candidate-Style Answer

“I would establish the scope of the latency and compare request metrics with recent changes. Then I would inspect application traces, pod resource usage, node health, scheduling, Services, and downstream dependencies. I would fix the confirmed bottleneck and verify latency improvements.”

Memory Trick

Application → Pods → Nodes → Network → Dependencies.

Q19. AWS Lambda is failing internally. What are your debugging steps?

Simple Concept

Lambda failures may result from code errors, timeouts, throttling, permissions, initialization problems, or downstream dependencies.

Why Do We Need It?

A structured investigation distinguishes application defects from configuration and infrastructure issues.

How Does It Work?

CloudWatch logs and metrics reveal error patterns, execution duration, throttling, concurrency, and invocation behavior.

Production Example

A Lambda function cannot connect to an RDS database after a networking change. Logs show connection timeouts, directing the investigation toward VPC configuration, routing, security groups, and database reachability.

Command / YAML

aws lambda get-function-configuration \
  --function-name my-function

aws logs tail /aws/lambda/my-function \
  --since 15m

Common Interview Trap

Increasing the timeout without investigating whether the function is stuck on a dependency or repeatedly retrying a failing operation.

Candidate-Style Answer

“I would identify the failure type from CloudWatch logs and metrics, then check recent code changes, execution-role permissions, memory and timeout settings, VPC connectivity, and downstream dependencies. After correcting the confirmed cause, I would test the function and monitor its error rate.”

Memory Trick

Logs → Metrics → Permissions → Network → Dependencies.

Q20. A CI/CD pipeline cannot connect to GitLab. What will you check?

Simple Concept

The failure may involve authentication, DNS, network connectivity, TLS certificates, runner configuration, or GitLab availability.

Why Do We Need It?

Pipelines depend on external services, and failures can occur even when pipeline configuration has not changed.

How Does It Work?

Reproduce the failure from the runner environment and isolate DNS, connectivity, TLS, and authentication separately.

Production Example

A runner suddenly cannot clone a repository because its access token expired or a network proxy configuration changed.

Command / YAML

git ls-remote https://gitlab.example.com/team/app.git
curl -Iv https://gitlab.example.com
nslookup gitlab.example.com

Common Interview Trap

Assuming that unchanged pipeline YAML means nothing changed. Credentials, certificates, network routes, and external services may change independently.

Candidate-Style Answer

“I would reproduce the failure from the runner and inspect the first failing step. Then I would check DNS, TLS, network connectivity, token validity, SSH configuration, and runner logs. I would validate access after the fix without exposing credentials in logs.”

Memory Trick

DNS → Network → TLS → Authentication → Repository Permissions.

Q21. Kubernetes is not able to expose a Pod. What could be the issue?

Simple Concept

A Pod may be running but unreachable because of incorrect labels, Service selectors, ports, readiness, network policies, or external routing.

Why Do We Need It?

Applications need correct service discovery and network configuration to receive traffic.

How Does It Work?

A Service selects matching pods and exposes a stable endpoint. External traffic may pass through an Ingress, Gateway, or cloud load balancer.

Production Example

The Service selector expects app: payment-api, but the pods use app: payments-api. The Service therefore has no matching endpoints.

Command / YAML

kubectl get pods --show-labels
kubectl get svc
kubectl describe svc my-service
kubectl get endpointslices
kubectl get ingress

Common Interview Trap

A Service object existing does not prove that traffic can reach the application.

Candidate-Style Answer

“I would verify that the application listens on the expected port, then check pod labels, Service selectors, target ports, readiness probes, EndpointSlices, and network policies. If external access is involved, I would also inspect Ingress or load balancer health and routing.”

Memory Trick

Pod Labels → Service Selector → Endpoint → Route.

Q22. Pods are running, but users are getting 503 errors. How do you debug?

Simple Concept

HTTP 503 indicates that a service is temporarily unable to handle a request. The exact cause depends on which component returns the response.

Why Do We Need It?

Running pods do not guarantee that requests can reach healthy application endpoints.

How Does It Work?

Trace the request path from the client through DNS, load balancer, Ingress or Gateway, Service, Pod, and downstream dependencies.

Production Example

All pods show Running, but readiness probes fail. Kubernetes removes the pods from eligible Service endpoints, and the Ingress controller returns 503 because no usable endpoints remain.

Command / YAML

kubectl get pods -o wide
kubectl get svc
kubectl get endpointslices
kubectl get ingress
kubectl logs deployment/my-app --since=15m

Common Interview Trap

Restarting pods without checking which component generates the 503. The cause may be an empty endpoint list, incorrect routing, or a failed downstream dependency.

Candidate-Style Answer

“I would identify which component returns the 503 and trace the request path. I would inspect load balancer target health, Ingress logs, Service endpoints, readiness probes, and application dependencies. After fixing the root cause, I would verify successful requests and monitor error rates.”

Memory Trick

503 → Identify Responder → Trace Route → Check Endpoints → Verify.

Q23. Terraform apply failed midway. How do you recover safely?

Simple Concept

A failed Terraform apply does not necessarily roll back every infrastructure change. Some resources may already have been created or modified.

Why Do We Need It?

Blind retries or manual deletion can make infrastructure and Terraform state inconsistent.

How Does It Work?

Inspect the failure, determine which resources changed, compare actual infrastructure with state, correct the cause, and review a fresh plan before applying again.

Production Example

Terraform creates a VPC and some subnets but fails while creating a later resource because of an IAM permission error. The existing resources may remain and need to be reconciled before another apply.

Command / YAML

terraform state list
terraform show
terraform plan

Common Interview Trap

Assuming that a failed apply means nothing changed. Never edit state manually or delete resources blindly without a verified recovery plan.

Candidate-Style Answer

“I would inspect the error and determine which resources were successfully changed. I would compare Terraform state with the actual infrastructure, resolve the underlying issue, and generate a new plan. I would apply only after reviewing the proposed changes and confirming there are no unexpected replacements or deletions.”

Memory Trick

Inspect → Reconcile → Plan → Review → Apply.

Q24. How do you handle secrets securely across multiple environments?

Simple Concept

Secrets include database passwords, API tokens, certificates, and credentials that must be protected from unauthorized access.

Why Do We Need It?

Exposed secrets can allow attackers to access applications, databases, and cloud infrastructure.

How Does It Work?

Use a dedicated secret manager, environment-specific permissions, encryption, short-lived credentials where possible, controlled delivery, and auditing.

Production Example

An application running in EKS assumes an appropriate workload IAM role and retrieves only the secrets it needs through an approved secret-management integration.

Command / YAML

aws secretsmanager describe-secret \
  --secret-id production/database

aws secretsmanager get-secret-value \
  --secret-id production/database

Use secret retrieval commands only with appropriate authorization. Avoid exposing secret values in terminal recordings, shell history, CI logs, or shared output.

Common Interview Trap

Kubernetes Secret objects are not automatically secure merely because they are called Secrets. Access controls, encryption at rest, workload permissions, and safe delivery all matter.

Candidate-Style Answer

“I centralize secrets in an approved secret manager, separate access by environment, and use IAM roles with least privilege. I avoid storing credentials in source code, container images, or logs. I also implement rotation, auditing, and controlled access to reduce exposure.”

Memory Trick

Store Securely → Restrict Access → Deliver Safely → Rotate → Audit.

Final Interview Preparation Checklist

For every question, practise explaining the reasoning rather than memorizing the wording.

Be ready to describe:

  • What problem you are solving.

  • What evidence you would collect first.

  • Which commands, logs, metrics, or configurations you would inspect.

  • How you would isolate the root cause.

  • Which recovery option is safest.

  • How you would verify the fix.

  • How you would prevent recurrence.

For scenario-based questions, follow this sequence:

ASSESS IMPACT → COLLECT EVIDENCE → ISOLATE ROOT CAUSE → RECOVER SAFELY → VERIFY → PREVENT RECURRENCE

For senior-level interviews, also explain trade-offs, security implications, availability requirements, rollback risks, and communication during incidents.

You do not need to memorize every command. You need to demonstrate structured thinking, practical technical knowledge, and sound production judgment.

The goal is not just to know AWS, Kubernetes, Docker, Jenkins, or Terraform. It is to understand how systems behave when something breaks and how to restore them safely.


About the Author

Arvind Verma | Senior DevOps Engineer

🔗 LinkedIn: https://www.linkedin.com/in/arvindverma021/

📚 DevOps Learning Resources: https://topmate.io/arvindverma021/

📝 Medium: https://medium.com/@arvindverma021/

📬 Substack:

Tags

#PTC #DevOps #SeniorDevOpsEngineer #DevOpsInterview #AWS #Kubernetes #AmazonEKS #Terraform #Docker #CICD #DevSecOps #CloudEngineering #SRE #ProductionTroubleshooting

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.

Pledge your support

© 2026 Arvind Verma
548 Market Street PMB 72296, San Francisco, CA 94104