DevOps & CI/CD Interview Guide

DevOps CI/CD phases with recommended tools:

• Continuous Integration (CI) — Author → Source → Build → Test. Developers frequently merge code changes, which are automatically built and tested.
• Continuous Deployment (CD) — Extends CI by automatically deploying every change that passes all stages to production.
• Continuous Delivery (CD) — Similar to Continuous Deployment, but includes a Manual Approval step before deploying to production.

Traditional DevOps (Push-based)

1. Developers check in Code, Dockerfile, and manifest YAMLs to an application repository. CI tools (e.g. Jenkins) build the container image and save it in a container registry such as Amazon ECR.
2. CD tools (e.g. Jenkins) update the deployment manifest files with the tag of the container image.
3. CD tools execute the command to deploy the manifest files into the cluster, deploying the newly built container in Amazon EKS.

Conclusion: Traditional CI/CD is a push-based model. If a sneaky SRE changes the YAML file directly in the cluster, the resources running in the cluster will deviate from what's defined in Git.

GitOps (Pull-based)

1. Developers check in Code, Dockerfile, and manifest YAMLs. CI tools build the container image and save it in Amazon ECR.
2. CD tools update the deployment manifest files with the tag of the container image.
3. With GitOps, Git becomes the single source of truth. You install a GitOps tool like Argo inside the cluster and point to a Git repo. It keeps checking if there is a new file, or if the files in the cluster drift from the ones in Git. As soon as YAML is updated, ArgoCD detects the drift and pulls in the updated YAML file to deploy the new container.

Conclusion: GitOps does NOT replace DevOps — it only replaces part of the CD process. If the sneaky SRE directly changes the YAML in the cluster, ArgoCD will detect the mismatch, pull in the file from Git, and bring Kubernetes resources to its intended state.

Git Flow

• main — Production-ready code. Only receives merges from release or hotfix branches.
• develop — Integration branch for features. All feature branches merge here.
• feature/* — One branch per feature. Created from develop, merged back into develop.
• release/* — Stabilization branch. Created from develop when ready for release, merged into both main and develop.
• hotfix/* — Emergency fixes off main. Merged back into both main and develop.

Trunk-Based Development

• All developers commit directly to main (or via very short-lived feature branches).
• Relies on feature flags to hide incomplete features in production.
• Preferred for CI/CD-heavy teams — enables continuous deployment with small, frequent releases.

GitHub Flow (Simplified)

• Single main branch + feature branches. Pull request → code review → merge to main → deploy.
• Best for smaller teams and SaaS products with continuous delivery.

DevSecOps integrates security into every phase of the CI/CD pipeline rather than treating it as a final gate:

Key Principles

• Shift Left — Find and fix vulnerabilities as early as possible (in code, not in production).
• Automate Everything — Security checks run automatically in the pipeline; no manual gates.
• Shared Responsibility — Security is everyone's job, not just the security team's.
• Continuous Monitoring — Runtime protection with GuardDuty, CloudTrail, and automated remediation.

DevOps questions test your understanding of CI/CD pipelines, deployment strategies, and operational excellence at scale.

1. Design a CI/CD pipeline for a microservices application deployed across 3 AWS accounts (dev, staging, prod). How do you handle cross-account deployments securely?
   Answer Guide

   Pipeline in a shared tooling account. Cross-account IAM roles assumed by the pipeline. Artifact stored in S3/ECR with cross-account policies. Stage gates between environments. Use OIDC federation (no long-term keys) for GitHub Actions or CodePipeline cross-account.
2. Compare blue/green, canary, and rolling deployment strategies. Your application has a database schema change in the release. Which strategy would you choose and why?
   Answer Guide

   Blue/green for zero-downtime with instant rollback. Canary for gradual risk reduction (5% → 25% → 100%). With DB schema changes, you MUST ensure backward compatibility — both old and new code versions must work with the new schema. This rules out big-bang blue/green without careful planning.
3. A developer pushes a commit and the deployment reaches production in 8 minutes with no human intervention. Your security team says this is too risky. How do you balance speed with safety?
   Answer Guide

   Automated quality gates: unit tests, integration tests, SAST/DAST, container image scanning, approval gates for prod. Canary deployments with automatic rollback on error rate thresholds. Discuss DORA metrics: deployment frequency, lead time, MTTR, change failure rate.
4. Explain GitOps. How does ArgoCD differ from a traditional push-based CI/CD pipeline? When would you NOT use GitOps?
   Answer Guide

   GitOps: Git is the source of truth for desired state. ArgoCD (pull-based) watches the repo and reconciles. Push-based: pipeline pushes changes directly. GitOps NOT ideal for: database migrations, one-time scripts, secret rotation (secrets shouldn't be in Git).
5. Your team uses trunk-based development. A feature takes 3 weeks to build and isn't ready for production, but other developers need to merge to main daily. How do you handle this?
   Answer Guide

   Feature flags (LaunchDarkly, AWS AppConfig). The incomplete feature is merged to main but hidden behind a flag. This avoids long-lived branches while keeping main deployable. Discuss: branch by abstraction pattern for larger refactors.
6. A production deployment failed at 3 AM. The on-call engineer can't rollback because the deployment modified a DynamoDB table schema. How should you have designed this to allow safe rollback?
   Answer Guide

   Schema changes must be backward-compatible and decoupled from code deployments. Expand-contract pattern: 1) Add new column, 2) Deploy code that writes to both old and new, 3) Migrate data, 4) Deploy code that reads only from new, 5) Remove old column. Never deploy schema + code together.
7. Your CI pipeline takes 45 minutes to run. Developers are merging 3 times per day each, and the pipeline is always backed up. How do you reduce the build time?
   Answer Guide

   Parallelize test suites, cache dependencies (npm, Docker layers), run only affected tests (test impact analysis), split unit/integration/e2e into stages with fast-fail. Consider: monorepo tools (Turborepo, Nx) that build only changed packages. Target: under 10 minutes for the critical path.
8. Design a shift-left security strategy for a containerized application. Which security checks would you add at each stage of the pipeline?
   Answer Guide

   Pre-commit: secrets scanning (gitleaks). Build: SAST (Snyk, SonarQube), dependency scanning (npm audit). Container: image scanning (Trivy, ECR scanning), base image policy. Deploy: OPA/Kyverno admission policies. Runtime: GuardDuty for EKS, Falco for container anomalies.
9. Compare Terraform and AWS CDK for infrastructure as code. A team with strong Python skills asks which to use for a new project. What's your recommendation?
   Answer Guide

   CDK — generates CloudFormation, uses familiar languages (Python, TypeScript), great for teams already in AWS. Terraform — provider-agnostic, mature state management, large community. CDK for AWS-only shops; Terraform for multi-cloud or teams needing explicit state control. Discuss state management trade-offs.
10. What are the four DORA metrics and why do they matter? Your team has a deployment frequency of once per month and MTTR of 24 hours. What would you prioritize improving?
    Answer Guide

    DORA: Deployment Frequency, Lead Time for Changes, MTTR (Mean Time to Recover), Change Failure Rate. Priority: MTTR first — 24 hours is too long. Implement automated rollback, better monitoring/alerting, and runbooks. Then increase deployment frequency (smaller, safer changes).