Devops Interview Questions and Answers

1. What are your typical daily responsibilities in your current role?
   As a DevOps engineer, my typical daily responsibilities include ensuring the smooth operation of our cloud-based infrastructure, deploying and managing applications, monitoring system performance, and collaborating with development teams to implement CI/CD pipelines.
2. Where is your current project hosted?
   My current project is hosted on Amazon Web Services (AWS), using a combination of EC2 instances, RDS databases, and S3 storage.
3. What AWS services have you worked with so far?
   I have worked with a variety of AWS services, including EC2, RDS, S3, Lambda, API Gateway, CloudWatch, and CloudFormation.
4. Do you have practical experience with AWS CloudFormation?
   Yes, I have practical experience with AWS CloudFormation, which I use to define and deploy infrastructure as code.
5. Are you more comfortable using CloudFormation or Terraform?
   I am comfortable using both CloudFormation and Terraform, but I have more experience with CloudFormation.
6. Have you worked with Prometheus and Grafana in your projects?
   Yes, I have worked with Prometheus and Grafana in my projects, using them to monitor system performance and visualize metrics.
7. What tasks related to Prometheus are you currently handling?
   I am currently handling tasks such as configuring Prometheus to scrape metrics from our applications, defining alerts and notifications, and creating dashboards in Grafana to visualize the metrics.
8. Have you ever created a Dockerfile?
   Yes, I have created Dockerfiles to containerize our applications and ensure consistent deployment across different environments.
9. What CI/CD tools have you used in your projects?
   I have used a variety of CI/CD tools, including Jenkins, GitLab CI/CD, and CircleCI.
10. Can you describe the process that occurs when a developer commits code or creates a pull request?
    When a developer commits code or creates a pull request, our CI/CD pipeline is triggered, which includes steps such as building the application, running automated tests, and deploying the application to a staging environment.
11. Where do you usually execute your Dockerfiles?
    I usually execute my Dockerfiles on our CI/CD pipeline, which uses a Docker-in-Docker approach to build and deploy our applications.
12. What is the difference between a Docker image and a container?
    A Docker image is a read-only template that contains the application code and dependencies, while a Docker container is a runtime instance of the image, which can be started, stopped, and managed.
13. If you have a 5GB Docker image but need to deploy it on an EC2 instance with only 2GB of RAM, how would you address this?
    To address this, I would consider options such as optimizing the Docker image to reduce its size, using a smaller base image, or increasing the RAM on the EC2 instance.
14. When working with Terraform, do you generally create modules or scripts?
    I generally create modules when working with Terraform, as they provide a reusable and modular way to define infrastructure.
15. What types of Terraform blocks have you written?
    I have written a variety of Terraform blocks, including resource blocks, data blocks, and output blocks.
16. Can you explain the different Terraform blocks you’ve used?
    Terraform blocks are used to define different types of infrastructure, such as resources, data sources, and outputs. Resource blocks are used to define infrastructure resources, such as EC2 instances or RDS databases. Data blocks are used to retrieve data from external sources, such as AWS IAM roles. Output blocks are used to output values from the Terraform configuration.
17. Why would you use a dynamic block in Terraform?
    I would use a dynamic block in Terraform to create infrastructure resources that depend on dynamic values, such as the number of Availability Zones in a region.
18. What is the difference between a dynamic block and an output block in Terraform?
    A dynamic block is used to create infrastructure resources that depend on dynamic values, while an output block is used to output values from the Terraform configuration.
19. How many environments are you managing?
    I am currently managing 5 environments, including dev, staging, prod, and two additional environments for testing and QA.
20. Does each environment have its own Kubernetes cluster?
    Yes, each environment has its own Kubernetes cluster, which provides a dedicated and isolated environment for deploying and managing applications.
21. How many nodes are there in your Kubernetes clusters?
    In a typical Kubernetes cluster, there can be multiple nodes, which can range from a few to hundreds or even thousands. The number of nodes depends on the specific use case, the size of the application, and the resources required. For example, a small cluster might have 3-5 nodes, while a large cluster might have 100-1000 nodes.
22. What are the specifications for the nodes in your Kubernetes clusters?
    The specifications for the nodes in a Kubernetes cluster can vary depending on the specific requirements of the application. Typically, nodes can be virtual machines (VMs) or physical machines with varying amounts of CPU, memory, and storage. For example, a node might have 2-4 CPU cores, 4-16 GB of memory, and 50-100 GB of storage.
23. How many pods are currently running in your clusters?
    The number of pods running in a Kubernetes cluster can vary depending on the specific application and the number of replicas required. For example, a small application might have 1-5 pods, while a large application might have 100-1000 pods.
24. Are pods allocated to specific nodes?
    Yes, pods are allocated to specific nodes in a Kubernetes cluster. When a pod is created, the Kubernetes scheduler allocates it to a node that has sufficient resources to run the pod. The scheduler takes into account factors such as the node’s available resources, the pod’s resource requirements, and the node’s affinity and anti-affinity rules.
25. If not, why is it still referred to as a cluster?
    Even if pods are allocated to specific nodes, the collection of nodes and pods is still referred to as a cluster because it is a group of machines that work together to provide a service. The cluster provides a shared pool of resources, such as CPU, memory, and storage, that can be allocated to pods as needed.
26. What types of services are you utilizing in Kubernetes?
    In Kubernetes, there are several types of services that can be utilized, including:
    • ClusterIP: a service that is only accessible within the cluster
    • NodePort: a service that is accessible from outside the cluster through a specific port on each node
    • LoadBalancer: a service that is accessible from outside the cluster through a load balancer
    • Ingress: a service that provides a single entry point for incoming HTTP requests
27. Are Kubernetes services exposed to the outside world?
    Yes, Kubernetes services can be exposed to the outside world through various means, such as:
    • NodePort: exposes a service through a specific port on each node
    • LoadBalancer: exposes a service through a load balancer
    • Ingress: provides a single entry point for incoming HTTP requests
    • ExternalIPs: allows a service to be accessed through a specific IP address
28. Have you worked with an Ingress controller in your projects?
    Yes, I have worked with Ingress controllers in my projects. An Ingress controller is a component that provides a single entry point for incoming HTTP requests and routes them to the corresponding services within the cluster. Popular Ingress controllers include NGINX, HAProxy, and Traefik.
29. When writing Kubernetes YAML files, do you specify the kind as Pod, ReplicaSet, or Deployment?
    When writing Kubernetes YAML files, I typically specify the kind as Deployment, which manages both Pods and ReplicaSets. However, I may also specify the kind as Pod or ReplicaSet in certain situations, such as when creating a single pod or a replica set for a specific use case.
30. Why would you use kind: Pod, kind: ReplicaSet, and kind: Deployment in separate YAML files when it seems possible to use only kind: Deployment?
    While it is possible to use only kind: Deployment, there are situations where using kind: Pod or kind: ReplicaSet separately may be necessary or desirable. For example:
    • When creating a single pod for a specific use case, such as a debug pod or a pod for a legacy application.
    • When creating a replica set for a specific use case, such as a replica set for a stateful application.
    • When using a Deployment for a stateless application, but needing to create a separate ReplicaSet for a stateful component.