Skip to content
EgyKode
All levels60 min

Final Interview Preparation

After this chapter you can

  • Answer architecture questions with trade-offs, not tool names

Introduction#

If you have read the previous 35 chapters, you possess the theoretical knowledge of a Senior Cloud/DevOps Engineer. However, passing a senior interview is not just about knowing what tools do. It is about proving that you can combine those tools to solve massive business problems, and proving that you know how to communicate those solutions to a non-technical CEO.

This chapter contains the ultimate behavioral and architectural interview frameworks.

Level 1 — Beginner (The Basics)#

The "I don't know" Rule#

If an interviewer asks you a question, and you do not know the answer, DO NOT LIE. DO NOT GUESS. Senior engineers know that guessing in a production environment destroys databases. If you don't know the answer, say exactly this: "I have not personally used that specific tool in production, so I don't know the exact command off the top of my head. However, based on my understanding of how [Similar Tool] works, I would assume the architecture is similar. My first step would be to consult the official documentation to verify."

The STAR Method#

When asked a behavioral question (e.g., "Tell me about a time you fixed a production outage"), you MUST use the STAR method.

  • S (Situation): "On Black Friday, our API went down."
  • T (Task): "My job was to restore service within our 15-minute SLA."
  • A (Action): "I checked Grafana, saw the database connections were exhausted, and deployed RDS Proxy via Terraform."
  • R (Result): "The site came back online in 10 minutes, and we generated $500,000 in revenue that hour."

Level 2 — Intermediate (System Design Strategy)#

When you are asked to design a system on a whiteboard, follow this exact 5-step framework:

  1. Clarify Requirements: Never start drawing immediately. Ask questions. "How many users are we expecting? Do we need Multi-Region DR? What is the budget? Is the data highly regulated (PCI/HIPAA)?"
  2. The Compute Layer: Decide between Serverless (Lambda) or Containers (EKS) based on traffic patterns.
  3. The Data Layer: Decide between Relational (RDS PostgreSQL) or NoSQL (DynamoDB) based on the data schema.
  4. The Edge Layer: Add CloudFront (CDN), WAF (Security), and ALB (Load Balancing).
  5. The Day 2 Layer: Explicitly mention how you will monitor it (Prometheus/Grafana) and deploy it (ArgoCD/Terraform). Most candidates forget this step. Doing this proves you are a DevOps engineer, not just a Software Engineer.

Level 3 — Advanced (The "Failure" Questions)#

Senior interviews heavily focus on failure.

Q: "Tell me about the worst mistake you've ever made in Production."#

How to answer: Never say, "I haven't made any." That means you lack experience. Tell a story about how you broke something because of a process failure, not because you are stupid.

Example Answer: "Early in my career, I deployed a Terraform change that accidentally deleted a production database. The issue wasn't just my typo; it was a systemic failure. We didn't have prevent_destroy = true enabled on stateful resources, and we weren't running terraform plan outputs through an automated OPA (Open Policy Agent) check in the CI pipeline. I immediately restored the database from the automated snapshot, resulting in only 5 minutes of downtime. More importantly, I spent the next week implementing strict GitOps policies and OPA rules so that no human could ever make that mistake again."

Why this is a perfect answer: It shows accountability, it shows you know how to fix it fast, and it shows you architected a systemic solution to prevent it from happening twice.

Level 4 — Enterprise (The "Why" Questions)#

Architects are not tested on how to build things. They are tested on why they chose to build things.

Q: "Why did you choose ArgoCD instead of Jenkins for deployment?"#

How to answer: "Jenkins is a fantastic CI engine, but using it for CD (Push-based deployments) violates the principle of least privilege. If Jenkins pushes to EKS, Jenkins needs cluster-admin credentials. If Jenkins is compromised, the cluster is compromised. Furthermore, if a junior developer manually runs kubectl edit in production, Jenkins has no idea that the cluster state has drifted from the Git repository. I chose ArgoCD because its Pull-based architecture keeps credentials securely inside the cluster, and its continuous reconciliation loop instantly detects and overwrites configuration drift, ensuring Git remains the absolute Single Source of Truth."

Q: "How do you balance Security vs. Developer Velocity?"#

How to answer: "Security is often viewed as a blocker to velocity. In a modern Platform Engineering architecture, I view them as symbiotic. If we force developers to manually request security audits, velocity drops to zero. Instead, we implement 'Shift-Left' security. I build Trivy vulnerability scanning and OPA policy checks directly into the Jenkins pipeline. If a developer writes an insecure Dockerfile, the pipeline fails instantly with a clear error message explaining how to fix it. This creates a 'Golden Path'. Developers can deploy to production 50 times a day without waiting for manual security approvals, because the platform mathematically guarantees they cannot deploy anything insecure."

Ultimate Final Exam#

The Scenario: The CEO walks up to you. "We just acquired a startup. Their entire application is a massive monolithic Java application running on a single, manually-configured EC2 instance. We need to move it to our modern Kubernetes platform by next month. How do you do it?"

The Architect's Answer:

  1. Containerization (Week 1): I will not rewrite their code. I will wrap their existing monolithic .jar file in a Docker container. I will write a multi-stage Dockerfile to ensure the image is secure and lightweight.
  2. Infrastructure (Week 2): I will not click around the AWS console. I will use Terraform to provision a dedicated RDS PostgreSQL instance for their data, ensuring it is in a private subnet with Multi-AZ enabled. I will use AWS Database Migration Service (DMS) to securely sync the data from their old EC2 instance to the new RDS instance without downtime.
  3. Deployment (Week 3): I will create Helm charts for their monolith. I will commit these charts to our manifest repository. I will configure ArgoCD to watch this repository, ensuring the monolith is deployed declaratively.
  4. Observability (Week 4): I will ensure their Pod is configured with an OpenTelemetry sidecar to ship logs to Loki and metrics to Prometheus.
  5. The Cutover: Once the data is synced and the Pods are healthy, we update Route 53 DNS to point to the new Application Load Balancer.
  6. The Future: Once they are safely in Kubernetes, we will spend the next 6 months slowly strangling the monolith (the Strangler Fig Pattern), breaking it apart into smaller microservices using Istio to route traffic between the old monolith and the new microservices. Contents | 45 — Project Architecture Summary (For Recruiters) |