1.
worked only on operations projects, or have they been involved in greenfield projects
as well?
Answer : i worked both type of project Operations Projects and Greenfield Projects
2. Have you worked on any migration projects? If yes, what was their role and level of
responsibility?
Answer: Yes, I have worked on migration projects involving Azure, AWS, and DevSecOps tools.
My role included planning and executing the migration of on-premise applications to cloud
platforms like Azure and AWS, while designing CI/CD pipelines using Azure DevOps. I was
responsible for integrating security tools like SonarQube and Dependabot to ensure code quality
and vulnerability management during the migration process
3. provide examples of networking challenges they faced and how they resolved them?
Answer:
Challenge: Intermittent Network Disruptions During Cloud Integration
In one of our cloud integration projects, we experienced intermittent network disruptions when
connecting on-premise servers to AWS, impacting application performance. The issue was
caused by inconsistent VPN tunnel stability. To resolve this, we switched to AWS Direct
Connect for a dedicated, private connection, ensuring higher bandwidth and reliable
connectivity.
Challenge: Cross-Region Latency in Global Web Applications
A global e-commerce platform hosted on AWS experienced significant latency issues as users
in different regions were accessing the same centralized database. To address this, we
implemented AWS Global Accelerator and replicated the database across multiple regions,
ensuring faster access for users by routing traffic to the nearest regional endpoint.
Challenge: DNS Resolution and Service Discovery Issues in Microservices
During the migration of monolithic applications to a microservices architecture on Kubernetes,
our team faced challenges with DNS resolution and service discovery between services hosted
in different namespaces. This resulted in failed connections between services. The problem was
fixed by configuring CoreDNS for intra-cluster service discovery and implementing Consul for
multi-cluster service discovery.
Challenge: Insecure Communication Between Multi-Cloud Resources
In a multi-cloud setup with both Azure and AWS, there was a security concern when data was
transmitted between the two clouds, as the communication was not fully encrypted. To resolve
this, we implemented IPsec VPN tunnels between the two clouds and enforced mutual TLS
(mTLS) for all internal service communications, ensuring secure and encrypted data transfer
between cloud environments.
Challenge: Network Congestion and Throttling During High Traffic Periods
A critical service running in Azure faced network congestion issues during peak usage periods,
resulting in throttling and slower response times. To mitigate this, we implemented Azure
Traffic Manager and Azure Load Balancer to distribute the traffic more effectively across
multiple instances, reducing congestion and improving service reliability.
4. How familiar are they with managing OpenShift clusters?
Answer I am familiar with kubernetes cluster
5. What DevOps tools you have worked with?
Answer: Experience in Build, Deployment, Cloud, Configuration Management, Infrastructure,
and Automation tools like TFS, Azure-Devops, GIT, GithubActions, Sonarqube,
Bitbucket, Maven, Jenkins, Argocd, Docker, Octopus, Apache Tomcat, IIS, WIX,
Kubernetes, Lens, Dynatrace, New-relic, Splunk, PDN(Pega), Jmeter Azure-cloud, AWS,
PowerShell Scripting, Ansible, Terraform, Windows and Linux environments.
6. In a YAML file, what stages do they typically include for a CD pipeline?
Answer: Configure the environment, Build, Test, deployment, post-deployment
7. explain the Kubernetes architecture and the services involved?
Answer:
1. Control Plane (Master Node)
The control plane is responsible for managing the Kubernetes cluster. It makes global decisions
(like scheduling), and monitors and maintains the cluster's desired state.
API Server (kube-apiserver): The API server is the front-end of the control plane. It
serves the Kubernetes API and acts as the main interface for interacting with the cluster.
All the commands you run (kubectl) interact with the API server.
Controller Manager (kube-controller-manager): It ensures that the cluster’s desired
state matches the actual state. For example, it ensures that the desired number of pod
replicas are running, or if a node goes down, it schedules new pods.
Scheduler (kube-scheduler): The scheduler watches for newly created pods that have
no assigned node and selects an appropriate node for them to run on based on resource
availability, constraints, and other factors.
etcd: A consistent and highly-available key-value store used by Kubernetes to store all
cluster data, including the configuration data, cluster state, and metadata.
Cloud Controller Manager (cloud-controller-manager): It integrates with the cloud
provider’s API to manage cloud-specific resources, like load balancers, volumes, and
network routes.
2. Node (Worker Node)
Nodes are the machines (either physical or virtual) that run the application workloads in the form
of containers.
Kubelet: An agent that runs on each node in the cluster. It ensures that containers are
running in a pod and takes care of reporting node status to the control plane.
Kube Proxy: A network proxy that maintains network rules for pod communication. It
enables communication between services, routing traffic to the appropriate pod based
on service discovery.
Container Runtime: This is the software responsible for running containers. Common
container runtimes include Docker, containerd, and CRI-O.
8. List a few basic commands.
Get Cluster Info
kubectl cluster-info
Get All Resources in the Current Namespace
kubectl get all
Get Pods
kubectl get pods
Get Nodes
kubectl get nodes
Get Services
kubectl get services
Create a Resource from a YAML File
kubectl apply -f <[Link]>
Get Pod Logs
kubectl logs <pod-name>
Describe a Resource (Pod, Node, etc.)
kubectl describe pod <pod-name>
Delete a Resource
kubectl delete pod <pod-name>
Execute a Command Inside a Running Pod
kubectl exec -it <pod-name> -- <command>
Scale a Deployment
kubectl scale deployment <deployment-name> --replicas=<number>
View Resource Usage (CPU and Memory)
kubectl top pod
9. familiar with creating Docker images from code and orchestrating applications?
Yes I am familiar with creating Docker images from code orchestrating applications
I am familiar with creating Docker images from code by writing Dockerfiles to define the build
process, dependencies, and application configurations. Additionally, I have experience
orchestrating multi-container applications using tools like Docker Compose and Kubernetes to
manage and scale services efficiently.
[Link] are persistent volumes?
Answer: Persistent Volumes (PVs) in Kubernetes are storage resources that exist independently
of Pods, providing long-term storage that persists across Pod restarts. Users request storage
through Persistent Volume Claims (PVCs), which are then bound to available PVs. PVs can be
backed by various storage systems and are managed through StorageClasses for dynamic
provisioning. Once a PVC is bound to a PV, the storage can be used by Pods by mounting the
PVC as a volume.
11. Explain Terraform Plan and Terraform Execute
Answer: Terraform Plan is a command that generates an execution plan, showing the actions
Terraform will take to reach the desired state of the infrastructure. It compares the current state
with the desired configuration and provides a preview of changes like resource creation,
modification, or deletion. Terraform Apply (often referred to as Terraform Execute) is the
command that actually applies the changes outlined in the plan, provisioning or modifying
resources in the infrastructure to match the desired state. While Terraform Plan is used for
review and validation, Terraform Apply executes the actual changes to the infrastructure.
[Link] on experience in creating and managing Helm Charts:
I have hands-on experience in creating Helm charts to package, configure, and deploy
applications in Kubernetes, ensuring efficient management of deployments. Additionally, I have
worked with Helm to manage releases, version control, and handle complex configurations
using [Link] files and templates.
13. Hands-on experience with ArgoCD:
I have hands-on experience with ArgoCD for continuous delivery and GitOps workflows,
enabling automated deployment of applications to Kubernetes clusters. By integrating ArgoCD
with Git repositories, I’ve managed application configurations, tracked changes, and ensured
consistent deployment across environments.