HICKS PROFESSIONAL GROUP · CATERPILLAR OPPORTUNITY · CHICAGO / IRVING
1. Tell me about yourself
Sure, absolutely.
My name is Elena, and I'm a DevOps Engineer with over five years of experience working with AWS cloud infrastructure, Kubernetes, Terraform, CI/CD automation, and production support.
Currently, I'm working at Northern Trust, where my main responsibility is managing and improving our AWS infrastructure and Kubernetes environments.
We use Amazon EKS to run containerized applications, Terraform to provision infrastructure, GitHub Actions and Jenkins for CI/CD automation, and Argo CD for GitOps-based deployments.
A big part of my work involves building reusable Terraform modules, improving deployment pipelines, monitoring production environments, and troubleshooting infrastructure and application issues.
For monitoring, I work with Prometheus, Grafana, Datadog, and AWS CloudWatch. We use these tools to monitor application health, resource utilization, and infrastructure performance.
Before Northern Trust, I worked at CDW, where I focused on infrastructure automation, containerization, and CI/CD pipelines. Earlier, at Apex Systems, I supported cloud migration projects and automated AWS infrastructure using Terraform and Bash.
I also have experience using AI tools like GitHub Copilot, OpenAI, and Claude to improve infrastructure automation, troubleshooting, and technical documentation.
What I enjoy most about DevOps is solving complex production problems, reducing manual work through automation, and building reliable infrastructure that development teams can use efficiently.
I'm particularly interested in this opportunity because it closely aligns with my experience in AWS, EKS, Terraform, GitHub Actions, and Kubernetes automation.
Target speaking time: 90 seconds to 2 minutes.
2. What are your day-to-day responsibilities?
My daily responsibilities are a combination of infrastructure automation, Kubernetes operations, CI/CD improvements, monitoring, and production support.
I usually start my day by reviewing our monitoring dashboards in Grafana, Datadog, and CloudWatch to make sure our production applications and Kubernetes clusters are healthy.
I check for any critical alerts, failed deployments, pod restarts, high CPU or memory utilization, and infrastructure issues.
After that, we have our daily stand-up meeting, where we discuss what we completed yesterday, what we're working on today, and whether we have any blockers.
Throughout the day, I work on Jira tickets, which might involve updating Terraform modules, improving GitHub Actions workflows, deploying applications through Argo CD, or troubleshooting Kubernetes issues.
For example, if a development team needs a new AWS resource, I update the appropriate Terraform module, open a pull request, and go through our code review and approval process before applying the changes.
I also maintain our CI/CD pipelines. When developers push code, GitHub Actions automatically runs tests, builds Docker images, performs security scans, and pushes approved images to Amazon ECR. Argo CD then helps synchronize our Kubernetes deployments with the desired configuration in Git.
Another important part of my job is production support. If an application becomes unavailable or a deployment fails, I investigate the issue using kubectl, application logs, Kubernetes events, and monitoring dashboards.
I also collaborate closely with developers, QA engineers, security teams, and other infrastructure engineers to make sure our releases are secure and reliable.
My overall goal is to keep our infrastructure stable, automate repetitive tasks, and help development teams deliver applications faster and more safely.
3. Tell me about a production incident you resolved — Kubernetes application outage
Scenario 1 · EKS · CrashLoopBackOff · Application availability
This is a realistic incident example consistent with Elena's listed EKS and troubleshooting skills, but the specific incident is not verified by the resume.
Sure. One incident I can describe involves an application running in our production Amazon EKS environment.
After a new deployment, we started receiving alerts from Datadog and Prometheus indicating that some application pods were unhealthy and the application error rate was increasing.
My first step was to assess the impact and check the health of the Kubernetes workloads.
I used kubectl get pods to review the pod status and noticed that several pods were entering CrashLoopBackOff.
Then I used kubectl describe pod and kubectl logs --previous to investigate why the containers were restarting.
The logs showed that the application was failing during startup because it couldn't load a required environment variable.
I compared the new deployment configuration with the previous working version and found that a required configuration value had been omitted from the new release.
Since this was affecting production, our first priority was restoring service.
We rolled back to the previous stable deployment using Argo CD and verified that the application pods became healthy again.
After service was restored, I worked with the development team to correct the missing configuration and validate it in our lower environment.
We also improved our deployment validation process by adding configuration checks to the GitHub Actions pipeline.
The result was that we restored application availability and reduced the risk of the same issue happening again.
The biggest lesson from this incident was the importance of automated configuration validation and having a reliable rollback strategy.
Technical follow-up questions
Q: How did you identify CrashLoopBackOff?
kubectl get pods -n production
kubectl describe pod <pod-name> -n production
kubectl logs <pod-name> -n production --previous
kubectl get events -n production --sort-by=.lastTimestamp
Q: Why did the pod restart?
The application process exited during startup because a required configuration value was missing. Kubernetes restarted the container according to the pod's restart policy, and repeated failures caused the backoff delay.
Q: How did you roll back?
For an Argo CD-managed application, we restored the last known-good configuration in Git and synchronized the application. A direct kubectl rollout undo may also be used as an emergency mitigation, but the GitOps desired state must be corrected to prevent Argo CD from restoring the faulty version.
Q: How did you prevent recurrence?
We added required configuration checks in CI, tested the release in a lower environment, and improved deployment monitoring.
4. Tell me about another production incident — High CPU and EKS performance degradation
Scenario 2 · AWS EKS · HPA · Resource limits · Performance
Another incident involved performance degradation in our Kubernetes environment during a period of increased application traffic.
We received alerts from Prometheus and Grafana showing high CPU utilization and increased application response times.
I started by checking the cluster and workload health using kubectl top nodes and kubectl top pods.
I noticed that several application pods were consuming significantly more CPU than usual, and some workloads were approaching their configured CPU limits.
I checked the Horizontal Pod Autoscaler configuration and noticed that the application wasn't scaling as expected.
After investigating the HPA configuration and resource metrics, we identified an issue with the CPU resource requests used by the workload, which affected the autoscaling behavior.
I worked with the team to update the resource requests and limits, verify that the metrics pipeline was functioning correctly, and adjust the HPA configuration.
We also reviewed node capacity to make sure the cluster had enough resources to schedule additional replicas.
After applying the changes, the HPA started scaling the application appropriately as traffic increased.
We monitored the deployment through Grafana and CloudWatch and confirmed that CPU utilization stabilized and application response times improved.
As a preventive measure, we added more specific alerts for HPA scaling conditions, resource saturation, and application latency.
This incident reinforced the importance of properly configuring Kubernetes resource requests, autoscaling policies, and cluster capacity together.
Technical follow-up questions
Q: What commands did you use?
kubectl top nodes
kubectl top pods -n production
kubectl get hpa -n production
kubectl describe hpa <hpa-name> -n production
kubectl describe deployment <deployment-name> -n production
kubectl get events -n production --sort-by=.lastTimestamp
Q: How does HPA calculate CPU utilization?
For CPU utilization-based scaling, HPA compares actual CPU usage against the CPU requests configured for containers. If resource requests are missing or unsuitable, scaling can behave incorrectly.
Q: What if HPA increases replicas but pods remain Pending?
I would check node capacity, scheduler events, node taints, resource requests, and whether Cluster Autoscaler or Karpenter is configured to provision additional capacity.
Q: What's the difference between HPA and Karpenter?
HPA scales the number of application pod replicas. Karpenter provisions and manages worker-node capacity so the cluster can accommodate unschedulable workloads.
5. Explain your company structure and DevOps team
The resume confirms Northern Trust as Elena's current employer but does not specify her reporting structure or team size. The following is a sample enterprise team description to adapt to her actual situation.
At Northern Trust, I work within the cloud infrastructure and DevOps engineering organization.
Our team is responsible for supporting AWS infrastructure, Kubernetes platforms, CI/CD automation, and application deployment processes.
We work closely with several application development teams, as well as QA, security, networking, and infrastructure teams.
In a typical team structure, we have a DevOps engineering manager, senior DevOps engineers, DevOps engineers, and platform or cloud engineers.
Our DevOps team is responsible for infrastructure provisioning, Kubernetes operations, deployment automation, monitoring, and production reliability.
Developers focus on application code and business functionality, while our team provides the infrastructure and automation needed to build, test, and deploy their applications.
We also collaborate with security engineers on IAM permissions, secrets management, vulnerability scanning, and infrastructure security.
When production incidents occur, we coordinate with the application owners and relevant infrastructure teams to identify the root cause, restore service, and implement preventive improvements.
We use Jira to track tasks and GitHub for source control, pull requests, and infrastructure code reviews.
Example organizational structure
Engineering / Cloud Infrastructure Leadership
DevOps / Platform Engineering Manager
DevOps / SRE Team
Senior Engineers · DevOps Engineers · Platform Engineers
Elena — DevOps Engineer
Development / QA
Security / Networking
Cloud / Operations
Illustrative team structure, not a verified Northern Trust organization chart.
6. What meetings do you attend?
We follow an Agile-style workflow, so I participate in several regular meetings.
Every morning, we have a daily stand-up, usually around 15 minutes, where we discuss what we worked on yesterday, our priorities for today, and any blockers.
We also have sprint planning meetings, where we review upcoming Jira tickets, estimate the effort required, and decide which infrastructure or automation tasks we can complete during the sprint.
During backlog refinement, we review technical requirements and clarify dependencies before starting new work.
I also participate in technical design discussions, especially when we're planning Terraform infrastructure changes, Kubernetes upgrades, or CI/CD improvements.
Before major production deployments, we may have release readiness or change review meetings to discuss risks, rollback plans, and deployment procedures.
If we experience a significant production incident, we hold a post-incident review to discuss the root cause, business impact, and preventive actions.
Finally, I have regular one-on-one meetings with my manager to discuss priorities, performance, and professional development.
Example meeting schedule
| Meeting | Frequency | Purpose |
|---|---|---|
| Daily stand-up | Daily, 15 min | Progress and blockers |
| Sprint planning | Every 2 weeks | Assign sprint work |
| Backlog refinement | Weekly | Review Jira tickets |
| Technical design | As needed | Architecture and changes |
| Release / change review | Before major releases | Risk and approval |
| Incident review | After significant incidents | Root cause and prevention |
| Manager 1:1 | Weekly or biweekly | Priorities and feedback |
7. Describe your GitHub Actions pipeline
This question is especially important because the job description requires extensive GitHub Actions experience.
In my current role, I work with GitHub Actions to automate our application build, testing, security scanning, and deployment processes.
Our typical pipeline starts when a developer opens a pull request or pushes changes to the repository.
First, we run code quality checks, unit tests, and dependency scanning.
Once the code is approved and merged, the pipeline builds a Docker image using a multi-stage Dockerfile.
We then run container security scanning using tools such as Trivy and publish the approved image to Amazon ECR.
For AWS authentication, I prefer using GitHub Actions OIDC with IAM roles instead of storing long-lived AWS access keys.
After the image is published, the deployment process updates the appropriate Kubernetes configuration in Git, and Argo CD synchronizes the changes to our EKS environment.
We also use environment-specific configurations and approval controls for production deployments.
One of the main benefits of this approach is that it gives us consistent, repeatable deployments with better security and traceability.
I'm also comfortable working with reusable workflows to avoid duplicating the same CI/CD logic across multiple repositories.
Typical deployment flow
GitHub Pull Request / Merge
Unit Tests
Code Quality
Security Scan
Docker Build → Amazon ECR
Update GitOps Repository
Argo CD → Amazon EKS
8. Why are you interested in this position?
I'm interested in this position because the technical requirements align very closely with the work I've been doing.
My strongest areas are AWS infrastructure, Kubernetes, Terraform, GitHub Actions, and automation.
What particularly interests me is the opportunity to work on enterprise-scale EKS environments, improve CI/CD workflows, and contribute to infrastructure standardization.
I also like that the position focuses on reliability, security, and cost optimization rather than just deploying applications.
I'm looking for an opportunity where I can take more ownership of infrastructure automation, solve challenging production problems, and continue growing as a DevOps and platform engineer.
9. Additional questions Elena should prepare for
The recruiter specifically emphasizes several advanced topics that are not clearly demonstrated in the resume, especially Karpenter, Actions Runner Controller, OIDC, IRSA, and zero-downtime EKS upgrades.
1. How do you implement GitHub Actions OIDC authentication with AWS?
Configure the GitHub OIDC identity provider in IAM, create an IAM role with a restricted trust policy for the repository and environment, and use aws-actions/configure-aws-credentials to assume that role. This avoids storing long-lived AWS access keys.
2. How would you upgrade a production EKS cluster with minimal downtime?
3. What is IRSA?
4. How do you troubleshoot a Kubernetes pod stuck in Pending?
5. How do you handle Terraform state?
6. What is Actions Runner Controller?
7. What is the difference between Argo CD and GitHub Actions?
Top comments (0)