[{"data":1,"prerenderedAt":442},["ShallowReactive",2],{"all-questions-cicd":3},{"beginner":4,"intermediate":176,"advanced":305},[5,16,25,33,42,52,61,70,79,88,95,103,112,121,129,138,149,158,168],{"id":6,"category":7,"question":8,"answer":9,"level":10,"tags":11},1,"CI Fundamentals","What is Continuous Integration (CI) and why is it important?","**Concept Explanation:** Continuous Integration (CI) is a development practice where developers regularly merge code changes into a shared repository, typically multiple times a day. Each merge triggers an automated build and test process, allowing teams to detect integration errors early. CI helps prevent \"integration hell\" by ensuring that code changes are integrated frequently and validated automatically.\n\n**CI\u002FCD Workflow Explanation:** In a typical CI workflow, a developer pushes code to a feature branch, then opens a pull request. The CI system automatically runs tests, linters, and builds on that branch. Only after all checks pass can the code be merged into the main branch. This ensures the main branch remains deployable at all times.\n\n**Internal Pipeline Flow:** 1) Developer pushes code → 2) CI server detects change → 3) Pipeline triggers (checkout code) → 4) Install dependencies → 5) Run linters and tests → 6) Build application → 7) Report status back to PR → 8) On failure, notify team.\n\n**Setup Explanation (GitHub Actions):** Create `.github\u002Fworkflows\u002Fci.yml` in your repository. Define triggers (push\u002Fpull_request), jobs, and steps.\n\n**YAML Configuration Example:**\n```yaml\nname: CI\non: [push, pull_request]\njobs:\n  build:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-node@v4\n        with: { node-version: '20' }\n      - run: npm ci\n      - run: npm test\n```\n\n**Practical Example:** A team of 5 developers working on a React app. Each pull request runs Jest tests and ESLint. CI catches a missing import before it reaches production.\n\n**Production Scenarios:** CI prevents broken code from entering main branch. For critical projects, require CI checks to pass before merging (branch protection).\n\n**Debugging Strategies:** Check CI logs for exact error lines. Use `act` (local GitHub Actions runner) to debug locally. Add `run: echo \"Debug: $VAR\"` steps.\n\n**Common Mistakes:** Ignoring flaky tests; not keeping CI fast; committing directly to main bypassing CI.\n\n**Edge Cases:** Flaky network tests can fail CI intermittently. Use retries. Large monorepo may exceed CI time limits – use caching and selective testing.\n\n**Security Best Practices:** Never log secrets. Use GitHub Secrets for API keys. Pin actions to SHA hashes. Use `actions\u002Fcheckout` with `persist-credentials: false` for public repos.\n\n**Optimization Strategies:** Cache dependencies (`actions\u002Fcache`). Run tests in parallel. Use matrix strategy. Fail fast on first error.\n\n**Deployment Considerations:** CI typically does not deploy; it only verifies. Deployments are handled by CD.\n\n**Monitoring Recommendations:** Use GitHub's status checks. Integrate with Slack\u002FTeams for failure alerts. Track CI run duration trends.\n\n**Scaling Considerations:** For many developers, use self-hosted runners with auto-scaling. Partition CI into multiple workflows.\n\n**Interview Tip:** Emphasize that CI is about \"continuously integrating\" changes, not about the tools. The key benefit is catching bugs early, reducing merge conflicts.\n\n**Common Follow-up:** \"What is the difference between CI and CD?\"\n\n**Real-world Example:** Google runs millions of CI jobs daily. Every code change is tested across thousands of machines before merge. This scale enables rapid development with high reliability.","beginner",[12,13,14,15],"ci","continuous-integration","github-actions","basics",{"id":17,"category":18,"question":19,"answer":20,"level":10,"tags":21},2,"CD Fundamentals","What is Continuous Delivery (CD) and how does it differ from Continuous Deployment?","**Concept Explanation:** Continuous Delivery (CD) is the practice of automatically building, testing, and preparing code changes for release to production. In Continuous Delivery, the deployment to production is a manual trigger (but one-click). Continuous Deployment goes further: every change that passes the pipeline is automatically deployed to production without human intervention.\n\n**CI\u002FCD Workflow Explanation:** After CI (build + test), CD takes over: package the application, deploy to a staging environment, run integration tests, and then either wait for manual approval (Delivery) or auto-deploy to production (Deployment).\n\n**Internal Pipeline Flow:** 1) CI passes → 2) CD pipeline creates deployable artifact → 3) Deploy to staging → 4) Run smoke tests → 5) If manual approval required, pause → 6) Deploy to production.\n\n**Setup Explanation (GitHub Actions):** Add deployment jobs after test jobs. Use environments for staging\u002Fprod with protection rules.\n\n**YAML Configuration Example:**\n```yaml\nname: CD\non:\n  push:\n    branches: [main]\njobs:\n  test:\n    runs-on: ubuntu-latest\n    steps: [checkout, setup, test]\n  deploy-staging:\n    needs: test\n    runs-on: ubuntu-latest\n    environment: staging\n    steps:\n      - run: echo \"Deploy to staging\"\n  deploy-prod:\n    needs: deploy-staging\n    runs-on: ubuntu-latest\n    environment: production\n    if: github.event_name == 'workflow_dispatch'  # manual trigger\n    steps:\n      - run: echo \"Deploy to production\"\n```\n\n**Practical Example:** An e-commerce site: CI runs on every PR. CD deploys to staging on every merge to main. A release manager clicks \"Deploy to Production\" button once a week after manual QA.\n\n**Production Scenarios:** High-compliance industries (finance, healthcare) use Continuous Delivery with approval gates. Startups with high velocity use Continuous Deployment.\n\n**Debugging Strategies:** Check deployment logs; use rollback buttons; monitor staging environment health before production.\n\n**Common Mistakes:** Not having proper monitoring for auto-deploys; deploying without smoke tests; mixing CI and CD in one bloated workflow.\n\n**Edge Cases:** Failed deployment triggers automatic rollback (requires advanced CD). Database migrations need special handling.\n\n**Security Best Practices:** Use separate service accounts for CD. Limit CD permissions to necessary resources. Use OIDC for cloud provider authentication.\n\n**Optimization Strategies:** Parallelize deployment to multiple regions. Use deployment scripts idempotently. Cache build artifacts across stages.\n\n**Deployment Considerations:** Use deployment strategies: rolling update, blue-green, canary. Ensure zero-downtime.\n\n**Monitoring Recommendations:** Track deployment frequency, lead time, change failure rate, mean time to recovery (DORA metrics).\n\n**Scaling Considerations:** For many services, use a deployment orchestration platform (ArgoCD, Spinnaker).\n\n**Interview Tip:** Emphasize the difference: Continuous Delivery = always ready to deploy (manual trigger). Continuous Deployment = automatically deploy every change.\n\n**Common Follow-up:** \"What are the DORA metrics?\"\n\n**Real-world Example:** Netflix uses Continuous Deployment: every successful build automatically deploys to production across thousands of servers, but with canary analysis and automated rollback if metrics degrade.",[22,23,24,14],"cd","continuous-delivery","deployment",{"id":26,"category":27,"question":28,"answer":29,"level":10,"tags":30},3,"CI\u002FCD Fundamentals","What are the key differences between CI and CD?","**Concept Explanation:** CI focuses on integrating code changes frequently and verifying them through automated builds and tests. CD extends CI by automatically deploying the verified code to production-like environments (and optionally to production). CI is a prerequisite for CD. CI answers: \"Does the code work?\" CD answers: \"Is the code deployable and deployed?\"\n\n**CI\u002FCD Workflow Explanation:** CI pipeline: code → build → unit tests → integration tests → artifact. CD pipeline: artifact → deploy to staging → acceptance tests → deploy to production (auto or manual).\n\n**Internal Pipeline Flow:** CI runs on every push\u002FPR; CD runs on merge to main (or release branch). CI must pass before CD begins.\n\n**Setup Explanation:** In GitHub Actions, you can have separate workflows or a single workflow with conditional jobs.\n\n**YAML Configuration Example:**\n```yaml\nname: CI_CD\non: [push]\njobs:\n  ci:\n    runs-on: ubuntu-latest\n    steps: [checkout, test, build]\n  cd:\n    needs: ci\n    runs-on: ubuntu-latest\n    if: github.ref == 'refs\u002Fheads\u002Fmain'\n    steps: [deploy-to-staging]\n```\n\n**Practical Example:** A developer pushes to feature branch → CI runs tests. When merged to main → CD deploys to staging. Manual approval → CD deploys to production.\n\n**Production Scenarios:** In Continuous Delivery, CD stops before production. In Continuous Deployment, CD proceeds automatically.\n\n**Debugging Strategies:** Separate logs for CI and CD stages. Use GitHub Actions artifacts to pass build outputs between jobs.\n\n**Common Mistakes:** Putting deployment logic in CI job; not using environment protection; deploying broken code because tests are insufficient.\n\n**Edge Cases:** Some tools (like Vercel) blur the line: every push gets a preview deployment (CD), but production is manual.\n\n**Security Best Practices:** CI uses read-only tokens; CD uses write tokens limited to deployment targets. Never share tokens across stages.\n\n**Optimization Strategies:** Reuse CI artifacts in CD to avoid rebuilding. Cache test results.\n\n**Deployment Considerations:** CD should handle blue-green, canary, or rolling updates. Implement health checks.\n\n**Monitoring Recommendations:** Monitor CI pass\u002Ffail rate. Monitor CD success rate and deployment duration.\n\n**Scaling Considerations:** Separate CI and CD into different workflows for large teams. Use self-hosted runners for CD if security requires.\n\n**Interview Tip:** Use the analogy: CI = \"Does it build and test?\" CD = \"Can we ship it?\"\n\n**Common Follow-up:** \"Can you have CD without CI?\"\n\n**Real-world Example:** A mobile app team: CI runs on every PR (unit tests, lint). CD builds the app and deploys to TestFlight (staging) automatically on merge to main. Production release is manual (Continuous Delivery).",[12,22,31,32],"comparison","fundamentals",{"id":34,"category":35,"question":36,"answer":37,"level":10,"tags":38},4,"CI\u002FCD Pipeline","What is a CI\u002FCD pipeline and what are its typical stages?","**Concept Explanation:** A CI\u002FCD pipeline is a series of automated steps that code changes go through from commit to deployment. Typical stages include: source (code checkout), build (compile\u002Fpackage), test (unit, integration, lint), deploy (to staging\u002Fproduction), and verify (smoke tests, monitoring). The pipeline ensures quality and consistency.\n\n**CI\u002FCD Workflow Explanation:** The pipeline is triggered by events (push, PR, schedule). Each stage must succeed for the pipeline to proceed; failures stop the pipeline and notify the team.\n\n**Internal Pipeline Flow:** 1) Trigger → 2) Checkout code → 3) Install dependencies → 4) Lint → 5) Build → 6) Unit tests → 7) Integration tests → 8) Security scan → 9) Package artifact → 10) Deploy to staging → 11) Smoke tests → 12) (manual approval) → 13) Deploy to production → 14) Health checks.\n\n**Setup Explanation (GitHub Actions):** Use jobs with `needs` to create dependencies. Each job runs in a fresh runner.\n\n**YAML Configuration Example:**\n```yaml\nname: Full Pipeline\non: [push]\njobs:\n  lint:\n    runs-on: ubuntu-latest\n    steps: [checkout, run: npm run lint]\n  test:\n    runs-on: ubuntu-latest\n    steps: [checkout, run: npm test]\n  build:\n    needs: [lint, test]\n    runs-on: ubuntu-latest\n    steps: [checkout, run: npm build, upload-artifact]\n  deploy-staging:\n    needs: build\n    runs-on: ubuntu-latest\n    environment: staging\n    steps: [download-artifact, deploy-to-staging]\n  e2e:\n    needs: deploy-staging\n    runs-on: ubuntu-latest\n    steps: [run-e2e-tests]\n  deploy-prod:\n    needs: e2e\n    runs-on: ubuntu-latest\n    environment: production\n    if: github.event_name == 'workflow_dispatch'\n    steps: [deploy-to-prod]\n```\n\n**Practical Example:** A Node.js API pipeline: test (Jest), build (TypeScript → JS), containerize (Docker), push to registry, deploy to Kubernetes staging, run integration tests, then manual production deployment.\n\n**Production Scenarios:** Fast pipeline (under 10 minutes) encourages frequent deployments. Slow pipeline discourages merging.\n\n**Debugging Strategies:** Add `echo` steps, use `tmate` for SSH debugging, check GitHub Actions logs. Use `continue-on-error` for non-critical steps.\n\n**Common Mistakes:** Too many stages in one job (no parallelization). Not caching dependencies. Missing cleanup steps.\n\n**Edge Cases:** Pipeline may need conditional stages (skip on doc changes). Use paths-ignore.\n\n**Security Best Practices:** Scan dependencies (npm audit, Snyk). Run SAST tools (Semgrep). Never hardcode secrets.\n\n**Optimization Strategies:** Parallel independent jobs. Cache node_modules. Use matrix strategy for tests.\n\n**Deployment Considerations:** Use deployment strategies appropriate for the app. Have rollback step.\n\n**Monitoring Recommendations:** Use GitHub Actions badges. Integrate with Datadog\u002FPrometheus for pipeline metrics.\n\n**Scaling Considerations:** For huge monorepos, use affected commands (Nx, Turborepo) to run only changed projects.\n\n**Interview Tip:** Emphasize that a good pipeline is fast, reliable, and secure. Each stage must add value.\n\n**Common Follow-up:** \"How do you handle failed deployments in the pipeline?\"\n\n**Real-world Example:** Uber's CI\u002FCD pipeline has hundreds of stages including static analysis, unit tests, integration tests, performance tests, and canary deployments, all automated within 30 minutes.",[39,40,14,41],"pipeline","stages","workflow",{"id":43,"category":44,"question":45,"answer":46,"level":10,"tags":47},5,"Benefits","What are the main benefits of implementing CI\u002FCD?","**Concept Explanation:** CI\u002FCD provides faster feedback, reduced integration problems, automated testing, faster deployments, higher quality, and less manual work. Benefits include: early bug detection, less merge hell, faster time to market, improved developer productivity, and ability to roll back easily.\n\n**CI\u002FCD Workflow Explanation:** With CI\u002FCD, bugs are caught minutes after commit, not weeks later. Deployments become low-risk and routine, not stressful events.\n\n**Internal Pipeline Flow:** The automated pipeline ensures consistency. Every change goes through the same rigorous process, eliminating human error.\n\n**Setup Explanation:** Minimal initial setup (e.g., GitHub Actions YAML) yields immediate benefits.\n\n**YAML Configuration Example:** Simple CI config that catches errors before they reach main.\n\n**Practical Example:** A team of 10 developers: before CI\u002FCD, releases were every 2 weeks with high stress. After CI\u002FCD, they deploy multiple times per day, and bugs are caught in PRs, not production.\n\n**Production Scenarios:** For e-commerce, CI\u002FCD allows hotfixes to go live in minutes. For SaaS, new features reach customers faster.\n\n**Debugging Strategies:** Not applicable for benefits.\n\n**Common Mistakes:** Underestimating the cultural change needed; not investing in good tests; using CI\u002FCD as a silver bullet.\n\n**Edge Cases:** CI\u002FCD may not suit legacy monoliths with long build times; break them down first.\n\n**Security Best Practices:** Embed security scanning in CI\u002FCD (shift-left).\n\n**Optimization Strategies:** Measure DORA metrics to quantify benefits.\n\n**Deployment Considerations:** CI\u002FCD reduces deployment risk through automation and rollback capability.\n\n**Monitoring Recommendations:** Track deployment frequency, lead time, change failure rate, MTTR.\n\n**Scaling Considerations:** Benefits scale with team size; larger teams see more productivity gains.\n\n**Interview Tip:** Emphasize that the biggest benefit is not just automation but culture change: developers become responsible for shipping to production.\n\n**Common Follow-up:** \"What are the DORA metrics and how do they relate to CI\u002FCD?\"\n\n**Real-world Example:** Etsy deploys 80+ times per day using CI\u002FCD. They went from quarterly releases to multiple daily deploys, reducing risk and improving customer satisfaction.",[48,49,50,51],"benefits","productivity","quality","automation",{"id":53,"category":54,"question":55,"answer":56,"level":10,"tags":57},6,"Git Workflow","What are basic Git branching strategies used with CI\u002FCD?","**Concept Explanation:** Common Git branching strategies include: GitFlow (develop, feature, release, hotfix branches), GitHub Flow (feature branches off main, PRs), and Trunk-Based Development (short-lived feature branches, merge to main multiple times per day). CI\u002FCD works best with short-lived branches and frequent integration.\n\n**CI\u002FCD Workflow Explanation:** Feature branches trigger CI on PR. Main branch triggers CD (deployments). Release branches trigger additional testing.\n\n**Internal Pipeline Flow:** Developer branches from main → pushes → opens PR → CI runs on PR → merge to main → CD runs deployment.\n\n**Setup Explanation:** Configure branch protection rules in GitHub: require PR, require CI checks to pass, require linear history.\n\n**YAML Configuration Example (trigger only on main):**\n```yaml\non:\n  push:\n    branches: [ main ]\n  pull_request:\n    branches: [ main ]\n```\n\n**Practical Example:** A team uses GitHub Flow: every feature branch is short-lived. CI runs on PR. Once approved and tests pass, merge to main triggers CD to staging. A separate tag triggers production deployment.\n\n**Production Scenarios:** For long-lived release branches (GitFlow), CI must run on release branches as well.\n\n**Debugging Strategies:** Check CI logs on PR branches. Use `git bisect` to find breaking commits.\n\n**Common Mistakes:** Long-lived branches causing merge hell; not running CI on feature branches; bypassing branch protection.\n\n**Edge Cases:** Hotfixes need special CI that runs quickly; use skip CI option for doc-only changes.\n\n**Security Best Practices:** Require signed commits for main branch. Use CODEOWNERS for approval.\n\n**Optimization Strategies:** Use `paths-ignore` to skip CI for documentation changes.\n\n**Deployment Considerations:** Main branch should always be deployable. Use tags for versioned releases.\n\n**Monitoring Recommendations:** Track branch age; alert on branches older than 2 days.\n\n**Scaling Considerations:** For monorepos, use path-based triggers to run only relevant CI.\n\n**Interview Tip:** Emphasize that CI\u002FCD works best with trunk-based development. Long-lived branches are anti-pattern.\n\n**Common Follow-up:** \"What is trunk-based development?\"\n\n**Real-world Example:** Google and Facebook use trunk-based development. Developers merge to main multiple times per day. CI\u002FCD runs on every commit, and main is always production-ready.",[58,59,41,60],"git","branching","github-flow",{"id":62,"category":63,"question":64,"answer":65,"level":10,"tags":66},7,"GitHub Actions Basics","What is GitHub Actions and what are its core components?","**Concept Explanation:** GitHub Actions is a CI\u002FCD platform integrated into GitHub. It allows automating software workflows: build, test, deploy, and more. Core components: Workflows (YAML files defining automation), Events (triggers like push, pull_request), Jobs (groups of steps), Steps (individual commands or actions), Runners (servers that execute jobs), and Actions (reusable units of code).\n\n**CI\u002FCD Workflow Explanation:** When an event occurs, GitHub Actions spins up a runner, checks out the code, and executes the defined steps sequentially within jobs. Jobs can run in parallel or sequentially.\n\n**Internal Pipeline Flow:** Event → GitHub picks a runner → Runner downloads the workflow → Executes steps → Reports status back to GitHub.\n\n**Setup Explanation:** Create `.github\u002Fworkflows\u002F*.yml` in your repository. Each file is a workflow.\n\n**YAML Configuration Example:**\n```yaml\nname: Example Workflow\non: [push]\njobs:\n  build:\n    runs-on: ubuntu-latest\n    steps:\n      - name: Checkout code\n        uses: actions\u002Fcheckout@v4\n      - name: Setup Node\n        uses: actions\u002Fsetup-node@v4\n        with:\n          node-version: 20\n      - name: Install dependencies\n        run: npm ci\n      - name: Run tests\n        run: npm test\n```\n\n**Practical Example:** A React project uses GitHub Actions to run tests on every push and build the app on PR.\n\n**Production Scenarios:** Large organizations use self-hosted runners for security and performance.\n\n**Debugging Strategies:** Use `ACTIONS_STEP_DEBUG` to enable debug logging. Add `run: echo \"${{ toJSON(github) }}\"` to inspect context.\n\n**Common Mistakes:** Not pinning actions to commit SHAs (security risk). Mixing steps in one job that could be parallelized.\n\n**Edge Cases:** Workflows have a maximum runtime (6 hours for public repos). Use `timeout-minutes`.\n\n**Security Best Practices:** Use `GITHUB_TOKEN` with minimal permissions. Never log secrets. Use OIDC for cloud authentication.\n\n**Optimization Strategies:** Cache dependencies (`actions\u002Fcache`). Use matrix builds. Reuse workflows.\n\n**Deployment Considerations:** Use environments for staging\u002Fproduction with protection rules.\n\n**Monitoring Recommendations:** Use GitHub Actions badges in README. Set up notifications.\n\n**Scaling Considerations:** Use larger runners for heavy builds (2-core, 4-core, etc.).\n\n**Interview Tip:** Emphasize that GitHub Actions is event-driven and highly customizable. It's not just for CI\u002FCD but for any automation.\n\n**Common Follow-up:** \"What's the difference between an action and a step?\"\n\n**Real-world Example:** GitHub itself uses GitHub Actions to build and test GitHub. Millions of workflows run daily across the platform.",[14,41,67,68,69],"jobs","steps","runners",{"id":71,"category":72,"question":73,"answer":74,"level":10,"tags":75},8,"GitHub Actions Workflows","How do you structure a GitHub Actions workflow? Explain jobs, steps, and actions.","**Concept Explanation:** A workflow is a YAML file containing one or more jobs. Each job runs on a runner and contains steps. Steps are either `run` (shell commands) or `uses` (reusable actions). Jobs can depend on each other via `needs`. Workflows are triggered by events.\n\n**CI\u002FCD Workflow Explanation:** Workflows are the top-level container. Jobs are the units of work. Steps are the individual commands. This hierarchy allows parallelization and dependency management.\n\n**Internal Pipeline Flow:** When triggered, each job gets a fresh runner. Steps execute sequentially. If a step fails, the job stops (unless `continue-on-error`). The workflow status is determined by jobs.\n\n**Setup Explanation:** Create `.github\u002Fworkflows\u002Fci.yml`. Use `name`, `on`, `jobs`, and within each job `runs-on`, `steps`, `env`.\n\n**YAML Configuration Example:**\n```yaml\nname: CI Pipeline\non: [push]\njobs:\n  lint:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - run: npm run lint\n  test:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - run: npm test\n  build:\n    needs: [lint, test]  # waits for both\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - run: npm build\n```\n\n**Practical Example:** A workflow with three jobs: lint (fast), test (medium), build (slow). Lint and test run in parallel; build runs after both succeed.\n\n**Production Scenarios:** For deployments, use `environment` to add approvals. Use `if` to conditionally run jobs.\n\n**Debugging Strategies:** Add `run: env` to see environment variables. Use `step.debug` for actions.\n\n**Common Mistakes:** Not using `needs` causing unordered jobs. Running everything in one job (no parallelism).\n\n**Edge Cases:** Jobs can timeout (`timeout-minutes`). Canceling workflow stops running jobs.\n\n**Security Best Practices:** Set `permissions` at workflow or job level to limit token access.\n\n**Optimization Strategies:** Use `services` for database containers. Use `actions\u002Fcache` for dependencies.\n\n**Deployment Considerations:** Deployment jobs should use `environment` and `concurrency` to prevent overlapping.\n\n**Monitoring Recommendations:** Use `github-action-typo` to check syntax. GitHub Actions tab shows visual workflow graph.\n\n**Scaling Considerations:** For monorepos, use `paths` filter and `matrix` for affected projects.\n\n**Interview Tip:** Emphasize that jobs are the unit of parallelism. Use `needs` for ordering, `matrix` for parallel variants.\n\n**Common Follow-up:** \"What is the difference between `run` and `uses`?\"\n\n**Real-world Example:** A typical CI workflow: `lint` job, `test` job (matrix Node versions), `security` job (CodeQL), `build` job, and `notify` job that runs only on failure.",[76,67,68,77,78],"workflow-structure","actions","yaml",{"id":80,"category":81,"question":82,"answer":83,"level":10,"tags":84},9,"Runners","What are GitHub Actions runners? Explain GitHub-hosted vs self-hosted runners.","**Concept Explanation:** Runners are servers that execute GitHub Actions jobs. GitHub-hosted runners are managed by GitHub (Ubuntu, Windows, macOS). Self-hosted runners are machines you manage, allowing custom hardware, software, or network access. Runners pick up jobs automatically.\n\n**CI\u002FCD Workflow Explanation:** When a workflow runs, GitHub assigns a runner matching `runs-on`. The runner downloads the workflow, executes steps, and returns logs and status.\n\n**Internal Pipeline Flow:** GitHub sends job details to a runner (via long-polling or webhook). Runner executes commands and streams logs back. After job completes, runner waits for next job.\n\n**Setup Explanation (self-hosted):** Go to repository Settings → Actions → Runners → New self-hosted runner. Follow OS-specific instructions to download and configure.\n\n**YAML Configuration Example:**\n```yaml\n# GitHub-hosted\nruns-on: ubuntu-latest\n\n# Self-hosted (label 'my-runner')\nruns-on: self-hosted\n# or with label\nruns-on: [self-hosted, linux, x64]\n```\n\n**Practical Example:** A company with a GPU server for ML testing runs self-hosted runners. For security, self-hosted runners are used for deployment jobs requiring internal network access.\n\n**Production Scenarios:** Self-hosted are used for ARM builds, large memory needs, or accessing internal services. GitHub-hosted for public repos and standard builds.\n\n**Debugging Strategies:** For self-hosted, check runner service logs (`.\u002Fsvc.sh status`). Use `step.debug`.\n\n**Common Mistakes:** Using self-hosted runners for untrusted code (security risk). Not cleaning up disk space.\n\n**Edge Cases:** Self-hosted runners must have internet to GitHub API. They can be ephemeral (one job only).\n\n**Security Best Practices:** Run self-hosted runners as non-root. Isolate them. Use ephemeral runners for untrusted code.\n\n**Optimization Strategies:** Scale self-hosted runners automatically using autoscaling. Use larger GitHub-hosted runners for speed.\n\n**Deployment Considerations:** Deployment jobs often use self-hosted runners for VPC access.\n\n**Monitoring Recommendations:** Monitor runner queue depth. Set up alerts for offline runners.\n\n**Scaling Considerations:** For large teams, use GitHub Actions larger runners (2-64 cores) or self-hosted clusters.\n\n**Interview Tip:** Emphasize that self-hosted give control but require maintenance. GitHub-hosted are simpler and secure for most projects.\n\n**Common Follow-up:** \"How do you prevent self-hosted runners from accessing other repos?\"\n\n**Real-world Example:** A fintech company uses self-hosted runners inside their VPC to deploy to production databases, while CI runs on GitHub-hosted for cost efficiency.",[69,85,86,87],"self-hosted","github-hosted","infrastructure",{"id":89,"category":90,"question":91,"answer":92,"level":10,"tags":93},10,"YAML Basics","What are the YAML basics needed for writing GitHub Actions workflows?","**Concept Explanation:** GitHub Actions workflows use YAML (Yet Another Markup Language). Key concepts: indentation (spaces only, not tabs), key-value pairs, lists (dash `-`), maps (nested keys), multiline strings (`|` or `>`), and booleans (`true\u002Ffalse`). Indentation defines hierarchy.\n\n**CI\u002FCD Workflow Explanation:** YAML is human-readable and structured. It's used because it's less verbose than JSON and supports comments.\n\n**Internal Pipeline Flow:** GitHub parses YAML to a data structure. Errors cause workflow not to run.\n\n**Setup Explanation:** Create `.yml` or `.yaml` file. Use spaces for indentation (typically 2 spaces).\n\n**YAML Configuration Example:**\n```yaml\nname: My Workflow\non: push\njobs:\n  build:\n    runs-on: ubuntu-latest\n    steps:\n      - name: Checkout\n        uses: actions\u002Fcheckout@v4\n      - name: Run script\n        run: |\n          echo \"Line 1\"\n          echo \"Line 2\"\n      - name: Conditional\n        if: ${{ github.ref == 'refs\u002Fheads\u002Fmain' }}\n        run: echo \"Main branch\"\n```\n\n**Practical Example:** A multi-line script using `|` to preserve newlines. A list of steps, each with `name` and `run`.\n\n**Production Scenarios:** Use YAML anchors (`&` and `*`) to reuse blocks. Use YAML validators to catch syntax errors.\n\n**Debugging Strategies:** Use online YAML linter. `cat` the file in workflow to inspect.\n\n**Common Mistakes:** Using tabs (causes parsing errors). Missing spaces after colon. Incorrect booleans (`yes` not allowed, use `true`).\n\n**Edge Cases:** Special characters must be quoted. `${{ }}` is GitHub expression syntax, not YAML.\n\n**Security Best Practices:** Avoid interpolating user input directly into YAML (can cause injection).\n\n**Optimization Strategies:** Use YAML anchors to reduce duplication across workflows.\n\n**Deployment Considerations:** Not applicable.\n\n**Monitoring Recommendations:** None.\n\n**Scaling Considerations:** Keep workflows under 500 lines for readability.\n\n**Interview Tip:** Emphasize that YAML is strict: indent with spaces, no tabs. Use validators.\n\n**Common Follow-up:** \"What is the difference between `|` and `>` for multiline strings?\"\n\n**Real-world Example:** A complex workflow uses YAML anchors to define common step templates across 10 jobs, reducing duplication from 500 lines to 150 lines.",[78,94,15,14],"syntax",{"id":96,"category":97,"question":98,"answer":99,"level":10,"tags":100},11,"Build Automation","How do you automate the build process in a CI\u002FCD pipeline?","**Concept Explanation:** Automating the build process means running a series of commands (compilation, bundling, minification, etc.) automatically when code changes. The build produces artifacts (e.g., `.exe`, `.jar`, `.js` bundle, Docker image) that are then tested and deployed. In CI\u002FCD, the build job runs after code checkout and dependency installation.\n\n**CI\u002FCD Workflow Explanation:** Build is a critical stage. It must be reproducible and idempotent. Build artifacts are often uploaded as workflow artifacts or pushed to a registry.\n\n**Internal Pipeline Flow:** Checkout → Install dependencies → Run build command (e.g., `npm run build`) → Produce artifact → Store artifact (upload-artifact, push to registry).\n\n**Setup Explanation:** In GitHub Actions, define a build job with appropriate build command for your stack.\n\n**YAML Configuration Example:**\n```yaml\nbuild:\n  runs-on: ubuntu-latest\n  steps:\n    - uses: actions\u002Fcheckout@v4\n    - uses: actions\u002Fsetup-node@v4\n      with: { node-version: '20' }\n    - run: npm ci\n    - run: npm run build\n    - uses: actions\u002Fupload-artifact@v4\n      with:\n        name: dist\n        path: dist\u002F\n```\n\n**Practical Example:** A React app build: `npm run build` creates a `dist\u002F` folder. The artifact is uploaded for deployment later.\n\n**Production Scenarios:** For Dockerized apps, build step includes `docker build` and push to registry.\n\n**Debugging Strategies:** Add `run: ls -la` after build to verify artifacts. Use `cat` to log build output.\n\n**Common Mistakes:** Not caching dependencies between builds; building twice (once in CI, once in CD).\n\n**Edge Cases:** Build may be skipped if no code changes (via path filters).\n\n**Security Best Practices:** Scan artifacts for vulnerabilities before upload. Use SBOM generation.\n\n**Optimization Strategies:** Cache build dependencies. Use incremental builds. Parallelize build across matrix.\n\n**Deployment Considerations:** Deploy the exact artifact from build, never rebuild in CD.\n\n**Monitoring Recommendations:** Track build time and artifact size trends.\n\n**Scaling Considerations:** For microservices, build each service independently.\n\n**Interview Tip:** Emphasize that build artifacts should be immutable and traceable (e.g., store with commit SHA).\n\n**Common Follow-up:** \"What is the difference between build artifact and Docker image?\"\n\n**Real-world Example:** A Java Spring Boot app: `.\u002Fgradlew build` produces a `.jar` file. CI uploads the jar as artifact, then CD deploys it to EC2 using the same artifact, ensuring consistency.",[101,102,51,14],"build","artifacts",{"id":104,"category":105,"question":106,"answer":107,"level":10,"tags":108},12,"Test Automation","How do you automate testing in a CI\u002FCD pipeline?","**Concept Explanation:** Test automation in CI\u002FCD means running tests (unit, integration, end-to-end, security) automatically on code changes. Tests must be fast, reliable, and deterministic. The pipeline fails if any test fails, preventing bad code from progressing.\n\n**CI\u002FCD Workflow Explanation:** Tests run after build and can run in parallel. Use test reports for visibility. Separate fast unit tests from slow e2e tests.\n\n**Internal Pipeline Flow:** Build → Unit tests (fast, parallel) → Integration tests (requires services) → E2E tests (after deployment to staging) → Security scans.\n\n**Setup Explanation:** In GitHub Actions, add test steps after build. Use `actions\u002Fupload-artifact` for test reports.\n\n**YAML Configuration Example:**\n```yaml\ntest:\n  runs-on: ubuntu-latest\n  steps:\n    - uses: actions\u002Fcheckout@v4\n    - run: npm ci\n    - run: npm run test:unit\n    - run: npm run test:integration\n    - uses: actions\u002Fupload-artifact@v4\n      if: always()\n      with:\n        name: test-reports\n        path: test-results\u002F\n```\n\n**Practical Example:** A Node.js app runs Jest unit tests in parallel (matrix across Node versions), then Playwright e2e tests on staging after deployment.\n\n**Production Scenarios:** Use test splitting to reduce time. Run flaky tests separately with retries.\n\n**Debugging Strategies:** Download test reports as artifacts. Use `--verbose` flag. Record videos for e2e tests.\n\n**Common Mistakes:** Flaky tests causing random failures; slow tests causing long CI; not testing in environment close to production.\n\n**Edge Cases:** Tests requiring secrets (e.g., API keys) use GitHub Secrets.\n\n**Security Best Practices:** Run SAST\u002FDAST tools in CI. Don't hardcode test credentials.\n\n**Optimization Strategies:** Run only affected tests (using tools like Jest's `--changedSince`). Use test splitting (parallel).\n\n**Deployment Considerations:** Run e2e tests on staging before production deployment.\n\n**Monitoring Recommendations:** Track test pass rate and duration. Alert on flaky tests.\n\n**Scaling Considerations:** For monorepos, run tests only for changed packages using `nx affected:test`.\n\n**Interview Tip:** Emphasize that CI tests must be deterministic. Flaky tests erode trust and should be fixed or quarantined.\n\n**Common Follow-up:** \"How do you handle end-to-end tests in CI?\"\n\n**Real-world Example:** A banking app runs 50,000 unit tests in 2 minutes using parallelization, then deploys to staging and runs 500 e2e tests (Cypress) across 10 parallel runners, completing in 10 minutes.",[109,51,110,111],"testing","unit-tests","e2e",{"id":113,"category":114,"question":115,"answer":116,"level":10,"tags":117},13,"Deployment Automation","What is deployment automation and how do you set up a basic deployment pipeline?","**Concept Explanation:** Deployment automation is the process of automatically moving built artifacts to target environments (staging, production) without manual steps. It includes configuring servers, restarting services, updating databases, and verifying health. Automation reduces human error and deployment time.\n\n**CI\u002FCD Workflow Explanation:** After successful build and test, the CD pipeline deploys the artifact. For a VPS, this might involve SSH, copying files, restarting PM2. For cloud, it might use CLI tools (aws, gcloud).\n\n**Internal Pipeline Flow:** Build → Test → Package → Deploy to staging → Smoke tests → (approval) → Deploy to production → Health check.\n\n**Setup Explanation (VPS with SSH):** Use `easingthemes\u002Fssh-deploy` or `appleboy\u002Fscp-action` GitHub Actions.\n\n**YAML Configuration Example (VPS deployment):**\n```yaml\ndeploy:\n  runs-on: ubuntu-latest\n  needs: build\n  environment: production\n  steps:\n    - uses: actions\u002Fcheckout@v4\n    - name: Deploy to VPS\n      uses: appleboy\u002Fscp-action@v0.1.7\n      with:\n        host: ${{ secrets.VPS_HOST }}\n        username: ${{ secrets.VPS_USER }}\n        key: ${{ secrets.SSH_KEY }}\n        source: \"dist\u002F*\"\n        target: \"\u002Fvar\u002Fwww\u002Fapp\"\n    - name: Restart PM2\n      uses: appleboy\u002Fssh-action@v1.0.0\n      with:\n        host: ${{ secrets.VPS_HOST }}\n        username: ${{ secrets.VPS_USER }}\n        key: ${{ secrets.SSH_KEY }}\n        script: pm2 restart app\n```\n\n**Practical Example:** A Node.js app deployed to a DigitalOcean droplet. On merge to main, GitHub Actions SSH's into the server, pulls latest code, runs `npm install`, and restarts with PM2.\n\n**Production Scenarios:** For zero-downtime, use blue-green or rolling deployments. For serverless, use CLI (e.g., `vercel --prod`).\n\n**Debugging Strategies:** Add `run: cat \u002Fvar\u002Flog\u002Fdeploy.log` in SSH step. Use `--dry-run` flags.\n\n**Common Mistakes:** Hardcoding server IPs; not handling rollback; deploying without health checks.\n\n**Edge Cases:** Database migrations must run before new code version. Use separate migration job.\n\n**Security Best Practices:** Never store SSH keys in code. Use GitHub Secrets. Rotate keys regularly.\n\n**Optimization Strategies:** Deploy only changed files (rsync). Use deployment slots for zero-downtime.\n\n**Deployment Considerations:** Have a rollback plan. Test rollback in staging.\n\n**Monitoring Recommendations:** Monitor deployment duration and success rate. Use deployment tracking tools (Datadog, New Relic).\n\n**Scaling Considerations:** For microservices, deploy each service independently with its own pipeline.\n\n**Interview Tip:** Emphasize that deployment automation should be idempotent – running it multiple times should be safe.\n\n**Common Follow-up:** \"How do you handle database migrations in automated deployment?\"\n\n**Real-world Example:** A SaaS company deploys 30 times per day using GitHub Actions to AWS ECS. The pipeline includes rolling updates, health checks, and automatic rollback if health checks fail.",[24,51,118,119,120],"vps","ssh","pm2",{"id":122,"category":123,"question":124,"answer":125,"level":10,"tags":126},14,"Environment Variables","How do you use environment variables in GitHub Actions?","**Concept Explanation:** Environment variables in GitHub Actions store configuration values (API endpoints, feature flags, non-secret settings). They can be set at workflow, job, or step level. Variables are exposed to all steps in that scope. Secrets are encrypted variables (see separate question).\n\n**CI\u002FCD Workflow Explanation:** Environment variables customize pipeline behavior without changing code. For example, `NODE_ENV=test` changes test behavior.\n\n**Internal Pipeline Flow:** Variables are injected into the runner's environment. Steps can read them via `$VAR` or `${{ env.VAR }}`.\n\n**Setup Explanation:** Set variables using `env` key. Can also set dynamically using `set-env` (legacy) or `echo \"VAR=value\" >> $GITHUB_ENV`.\n\n**YAML Configuration Example:**\n```yaml\nenv:\n  NODE_VERSION: '20'\n  API_BASE: 'https:\u002F\u002Fapi.example.com'\n\njobs:\n  build:\n    runs-on: ubuntu-latest\n    env:\n      JOB_VAR: 'job-specific'\n    steps:\n      - name: Set dynamic var\n        run: echo \"DYNAMIC_VAR=$(date)\" >> $GITHUB_ENV\n      - name: Use vars\n        run: echo \"${{ env.NODE_VERSION }}\" && echo \"$DYNAMIC_VAR\"\n      - env:\n          STEP_VAR: 'step-only'\n        run: echo $STEP_VAR\n```\n\n**Practical Example:** Set `ENVIRONMENT=staging` for deploy job to differentiate staging vs prod deployments.\n\n**Production Scenarios:** Use environment variables for feature flags, region selection, or build variants.\n\n**Debugging Strategies:** Print all env vars: `run: env`. Use `${{ toJSON(env) }}`.\n\n**Common Mistakes:** Using environment variables for secrets (use secrets instead). Forgetting that `${{ env.VAR }}` is evaluated before run.\n\n**Edge Cases:** Environment variables cannot override reserved names (`GITHUB_*`, `RUNNER_*`). Max length 64KB.\n\n**Security Best Practices:** Never log environment variables that might contain sensitive data. Use secrets for sensitive values.\n\n**Optimization Strategies:** Use environment variables to parameterize reusable workflows.\n\n**Deployment Considerations:** Use different env vars per environment via `environment` configuration.\n\n**Monitoring Recommendations:** Not applicable.\n\n**Scaling Considerations:** For many variables, use `.env` files and read them.\n\n**Interview Tip:** Emphasize the difference between `$VAR` (shell expansion) and `${{ env.VAR }}` (GitHub expression). Use `${{ env.VAR }}` for conditionals.\n\n**Common Follow-up:** \"How do you pass environment variables between jobs?\"\n\n**Real-world Example:** A monorepo pipeline sets `PROJECT_NAME` dynamically based on changed files, then uses that variable to build only that project.",[127,128,14],"environment-variables","config",{"id":130,"category":131,"question":132,"answer":133,"level":10,"tags":134},15,"Secrets Management","How do you manage secrets in GitHub Actions?","**Concept Explanation:** GitHub Secrets are encrypted environment variables used to store sensitive data like API keys, passwords, SSH keys, and tokens. Secrets are set at repository, environment, or organization level. They are never exposed in logs and are masked when printed.\n\n**CI\u002FCD Workflow Explanation:** Secrets are injected into workflow steps as environment variables. They can be passed to actions or used in shell scripts. Secrets are encrypted before storage and decrypted only during workflow execution.\n\n**Internal Pipeline Flow:** When a workflow runs, GitHub decrypts secrets and injects them into runner environment. Runner prevents secrets from being printed (masking). After workflow, secrets are not stored.\n\n**Setup Explanation:** Go to repository Settings → Secrets and variables → Actions → New repository secret. Name it (e.g., `API_KEY`), add value. Use in workflow: `${{ secrets.API_KEY }}`.\n\n**YAML Configuration Example:**\n```yaml\njobs:\n  deploy:\n    runs-on: ubuntu-latest\n    environment: production\n    steps:\n      - name: Use secret\n        run: echo \"Deploying with ${{ secrets.DEPLOY_KEY }}\"\n      - name: Pass to action\n        uses: some\u002Faction@v1\n        with:\n          token: ${{ secrets.GITHUB_TOKEN }}\n      - name: Environment-specific secret\n        run: echo \"${{ secrets.PROD_DB_PASSWORD }}\"\n```\n\n**Practical Example:** A workflow deploying to AWS uses `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` secrets. The keys are never visible in logs.\n\n**Production Scenarios:** Use environment secrets for staging vs production (different API keys). Use organization secrets shared across repos.\n\n**Debugging Strategies:** Secrets are masked; to debug, use `echo \"${#SECRET}\"` to print length. Never print value.\n\n**Common Mistakes:** Storing secrets in code (even commented). Printing secrets. Not rotating secrets.\n\n**Edge Cases:** Secrets have limits (256 per repo, 64KB each). For large secrets, use external vault.\n\n**Security Best Practices:** Use OIDC instead of long-lived secrets for cloud authentication. Rotate secrets regularly. Use minimum permissions principle.\n\n**Optimization Strategies:** Use OpenID Connect (OIDC) for cloud providers to avoid storing static secrets.\n\n**Deployment Considerations:** Different environments need different secrets; use environment-level secrets.\n\n**Monitoring Recommendations:** Audit secret access via GitHub's security logs.\n\n**Scaling Considerations:** For large organizations, use GitHub's secret scanning and push protection.\n\n**Interview Tip:** Emphasize that secrets are never exposed in logs, but they can be leaked via script output. Always sanitize.\n\n**Common Follow-up:** \"What is OIDC and how does it improve secret management?\"\n\n**Real-world Example:** A company uses GitHub Secrets for database passwords and API keys. For AWS, they switched to OIDC, eliminating the need to store AWS keys in GitHub, reducing risk.",[135,136,137,14],"secrets","security","encryption",{"id":139,"category":140,"question":141,"answer":142,"level":10,"tags":143},16,"Trigger Events","What are trigger events in GitHub Actions? Explain push, pull_request, and workflow_dispatch.","**Concept Explanation:** Trigger events determine when a workflow runs. Common events: `push` (code push to branch), `pull_request` (PR opened, updated, merged), `workflow_dispatch` (manual trigger from UI), `schedule` (cron), `release` (published release), and many more.\n\n**CI\u002FCD Workflow Explanation:** Choose appropriate events: CI runs on pull_request; CD runs on push to main; manual approval on workflow_dispatch.\n\n**Internal Pipeline Flow:** GitHub sends event payload to Actions service. The workflow is evaluated: if event type matches and branch\u002Fpath filters pass, workflow runs.\n\n**Setup Explanation:** In workflow YAML, use `on:` with event name and optional filters.\n\n**YAML Configuration Example:**\n```yaml\n# Run on push to main or staging\non:\n  push:\n    branches: [ main, staging ]\n\n# Run on PR to main, but skip if only docs change\non:\n  pull_request:\n    branches: [ main ]\n    paths-ignore:\n      - 'docs\u002F**'\n\n# Manual trigger with inputs\non:\n  workflow_dispatch:\n    inputs:\n      environment:\n        description: 'Deploy target'\n        required: true\n        default: 'staging'\n        type: choice\n        options: [staging, production]\n\n# Multiple events\non: [push, pull_request, workflow_dispatch]\n```\n\n**Practical Example:** A typical setup: `pull_request` triggers CI (tests, lint). `push` to main triggers CD (build, deploy staging). `workflow_dispatch` allows manual production deployment.\n\n**Production Scenarios:** Use `pull_request_target` with caution (security). Use `schedule` for nightly builds.\n\n**Debugging Strategies:** Check the event payload using `github.event` context. Add `run: echo '${{ toJSON(github.event) }}'`.\n\n**Common Mistakes:** Forgetting that `pull_request` runs on PR head, not target branch. Not using `paths-ignore` causing unnecessary runs.\n\n**Edge Cases:** `push` to tag triggers but branch filters ignore tags. Use `tags` filter separately.\n\n**Security Best Practices:** Be careful with `pull_request_target` (runs in context of target branch, can be exploited).\n\n**Optimization Strategies:** Use `paths-ignore` to skip CI for docs. Use `branches-ignore`.\n\n**Deployment Considerations:** Use `release` event to trigger production deployment only when a release is published.\n\n**Monitoring Recommendations:** Not applicable.\n\n**Scaling Considerations:** For monorepo, use `paths` to run workflows only for changed subprojects.\n\n**Interview Tip:** Emphasize that `pull_request` event runs against the merge commit between PR head and base, which is the best for testing before merge.\n\n**Common Follow-up:** \"What is the difference between `pull_request` and `pull_request_target`?\"\n\n**Real-world Example:** A project runs security scans on `schedule` (daily), unit tests on `pull_request`, e2e tests on `push` to main, and manual approval for production deployment via `workflow_dispatch`.",[144,145,146,147,148],"triggers","events","push","pull_request","workflow_dispatch",{"id":150,"category":151,"question":152,"answer":153,"level":10,"tags":154},17,"Docker Basics","What is Docker and how is it used in CI\u002FCD pipelines?","**Concept Explanation:** Docker is a containerization platform that packages applications and dependencies into isolated containers. In CI\u002FCD, Docker ensures consistency across environments: the same container runs on developer machine, CI, and production. Pipelines can build Docker images, run tests in containers, and push images to registries.\n\n**CI\u002FCD Workflow Explanation:** Docker is used in CI to create reproducible build environments, in testing to spin up dependencies (databases, message queues), and in CD to deploy immutable containers to orchestrators (Kubernetes, ECS).\n\n**Internal Pipeline Flow:** CI runner executes `docker build` to create image, `docker push` to registry. CD pulls image and deploys. Tests can run `docker-compose up` to start dependent services.\n\n**Setup Explanation:** Install Docker on runner (GitHub-hosted runners have it preinstalled). Create `Dockerfile` in repository.\n\n**YAML Configuration Example:**\n```yaml\njobs:\n  docker:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - name: Build image\n        run: docker build -t myapp:${{ github.sha }} .\n      - name: Run tests in container\n        run: docker run myapp:${{ github.sha }} npm test\n      - name: Log in to registry\n        uses: docker\u002Flogin-action@v3\n        with:\n          username: ${{ secrets.DOCKER_USERNAME }}\n          password: ${{ secrets.DOCKER_PASSWORD }}\n      - name: Push image\n        run: docker push myapp:${{ github.sha }}\n```\n\n**Practical Example:** A Node.js app with Dockerfile. CI builds the image, runs tests inside container, pushes to Docker Hub. CD pulls and deploys to Kubernetes.\n\n**Production Scenarios:** Multi-stage Dockerfiles for smaller production images. Use distroless or alpine base for security.\n\n**Debugging Strategies:** Run `docker logs` on container. Use `docker run --entrypoint \u002Fbin\u002Fbash` to debug.\n\n**Common Mistakes:** Large image sizes (slow push\u002Fpull). Not using `.dockerignore` (build context huge). Running as root.\n\n**Edge Cases:** Docker caching in CI: use `docker build` with layer caching. Use `actions\u002Fcache` for Docker layers.\n\n**Security Best Practices:** Scan images for vulnerabilities (Trivy, Snyk). Use non-root user. Never store secrets in images.\n\n**Optimization Strategies:** Use BuildKit for parallel builds. Cache dependencies. Use alpine base.\n\n**Deployment Considerations:** Use image tags like `commit-sha` for immutable deployments, `latest` for development.\n\n**Monitoring Recommendations:** Track image size, build time, and vulnerability count.\n\n**Scaling Considerations:** Use Docker registry mirror for faster pulls in CI.\n\n**Interview Tip:** Emphasize that Docker provides consistency: \"works on my machine\" becomes \"works in container on any machine.\"\n\n**Common Follow-up:** \"What is the difference between Docker image and container?\"\n\n**Real-world Example:** A fintech company uses Docker in CI to run integration tests with PostgreSQL and Redis containers using `docker-compose`, ensuring tests run identically on developer laptops and CI servers.",[155,156,101,157],"docker","containers","registry",{"id":159,"category":160,"question":161,"answer":162,"level":10,"tags":163},18,"Frontend Deployment","What is a basic frontend deployment flow (React\u002FVue) using CI\u002FCD?","**Concept Explanation:** A frontend deployment flow typically: build static assets (HTML, CSS, JS), then upload to hosting platform (Vercel, Netlify, S3 + CloudFront). CI\u002FCD automates this: on merge to main, the pipeline builds the app and deploys to hosting. Preview deployments for PRs are also common.\n\n**CI\u002FCD Workflow Explanation:** For React: `npm run build` produces `build\u002F` folder. Upload to S3 bucket, invalidate CloudFront cache. For Vercel\u002FNetlify: push to git triggers automatic deployment.\n\n**Internal Pipeline Flow:** Checkout → Install dependencies → Build → Upload artifacts → Deploy to hosting → Invalidate CDN.\n\n**Setup Explanation (S3 + CloudFront):** Use `aws-actions\u002Fconfigure-aws-credentials` and `aws s3 sync`.\n\n**YAML Configuration Example (React to S3):**\n```yaml\nname: Deploy React App\non:\n  push:\n    branches: [main]\njobs:\n  deploy:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-node@v4\n        with: { node-version: '20' }\n      - run: npm ci\n      - run: npm run build\n      - uses: aws-actions\u002Fconfigure-aws-credentials@v4\n        with:\n          aws-access-key-id: ${{ secrets.AWS_KEY }}\n          aws-secret-access-key: ${{ secrets.AWS_SECRET }}\n          aws-region: us-east-1\n      - run: aws s3 sync build\u002F s3:\u002F\u002Fmy-bucket --delete\n      - run: aws cloudfront create-invalidation --distribution-id ${{ secrets.DIST_ID }} --paths \"\u002F*\"\n```\n\n**Practical Example:** A React portfolio site. On push to main, GitHub Actions builds and deploys to S3. A CloudFront invalidation ensures CDN serves new files.\n\n**Production Scenarios:** For Vercel, just connect GitHub; every push deploys automatically. For Netlify, similar.\n\n**Debugging Strategies:** Check build logs, S3 bucket contents, CloudFront invalidation status. Use `--dryrun` with `aws s3 sync`.\n\n**Common Mistakes:** Forgetting to invalidate CloudFront cache; not using `--delete` causing orphaned files; not configuring bucket as static website.\n\n**Edge Cases:** Large assets (images) should be optimized in build. Use `--exclude` for certain files.\n\n**Security Best Practices:** Use OIDC for AWS instead of long-lived keys. Bucket should not be public; use CloudFront origin access control.\n\n**Optimization Strategies:** Use `npm ci` instead of `npm install`. Cache `node_modules`. Use `gzip` compression on S3.\n\n**Deployment Considerations:** Use environment variables for API endpoints (e.g., `REACT_APP_API_URL`).\n\n**Monitoring Recommendations:** Use CloudFront access logs. Monitor S3 sync duration.\n\n**Scaling Considerations:** For high-traffic sites, use CDN (CloudFront) and optimize cache headers.\n\n**Interview Tip:** Emphasize that frontend CI\u002FCD is about static asset hosting, but also environment variable injection (build-time vs runtime).\n\n**Common Follow-up:** \"How do you handle environment variables for different environments (staging\u002Fprod)?\"\n\n**Real-world Example:** A Next.js app deployed to Vercel: every PR gets a preview deployment, merge to main deploys to production automatically. No manual YAML needed – Vercel integrates with GitHub.",[164,165,166,167,24],"frontend","react","s3","cloudfront",{"id":169,"category":170,"question":171,"answer":172,"level":10,"tags":173},19,"Backend Deployment","What is a basic backend deployment flow (Node.js) using CI\u002FCD?","**Concept Explanation:** Backend deployment involves building the application (transpiling TypeScript, bundling), packaging into artifacts (Docker image or tarball), and deploying to servers (VPS, EC2, PaaS). The pipeline typically includes running database migrations and restarting the service with zero downtime.\n\n**CI\u002FCD Workflow Explanation:** For a Node.js app on VPS: build, compress, copy via SSH, extract, install dependencies, run migrations, restart with PM2. For Docker: build image, push to registry, pull on server, restart container.\n\n**Internal Pipeline Flow:** Checkout → Install dependencies → Build (TypeScript) → Run tests → Package → (Docker build & push) → Deploy to server → Run migrations → Restart service.\n\n**Setup Explanation (VPS with SSH):** Use `appleboy\u002Fssh-action` to execute remote commands.\n\n**YAML Configuration Example (Node.js to VPS):**\n```yaml\nname: Deploy Node.js\non:\n  push:\n    branches: [main]\njobs:\n  deploy:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-node@v4\n        with: { node-version: '20' }\n      - run: npm ci\n      - run: npm run build\n      - name: Deploy via SSH\n        uses: appleboy\u002Fssh-action@v1.0.0\n        with:\n          host: ${{ secrets.VPS_HOST }}\n          username: ${{ secrets.VPS_USER }}\n          key: ${{ secrets.SSH_KEY }}\n          script: |\n            cd \u002Fvar\u002Fwww\u002Fmyapp\n            git pull\n            npm ci --production\n            npm run migrate\n            pm2 restart myapp\n```\n\n**Practical Example:** A Node.js REST API. On push to main, pipeline runs tests, builds, then SSH into VPS, pulls code, installs production deps, runs database migrations, restarts PM2.\n\n**Production Scenarios:** For zero downtime, use blue-green or rolling with load balancer. For database, run migrations before new code.\n\n**Debugging Strategies:** SSH into server after failed deploy. Check PM2 logs: `pm2 logs myapp`. Add `--dry-run` flags.\n\n**Common Mistakes:** Running migrations after code deploy (should be before or in a way that supports backward compatibility). Not using `--production` flag.\n\n**Edge Cases:** If migration fails, deployment should stop. Use `set -e` in scripts.\n\n**Security Best Practices:** Use non-root SSH user. Restrict SSH key permissions. Use environment variables for secrets.\n\n**Optimization Strategies:** Use `npm ci --production` to skip dev deps. Cache `node_modules`. Use distroless Docker images.\n\n**Deployment Considerations:** Implement health check endpoint; pipeline should verify after restart.\n\n**Monitoring Recommendations:** Integrate with Sentry or New Relic. Monitor PM2 status.\n\n**Scaling Considerations:** For multiple servers, use Ansible or Kubernetes instead of SSH to each.\n\n**Interview Tip:** Emphasize that database migrations are the most critical part; they must be backward-compatible and reversible.\n\n**Common Follow-up:** \"How do you handle database rollbacks on failed deployment?\"\n\n**Real-world Example:** A Laravel backend deployed to DigitalOcean. CI runs PHPUnit, builds assets, then SSH into server, runs `php artisan migrate --force`, and restarts PHP-FPM. Rollback script reverts to previous release folder.",[174,175,118,119,120],"backend","nodejs",[177,187,195,204,214,224,234,244,254,263,272,278,288,298],{"id":178,"category":179,"question":180,"answer":181,"level":182,"tags":183},101,"Advanced GitHub Actions","What are advanced GitHub Actions features like matrix builds, reusable workflows, and composite actions?","**Concept Explanation:** Matrix builds run the same job across multiple configurations (Node versions, OS, dependency sets) in parallel. Reusable workflows allow calling a workflow from another workflow, reducing duplication. Composite actions combine multiple steps into a single action for reuse across workflows.\n\n**CI\u002FCD Workflow Explanation:** Matrix is useful for testing across environments. Reusable workflows centralize logic (e.g., security scan). Composite actions encapsulate multi-step processes (e.g., setup Node + cache + install).\n\n**Internal Pipeline Flow:** Matrix expands into multiple jobs dynamically. Reusable workflows are called via `uses: .\u002F.github\u002Fworkflows\u002Freusable.yml`. Composite actions define steps in `action.yml`.\n\n**Setup Explanation:** For matrix: add `strategy.matrix`. For reusable: create separate workflow with `on: workflow_call`. For composite: create `action.yml` with `runs.using: composite`.\n\n**YAML Configuration Example:**\n```yaml\n# Matrix build\njobs:\n  test:\n    runs-on: ubuntu-latest\n    strategy:\n      matrix:\n        node-version: [18, 20, 22]\n        os: [ubuntu-latest, windows-latest]\n    steps:\n      - uses: actions\u002Fsetup-node@v4\n        with: { node-version: ${{ matrix.node-version }} }\n\n# Reusable workflow (.github\u002Fworkflows\u002Freusable-test.yml)\non: workflow_call\n  inputs:\n    node-version:\n      required: true\n      type: string\njobs: ...\n\n# Calling reusable workflow\njobs:\n  call-test:\n    uses: .\u002F.github\u002Fworkflows\u002Freusable-test.yml\n    with: { node-version: '20' }\n```\n\n**Practical Example:** A library tested on Node 18, 20, 22 and Windows, Linux, macOS using matrix, reducing code duplication by 90%.\n\n**Production Scenarios:** Matrix builds for cross-platform compatibility. Reusable workflows for security scanning across 50 repositories.\n\n**Debugging Strategies:** Matrix builds have separate logs per combination. Use `matrix` context to log values.\n\n**Common Mistakes:** Too many matrix combinations (costly). Not setting `fail-fast: false` causing all jobs to stop on first failure.\n\n**Edge Cases:** Matrix can include up to 256 jobs. Use `include`\u002F`exclude` for specific combinations.\n\n**Security Best Practices:** Reusable workflows from public repos can be risky; pin by SHA.\n\n**Optimization Strategies:** Cache dependencies per matrix combination. Use `if: matrix.node-version == '20'` for selective steps.\n\n**Deployment Considerations:** Not directly applicable.\n\n**Monitoring Recommendations:** Track matrix job durations to identify slowest combination.\n\n**Scaling Considerations:** For large matrices, use `max-parallel` to limit concurrency.\n\n**Interview Tip:** Emphasize that matrix is the easiest way to test across environments. Reusable workflows are the key to DRY CI\u002FCD.\n\n**Common Follow-up:** \"How do you pass secrets to reusable workflows?\"\n\n**Real-world Example:** A company with 100 microservices uses one reusable workflow for CI, called from each repository with different inputs, reducing maintenance overhead by 90%.","intermediate",[184,185,186,14],"matrix","reusable-workflows","composite-actions",{"id":188,"category":189,"question":190,"answer":191,"level":182,"tags":192},102,"Self-Hosted Runners","How do you set up and manage self-hosted runners for GitHub Actions in production?","**Concept Explanation:** Self-hosted runners are machines you manage that execute GitHub Actions jobs. They provide custom hardware, software, network access, and cost control. You can run them on VMs, Kubernetes, or physical servers. Management includes installing the runner application, autoscaling, and security hardening.\n\n**CI\u002FCD Workflow Explanation:** Self-hosted runners are useful for large builds (need more CPU\u002FRAM), access to internal network (databases, VPC), or specific hardware (GPUs). They require more maintenance than GitHub-hosted runners.\n\n**Internal Pipeline Flow:** GitHub sends job payload to runner via long-polling (or webhook). Runner executes steps and streams logs. After job, runner waits for next job.\n\n**Setup Explanation:** Go to repo\u002Forg settings → Actions → Runners → New runner. Follow OS-specific commands (download, configure). Run `.\u002Fconfig.sh --url https:\u002F\u002Fgithub.com\u002Fowner\u002Frepo --token XXX`.\n\n**YAML Configuration Example:**\n```yaml\njobs:\n  build:\n    runs-on: self-hosted  # or runs-on: [self-hosted, linux, gpu]\n    steps: ...\n```\n\n**Production Scenarios:** Use self-hosted runners for deployment jobs requiring internal network; for CI on ARM architecture; for large monorepo builds needing 32GB RAM.\n\n**Debugging Strategies:** Check runner service logs (`\u002Fhome\u002Frunner\u002Factions-runner\u002F_diag`). Use `.\u002Frun.sh --once` to test. Monitor runner heartbeat via GitHub UI.\n\n**Common Mistakes:** Running self-hosted on laptops (unstable). Not cleaning disk space. Using root user.\n\n**Edge Cases:** Runners can be ephemeral (auto-delete after job). Use `ephemeral: true` in config. Scale to zero when idle.\n\n**Security Best Practices:** Run as non-root. Use dedicated VMs. Isolate per repo\u002Forg. Use `ACTIONS_RUNNER_HOOK_JOB_STARTED` to audit.\n\n**Optimization Strategies:** Use ARM runners for cost savings. Pre-cache Docker images. Use autoscaling with EC2 spot instances.\n\n**Deployment Considerations:** Self-hosted runners for prod deployment must be inside VPC with secure access.\n\n**Monitoring Recommendations:** Use GitHub's runner health API. Monitor runner uptime, queue depth, disk usage.\n\n**Scaling Considerations:** Autoscale using actions-runner-controller (Kubernetes) or aws-actions-runner-terraform.\n\n**Interview Tip:** Emphasize that self-hosted are powerful but require maintenance. Use them only when GitHub-hosted are insufficient.\n\n**Common Follow-up:** \"How do you auto-scale self-hosted runners?\"\n\n**Real-world Example:** A data science team uses self-hosted GPU runners to train models in CI, spinning up EC2 g4dn.xlarge instances on demand and terminating after job completion, saving 80% cost compared to GPU GitHub-hosted.",[193,194,87,14],"self-hosted-runners","scaling",{"id":196,"category":197,"question":198,"answer":199,"level":182,"tags":200},103,"Multi-Environment Deployment","How do you implement multi-environment deployment (dev, staging, production) in GitHub Actions?","**Concept Explanation:** Multi-environment deployment uses separate environments (e.g., dev, staging, prod) each with its own configuration, secrets, and protection rules. GitHub Environments allow setting required reviewers, deployment branches, and environment-specific secrets. Workflows use conditions (`if`) to deploy to appropriate environment based on branch or trigger.\n\n**CI\u002FCD Workflow Explanation:** Common pattern: `dev` deploys on push to `develop` branch, `staging` on push to `main`, `production` on tag or manual trigger. Each environment can have approval gates (e.g., prod requires manual approval).\n\n**Internal Pipeline Flow:** Workflow job specifies `environment: prod`. GitHub checks protection rules (required reviewers, branch restrictions). If approved, job runs with environment-specific secrets.\n\n**Setup Explanation:** Create environments in repo Settings → Environments. Add protection rules (required reviewers, wait timer). Add environment secrets.\n\n**YAML Configuration Example:**\n```yaml\njobs:\n  deploy-dev:\n    if: github.ref == 'refs\u002Fheads\u002Fdevelop'\n    environment: dev\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo \"Deploy to dev\"\n  deploy-staging:\n    if: github.ref == 'refs\u002Fheads\u002Fmain'\n    environment: staging\n    needs: [build]\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo \"Deploy to staging\"\n  deploy-prod:\n    if: github.event_name == 'workflow_dispatch' && github.ref == 'refs\u002Fheads\u002Fmain'\n    environment:\n      name: production\n      url: https:\u002F\u002Fexample.com\n    needs: [deploy-staging]\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo \"Deploy to prod with ${{ secrets.PROD_API_KEY }}\"\n```\n\n**Practical Example:** A SaaS app: dev environment auto-deploys every push, staging auto-deploys from main branch with no approval, production requires manual approval and tag.\n\n**Production Scenarios:** For PCI compliance, production requires 2-person approval. Some use timed deployment windows.\n\n**Debugging Strategies:** Check environment logs in GitHub Actions tab. Review deployment protection rules.\n\n**Common Mistakes:** Using same secrets across environments. Not protecting production branch. Forgetting to set `environment` in job.\n\n**Edge Cases:** Environment URL can be dynamic using `${{ steps.deploy.outputs.url }}`.\n\n**Security Best Practices:** Never use production secrets in non-production environments. Use OIDC per environment.\n\n**Optimization Strategies:** Share build artifacts across environments using `actions\u002Fupload-artifact`.\n\n**Deployment Considerations:** Use `concurrency` to prevent parallel deployments to same environment.\n\n**Monitoring Recommendations:** Track deployment frequency per environment. Alert on approval delays.\n\n**Scaling Considerations:** For many environments (per feature), use dynamic environment names.\n\n**Interview Tip:** Emphasize that environments are about risk management: staging and production should have different protection levels.\n\n**Common Follow-up:** \"How do you pass dynamic URLs between jobs?\"\n\n**Real-world Example:** A fintech company uses GitHub Environments: `dev` (no approval, auto-deploy), `staging` (require QA lead approval), `production` (require security and lead approvals, only on tagged releases).",[201,202,24,203],"environments","multi-environment","approvals",{"id":205,"category":206,"question":207,"answer":208,"level":182,"tags":209},104,"Rollback Strategies","What are rollback strategies in CI\u002FCD and how do you implement automatic rollback on failure?","**Concept Explanation:** Rollback is reverting to a previous known-good version after a failed deployment. Strategies include: redeploying previous artifact, reversing database migrations, or switching traffic back to old version in blue-green deployment. Automatic rollback triggers when health checks or monitoring detect failures.\n\n**CI\u002FCD Workflow Explanation:** After deployment, pipeline runs health checks (e.g., curl \u002Fhealth). If checks fail, pipeline executes rollback step (re-deploy previous image or switch load balancer). Rollback should be tested and fast.\n\n**Internal Pipeline Flow:** Deploy → Health check → (failure) → Rollback → Notify → (success) → Complete.\n\n**Setup Explanation:** In GitHub Actions, use `if: failure()` on rollback job. Store previous artifact tag in variable.\n\n**YAML Configuration Example:**\n```yaml\njobs:\n  deploy:\n    runs-on: ubuntu-latest\n    outputs:\n      version: ${{ steps.tag.outputs.version }}\n    steps:\n      - id: tag\n        run: echo \"version=${{ github.sha }}\" >> $GITHUB_OUTPUT\n      - name: Deploy\n        run: .\u002Fdeploy.sh\n  health-check:\n    needs: deploy\n    runs-on: ubuntu-latest\n    steps:\n      - name: Check health\n        run: curl --fail https:\u002F\u002Fmyapp.com\u002Fhealth || exit 1\n  rollback:\n    needs: [deploy, health-check]\n    if: failure()\n    runs-on: ubuntu-latest\n    steps:\n      - name: Rollback to previous\n        run: .\u002Frollback.sh ${{ needs.deploy.outputs.version }}\n```\n\n**Practical Example:** A Kubernetes deployment: on health check failure, pipeline runs `kubectl rollout undo deployment\u002Fmyapp`.\n\n**Production Scenarios:** For database changes, rollback may require reverse migration scripts. For feature flags, just disable flag.\n\n**Debugging Strategies:** Log health check failures; capture pod logs. Test rollback in staging.\n\n**Common Mistakes:** Not testing rollback. Rolling back database migrations that break forward compatibility.\n\n**Edge Cases:** Partial rollback (some nodes updated) – use blue-green. Canary deployments require automated analysis before rollback.\n\n**Security Best Practices:** Rollback should not re-introduce security vulnerabilities. Rollback logs must be audit-able.\n\n**Optimization Strategies:** Use deployment slots (Azure, AWS ECS) for instant rollback by swapping slots.\n\n**Deployment Considerations:** Rollback should be part of deployment playbook. Set timeout for health checks.\n\n**Monitoring Recommendations:** Track rollback frequency; high frequency indicates deployment process issues.\n\n**Scaling Considerations:** For stateful services, rollback may be complex; prefer canary or blue-green.\n\n**Interview Tip:** Emphasize that rollback is not just a technical mechanism but a business requirement: faster rollback = lower MTTR (Mean Time To Recover).\n\n**Common Follow-up:** \"How do you roll back database migrations?\"\n\n**Real-world Example:** A video streaming service deploys new version to canary cluster (5% traffic). Automated metrics (error rate, latency) are monitored. If error rate spikes, automated rollback reverts traffic to previous version within 2 minutes, long before users notice.",[210,211,212,213],"rollback","failure","health-check","mttr",{"id":215,"category":216,"question":217,"answer":218,"level":182,"tags":219},105,"Blue-Green Deployment","What is blue-green deployment and how do you implement it in CI\u002FCD?","**Concept Explanation:** Blue-green deployment uses two identical production environments (blue = current live, green = new version). Traffic switches from blue to green after green is fully deployed and tested. This enables zero-downtime deployments and instant rollback by switching back.\n\n**CI\u002FCD Workflow Explanation:** Pipeline deploys new version to inactive environment (green), runs smoke tests, then switches load balancer\u002Frouter to green. Previous environment (blue) becomes inactive but can be used for rollback.\n\n**Internal Pipeline Flow:** Deploy to green → Test green → Switch traffic (update load balancer) → Monitor → (if fail) switch back to blue.\n\n**Setup Explanation:** Use cloud provider tools (AWS Elastic Beanstalk with environment swap, Azure Deployment Slots). For self-managed, use load balancer with weighted routing.\n\n**YAML Configuration Example (AWS ECS):**\n```yaml\njobs:\n  deploy-green:\n    runs-on: ubuntu-latest\n    steps:\n      - name: Deploy to green\n        run: |\n          aws ecs update-service --cluster my-cluster --service my-service --task-definition green-task\n          aws ecs wait services-stable --cluster my-cluster --service my-service\n      - name: Test green\n        run: curl https:\u002F\u002Fgreen.myapp.com\u002Fhealth\n      - name: Switch traffic\n        run: |\n          aws elbv2 modify-listener --listener-arn $LISTENER --default-actions Type=forward,TargetGroupArn=$GREEN_TG\n```\n\n**Practical Example:** A web app on AWS: blue environment (production) runs version 1. Green (staging) deploys version 2. After validation, update load balancer to send all traffic to green. Blue kept for rollback.\n\n**Production Scenarios:** For stateful services, blue-green requires shared database (both environments connect to same DB) or database migration coordination.\n\n**Debugging Strategies:** Check green environment health before switching. Test with internal users using session affinity.\n\n**Common Mistakes:** Not testing green enough before switch. Database migration incompatible with both blue and green.\n\n**Edge Cases:** Long-running requests; use connection draining to allow existing requests to finish before switch.\n\n**Security Best Practices:** Both environments must have same security posture. Green should be isolated during testing.\n\n**Optimization Strategies:** Use infrastructure as code to create\u002Fdestroy green environment on demand.\n\n**Deployment Considerations:** Blue-green doubles infrastructure cost temporarily. Consider using deployment slots (Azure) which share same infrastructure.\n\n**Monitoring Recommendations:** Monitor error rates before and after traffic switch. Have dashboards for blue\u002Fgreen metrics.\n\n**Scaling Considerations:** For microservices, blue-green per service requires coordination. Use service mesh (Istio) for fine-grained traffic routing.\n\n**Interview Tip:** Emphasize that blue-green is the gold standard for zero-downtime, but requires careful database management.\n\n**Common Follow-up:** \"How does blue-green work with databases?\"\n\n**Real-world Example:** A large e-commerce site uses blue-green on Kubernetes with Istio: green environment gets 1% traffic for canary, then 100%, all automated in CI\u002FCD pipeline, with automatic rollback on error rate increase.",[220,221,222,223],"blue-green","zero-downtime","load-balancer","aws",{"id":225,"category":226,"question":227,"answer":228,"level":182,"tags":229},106,"Canary Deployment","What is canary deployment and how does it differ from blue-green?","**Concept Explanation:** Canary deployment releases a new version to a small percentage of users (canaries) before full rollout. This reduces risk by exposing the new version to a limited audience. If the canary shows no issues, the rollout continues gradually to 100%. Unlike blue-green, canary is incremental and allows real user validation.\n\n**CI\u002FCD Workflow Explanation:** Deploy new version → Route small % traffic to canary → Monitor metrics → If healthy, increase percentage → Repeat until 100% → If unhealthy, rollback.\n\n**Internal Pipeline Flow:** Deploy canary → Set traffic split (e.g., 5% canary, 95% stable) → Monitor error rate, latency, business metrics → If OK, increase to 20% → Continue → If fail, shift traffic to stable.\n\n**Setup Explanation:** Use service mesh (Istio), load balancer with weighted routing (AWS NLB with weighted target groups), or feature flags.\n\n**YAML Configuration Example (Istio):**\n```yaml\napiVersion: networking.istio.io\u002Fv1beta1\nkind: VirtualService\nspec:\n  http:\n  - route:\n    - destination: { host: myapp, subset: stable }\n      weight: 90\n    - destination: { host: myapp, subset: canary }\n      weight: 10\n```\nCI\u002FCD updates weights in steps.\n\n**Practical Example:** A social media platform releases new feed algorithm to 1% of users. Monitors engagement metrics. If positive, increases to 10%, 50%, 100% over hours.\n\n**Production Scenarios:** Canary is ideal for risk-averse deployments or when real user behavior is hard to simulate.\n\n**Debugging Strategies:** Use request headers to identify canary users. Analyze logs per version.\n\n**Common Mistakes:** Not having automated analysis for canary health (manual is too slow). Releasing canary with significant differences that skew metrics.\n\n**Edge Cases:** Canary affects users differently based on geography; use segmented canaries.\n\n**Security Best Practices:** Canary should receive same security policies as production.\n\n**Optimization Strategies:** Automate analysis with Prometheus metrics and statistical tests (e.g., compare error rate p-values).\n\n**Deployment Considerations:** Canary requires ability to route traffic at a granular level (HTTP headers, IP ranges).\n\n**Monitoring Recommendations:** Real-time dashboard comparing canary vs stable metrics. Set up alerts for anomaly detection.\n\n**Scaling Considerations:** For microservices, canary per service; use service mesh for simplicity.\n\n**Interview Tip:** Emphasize that canary is about confidence: real users tell you if the release works, not just automated tests.\n\n**Common Follow-up:** \"What is the difference between canary and A\u002FB testing?\"\n\n**Real-world Example:** Netflix's canary deployment system (Cassandra) rolls out new database schema to 1% of clusters, monitors compaction latency, and automatically halts if anomalies detected. Full rollout takes days with human approval at each stage.",[230,231,232,233],"canary","gradual-rollout","traffic-splitting","istio",{"id":235,"category":236,"question":237,"answer":238,"level":182,"tags":239},107,"Monorepo CI\u002FCD","How do you structure CI\u002FCD for a monorepo with multiple projects?","**Concept Explanation:** Monorepo CI\u002FCD requires selective execution: only build\u002Ftest\u002Fdeploy projects that changed. Tools like Nx, Turborepo, or Lerna compute affected projects. GitHub Actions can use path filters or custom scripts to determine which projects to process.\n\n**CI\u002FCD Workflow Explanation:** On push, determine changed files using `git diff`. Map files to projects. Run tasks (build, test) only for affected projects. For deployment, deploy only changed services.\n\n**Internal Pipeline Flow:** Checkout → Fetch base branch → Compute affected projects → For each affected project: install deps, build, test → Package → Deploy.\n\n**Setup Explanation:** Use `dorny\u002Fpaths-filter` action to detect changes per folder. Or use Nx with `nx affected:build`.\n\n**YAML Configuration Example (path filter):**\n```yaml\njobs:\n  changes:\n    runs-on: ubuntu-latest\n    outputs:\n      api: ${{ steps.filter.outputs.api }}\n      web: ${{ steps.filter.outputs.web }}\n    steps:\n      - uses: dorny\u002Fpaths-filter@v2\n        id: filter\n        with:\n          filters: |\n            api: 'packages\u002Fapi\u002F**'\n            web: 'packages\u002Fweb\u002F**'\n  test-api:\n    needs: changes\n    if: ${{ needs.changes.outputs.api == 'true' }}\n    runs-on: ubuntu-latest\n    steps:\n      - run: cd packages\u002Fapi && npm test\n```\n\n**Practical Example:** A monorepo with `frontend`, `backend`, `shared`. When `backend` changes, only backend tests run and backend deploys.\n\n**Production Scenarios:** Use Nx for task caching and computation hashing. Use affected commands in CI.\n\n**Debugging Strategies:** Log detected changes. Use `tree` to see affected projects.\n\n**Common Mistakes:** Over-triggering (re-running unchanged projects). Not caching dependencies per project.\n\n**Edge Cases:** Changes in shared library affect multiple projects; must test all dependents.\n\n**Security Best Practices:** Isolate secrets per project; don't pass production secrets to unchanged projects.\n\n**Optimization Strategies:** Use Nx remote caching to share build artifacts across CI runs. Use `nx affected` with parallel.\n\n**Deployment Considerations:** Deploy projects independently; use version tags.\n\n**Monitoring Recommendations:** Track CI time per project; optimize slow ones.\n\n**Scaling Considerations:** For very large monorepos, use Bazel with remote execution.\n\n**Interview Tip:** Emphasize that monorepo CI\u002FCD must be fast; selective testing is mandatory. Nx\u002FTurborepo are industry standards.\n\n**Common Follow-up:** \"How do you handle shared dependencies in monorepo CI?\"\n\n**Real-world Example:** Google's monolithic repository uses Bazel. Changes trigger builds only for affected targets; distributed build cache shares results across millions of daily builds, reducing average build time from hours to minutes.",[240,241,242,243],"monorepo","nx","affected","selective-testing",{"id":245,"category":246,"question":247,"answer":248,"level":182,"tags":249},108,"Caching Strategies","What are caching strategies in GitHub Actions to speed up workflows?","**Concept Explanation:** Caching stores dependencies (node_modules, pip cache, Docker layers) between workflow runs to avoid re-downloading. GitHub provides `actions\u002Fcache` for generic caching. For package managers, there are specialized actions (setup-node caches npm automatically). Caching keys can be exact or partial (restore keys).\n\n**CI\u002FCD Workflow Explanation:** Cache saves time: npm install from 60 seconds → 5 seconds. Strategies: exact key (`npm-lock-${{ hashFiles('package-lock.json') }}`) for perfect hit, restore key for fallback. Cache should be read-only on PRs from forks for security.\n\n**Internal Pipeline Flow:** Step checks for cache hit using key. If hit, restores; else runs install and then saves cache after step.\n\n**Setup Explanation:** Use `actions\u002Fcache@v4` with `path`, `key`, `restore-keys`.\n\n**YAML Configuration Example:**\n```yaml\n- name: Cache node_modules\n  uses: actions\u002Fcache@v4\n  with:\n    path: ~\u002F.npm\n    key: ${{ runner.os }}-node-${{ hashFiles('package-lock.json') }}\n    restore-keys: |\n      ${{ runner.os }}-node-\n- run: npm ci\n```\n\n**Practical Example:** A Node.js app caches `node_modules`. On lockfile change, new cache created; otherwise, restore from previous.\n\n**Production Scenarios:** Docker layer caching with `docker\u002Fbuild-push-action` and `cache-from\u002Fcache-to`. Pip cache for Python. Gradle cache for Java.\n\n**Debugging Strategies:** Inspect cache hit\u002Fmiss logs. Use `steps.cache.outputs.cache-hit`.\n\n**Common Mistakes:** Cache key not including lockfile (stale cache). Cache too large (>10GB limit). Not cleaning cache regularly.\n\n**Edge Cases:** PRs from forks cannot write cache (security). Use `restore-keys` only.\n\n**Security Best Practices:** Cache includes potentially vulnerable dependencies; ensure cache not served to untrusted workflows.\n\n**Optimization Strategies:** Separate caches per OS, Node version. Use `save-always: false` to save only on main branch.\n\n**Deployment Considerations:** Not applicable.\n\n**Monitoring Recommendations:** Track cache hit rate. Alert on decreasing hit rate.\n\n**Scaling Considerations:** For monorepo, use per-project cache keys.\n\n**Interview Tip:** Emphasize that caching is the single biggest performance win in CI; reduce from minutes to seconds.\n\n**Common Follow-up:** \"How do you invalidate cache?\" (Change key, e.g., update lockfile)\n\n**Real-world Example:** A large monorepo with 1000+ dependencies saw npm install time of 2 minutes. With caching, dropped to 10 seconds, reducing total CI time by 40% and saving $500\u002Fmonth in runner costs.",[250,251,252,253],"caching","performance","node_modules","actions-cache",{"id":255,"category":256,"question":257,"answer":258,"level":182,"tags":259},109,"Artifact Management","How do you manage build artifacts across jobs and workflows in GitHub Actions?","**Concept Explanation:** Artifacts are files produced by a workflow (build outputs, test reports, logs) that are persisted after job completion. Use `actions\u002Fupload-artifact` and `actions\u002Fdownload-artifact` to share data between jobs (e.g., build job produces artifact, test jobs consume it). Artifacts can be downloaded from the GitHub UI.\n\n**CI\u002FCD Workflow Explanation:** Build job produces artifact (e.g., `dist\u002F` folder). Test and deploy jobs download artifact. This avoids rebuilding and ensures consistency.\n\n**Internal Pipeline Flow:** Upload step compresses and uploads to GitHub storage. Download step retrieves from same workflow run.\n\n**Setup Explanation:** After build, add `upload-artifact`. In subsequent jobs, add `download-artifact`.\n\n**YAML Configuration Example:**\n```yaml\nbuild:\n  runs-on: ubuntu-latest\n  steps:\n    - run: npm run build\n    - uses: actions\u002Fupload-artifact@v4\n      with:\n        name: dist\n        path: dist\u002F\ntest:\n  needs: build\n  runs-on: ubuntu-latest\n  steps:\n    - uses: actions\u002Fdownload-artifact@v4\n      with:\n        name: dist\n        path: dist\u002F\n    - run: npm run test:dist\ndeploy:\n  needs: test\n  runs-on: ubuntu-latest\n  steps:\n    - uses: actions\u002Fdownload-artifact@v4\n      with:\n        name: dist\n        path: dist\u002F\n    - run: aws s3 sync dist\u002F s3:\u002F\u002Fbucket\n```\n\n**Practical Example:** A React app: build job creates `dist`, uploads artifact; test job downloads and runs end-to-end tests; deploy job downloads and uploads to S3.\n\n**Production Scenarios:** Store test reports as artifacts for debugging. Store SBOM (Software Bill of Materials) as artifact.\n\n**Debugging Strategies:** Download artifacts manually from GitHub UI. Use `list-artifacts` API.\n\n**Common Mistakes:** Uploading large artifacts (>500MB) can be slow; use separate storage (S3) for large files. Not cleaning old artifacts.\n\n**Edge Cases:** Artifacts are retained for 90 days (default). Use `retention-days`.\n\n**Security Best Practices:** Do not upload secrets to artifacts. Artifacts are accessible to anyone with read access to repo.\n\n**Optimization Strategies:** Upload only necessary files; exclude `node_modules`. Use `if-no-files-found: error`.\n\n**Deployment Considerations:** For cross-workflow artifacts, use `actions\u002Fupload-artifact` with different name per workflow.\n\n**Monitoring Recommendations:** None.\n\n**Scaling Considerations:** For huge artifacts (>2GB), use external storage (AWS S3).\n\n**Interview Tip:** Emphasize that artifacts ensure consistency: the exact same build output is tested and deployed.\n\n**Common Follow-up:** \"What is the difference between artifacts and cache?\" (Artifacts = output for later jobs, cache = dependencies for speed)\n\n**Real-world Example:** A Java monorepo: build job compiles 50 modules into a fat JAR (200MB), uploads as artifact. Security scan job downloads it, runs analysis. Deploy job downloads and deploys to Kubernetes. Each job doesn't need to rebuild, saving 10 minutes per run.",[102,260,261,262],"upload","download","build-output",{"id":264,"category":265,"question":266,"answer":267,"level":182,"tags":268},110,"Secrets Management Advanced","What are advanced secret management techniques in GitHub Actions (OIDC, Vault integration, secret rotation)?","**Concept Explanation:** Advanced secret management moves beyond static secrets. OpenID Connect (OIDC) allows workflows to authenticate to cloud providers without long-lived secrets. HashiCorp Vault integration dynamically generates short-lived credentials. Secret rotation involves regularly updating secrets without downtime.\n\n**CI\u002FCD Workflow Explanation:** With OIDC, GitHub issues a JWT token. Cloud provider trusts GitHub and issues temporary credentials. No secrets stored in GitHub. Vault can generate database credentials on-demand per workflow run.\n\n**Internal Pipeline Flow:** Workflow requests OIDC token from GitHub's OIDC provider → Token sent to cloud provider (AWS, Azure) → Cloud validates token and returns temporary credentials → Workflow uses credentials for deployment.\n\n**Setup Explanation (AWS OIDC):** Create AWS IAM Identity Provider for GitHub. Create role with trust policy allowing `repo:owner\u002Frepo`. Use `aws-actions\u002Fconfigure-aws-credentials` with `role-to-assume`.\n\n**YAML Configuration Example (AWS OIDC):**\n```yaml\npermissions:\n  id-token: write\n  contents: read\nsteps:\n  - name: Configure AWS credentials\n    uses: aws-actions\u002Fconfigure-aws-credentials@v4\n    with:\n      role-to-assume: arn:aws:iam::123456789012:role\u002Fgithub-actions-role\n      aws-region: us-east-1\n```\n\n**Vault integration:**\n```yaml\n- name: Get secrets from Vault\n  uses: hashicorp\u002Fvault-action@v2\n  with:\n    url: ${{ secrets.VAULT_URL }}\n    method: jwt\n    path: jwt\u002Fgithub\n    role: my-role\n    secrets: |\n      secret\u002Fdata\u002Fdatabase password | DB_PASSWORD ;\n```\n\n**Practical Example:** A CI pipeline deploys to AWS using OIDC. No AWS keys stored in GitHub. Every run gets fresh credentials valid for 1 hour.\n\n**Production Scenarios:** For compliance, OIDC is mandatory to eliminate static credentials. Vault provides dynamic database users per workflow, limiting blast radius.\n\n**Debugging Strategies:** Check OIDC token with `echo $ACTIONS_ID_TOKEN_REQUEST_TOKEN`. Use `oidc-debug` action.\n\n**Common Mistakes:** Not setting `permissions.id-token: write`. Role trust policy misconfigured.\n\n**Edge Cases:** OIDC token expiration (default 10 minutes). For long workflows, need to refresh.\n\n**Security Best Practices:** Use OIDC for all cloud providers. Rotate Vault tokens regularly. Use short TTL.\n\n**Optimization Strategies:** Cache OIDC tokens? Not needed. Vault responses can be cached for workflow duration.\n\n**Deployment Considerations:** OIDC works with AWS, Azure, GCP, Vault, and others.\n\n**Monitoring Recommendations:** Audit OIDC role usage via cloud provider logs. Monitor Vault secret access.\n\n**Scaling Considerations:** For many repos, use organization-wide OIDC role with condition on repository name.\n\n**Interview Tip:** Emphasize that OIDC is the industry best practice for CI\u002FCD secret management, eliminating the risk of leaked static keys.\n\n**Common Follow-up:** \"How do you handle secret rotation with OIDC?\" (No need; credentials are short-lived per run)\n\n**Real-world Example:** A large e-commerce company migrated 500+ GitHub repos from static AWS keys to OIDC. Within 3 months, zero key-related security incidents occurred, compared to 3 incidents previously. Vault integration provides dynamic PostgreSQL credentials for migrations, automatically revoked after job finishes.",[269,270,271,136,223],"oidc","vault","secret-rotation",{"id":273,"category":274,"question":275,"answer":276,"level":182,"tags":277},111,"React Deployment Pipeline","What is a production-grade React deployment pipeline using GitHub Actions?","**Concept Explanation:** A production React pipeline includes: linting, unit tests, building, end-to-end tests, and deployment with CDN invalidation. It also includes environment-specific builds (staging\u002Fprod) and preview deployments for PRs. Security scanning (npm audit, SAST) and performance budget checks are integrated.\n\n**CI\u002FCD Workflow Explanation:** On PR: lint, test, build (preview). On merge to main: build, deploy to staging, run E2E tests, then deploy to production (manual approval). Production build includes optimizations and environment variables.\n\n**Internal Pipeline Flow:** Checkout → Install → Lint → Unit test → Build → Upload artifact → Deploy to preview\u002Fstaging → E2E tests → Deploy to production → Invalidate CDN.\n\n**Setup Explanation:** Use `actions\u002Fsetup-node`, `npm ci`, `npm run build`. For preview, use Vercel\u002FNetlify or deploy to S3 subfolder.\n\n**YAML Configuration Example:**\n```yaml\nname: React Pipeline\non: [pull_request, push]\njobs:\n  build-test:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-node@v4\n        with: { node-version: '20', cache: 'npm' }\n      - run: npm ci\n      - run: npm run lint\n      - run: npm run test\n      - run: npm run build\n      - uses: actions\u002Fupload-artifact@v4\n        with: { name: build, path: build\u002F }\n  e2e:\n    needs: build-test\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fdownload-artifact@v4\n        with: { name: build, path: build }\n      - name: Serve and test\n        run: |\n          npx serve build &\n          npx wait-on http:\u002F\u002Flocalhost:3000\n          npx cypress run\n  deploy-staging:\n    if: github.ref == 'refs\u002Fheads\u002Fmain'\n    needs: e2e\n    environment: staging\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fdownload-artifact@v4\n        with: { name: build, path: build }\n      - name: Deploy to S3 (staging)\n        run: aws s3 sync build\u002F s3:\u002F\u002Fmyapp-staging --delete\n  deploy-prod:\n    if: github.event_name == 'workflow_dispatch' && github.ref == 'refs\u002Fheads\u002Fmain'\n    needs: deploy-staging\n    environment: production\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fdownload-artifact@v4\n        with: { name: build, path: build }\n      - run: aws s3 sync build\u002F s3:\u002F\u002Fmyapp-prod --delete\n      - run: aws cloudfront create-invalidation --distribution-id ${{ secrets.DIST_ID }} --paths \"\u002F*\"\n```\n\n**Practical Example:** A React e-commerce site. On PR, preview environment created (via Vercel). On merge to main, staging deploys automatically; production requires manual approval.\n\n**Production Scenarios:** For performance, add Lighthouse CI to fail build if performance budget exceeded.\n\n**Debugging Strategies:** Download build artifact to inspect locally. Use `--dryrun` for S3 sync.\n\n**Common Mistakes:** Not invalidating CDN (old files cached). Using development build for production. Not setting `NODE_ENV=production`.\n\n**Edge Cases:** Environment variables: for Vercel\u002FNetlify, they set at build time; for S3\u002FCloudFront, runtime variables require backend.\n\n**Security Best Practices:** Run `npm audit` in CI. Use Content Security Policy headers. Scan S3 bucket for public access.\n\n**Optimization Strategies:** Cache `node_modules`. Use `npm ci` instead of `npm install`. Inline critical CSS.\n\n**Deployment Considerations:** Use CloudFront invalidation for S3. For large sites, use `--exclude` to skip unchanged files.\n\n**Monitoring Recommendations:** Track bundle size over time. Monitor CloudFront cache hit ratio.\n\n**Scaling Considerations:** For high-traffic sites, use CloudFront multi-region.\n\n**Interview Tip:** Emphasize that React CI\u002FCD must consider environment variables (build-time vs runtime) and CDN invalidation.\n\n**Common Follow-up:** \"How do you handle environment variables for React apps in CI\u002FCD?\"\n\n**Real-world Example:** A large React app with 500+ components reduced deployment time from 15 minutes to 5 minutes by caching node_modules and using incremental builds. They also added Lighthouse CI, catching performance regressions before deployment.",[165,164,166,167,111],{"id":279,"category":280,"question":281,"answer":282,"level":182,"tags":283},112,"Nuxt Deployment Pipeline","How do you deploy a Nuxt application with SSR in CI\u002FCD?","**Concept Explanation:** Nuxt SSR deployment requires Node.js server environment. Options: deploy to Vercel (auto-detects Nuxt), deploy to Node.js server (PM2), or deploy as serverless function (AWS Lambda, Netlify Functions). CI\u002FCD pipeline must handle Nuxt build (`nuxt build` for SSR, `nuxt generate` for static).\n\n**CI\u002FCD Workflow Explanation:** For SSR: build step generates `.output` folder (Nitro). For static: generates `dist`. CD step deploys `.output` to server (e.g., VPS with PM2) or to serverless platform.\n\n**Internal Pipeline Flow:** Checkout → Install → Run tests → Build (`nuxt build`) → Package `.output` → Deploy to server → Run migrations (if any) → Restart service.\n\n**Setup Explanation (VPS with PM2):** Build artifact transferred via SSH. Use PM2 to manage Nuxt process.\n\n**YAML Configuration Example (Nuxt to VPS):**\n```yaml\nname: Deploy Nuxt\non:\n  push:\n    branches: [main]\njobs:\n  build:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-node@v4\n        with: { node-version: '20' }\n      - run: npm ci\n      - run: npm run build  # nuxt build\n      - run: tar -czf output.tar.gz .output\u002F\n      - uses: actions\u002Fupload-artifact@v4\n        with: { name: output, path: output.tar.gz }\n  deploy:\n    needs: build\n    runs-on: ubuntu-latest\n    environment: production\n    steps:\n      - uses: actions\u002Fdownload-artifact@v4\n        with: { name: output }\n      - name: Deploy via SSH\n        uses: appleboy\u002Fscp-action@v0.1.7\n        with:\n          host: ${{ secrets.VPS_HOST }}\n          username: ${{ secrets.VPS_USER }}\n          key: ${{ secrets.SSH_KEY }}\n          source: output.tar.gz\n          target: \u002Fvar\u002Fwww\u002Fmyapp\n      - name: Restart\n        uses: appleboy\u002Fssh-action@v1.0.0\n        with:\n          host: ${{ secrets.VPS_HOST }}\n          username: ${{ secrets.VPS_USER }}\n          key: ${{ secrets.SSH_KEY }}\n          script: |\n            cd \u002Fvar\u002Fwww\u002Fmyapp\n            tar -xzf output.tar.gz\n            pm2 restart nuxt-app\n```\n\n**Practical Example:** A marketing site with SSR for SEO. CI builds Nuxt, deploys to VPS with PM2. Staging branch deploys automatically; production requires approval.\n\n**Production Scenarios:** For high traffic, deploy to AWS Lambda with `@nuxt\u002Fnitro` preset `aws-lambda`. For edge, use `vercel-edge` preset.\n\n**Debugging Strategies:** Check PM2 logs on server. Test SSR locally with `node .output\u002Fserver\u002Findex.mjs`.\n\n**Common Mistakes:** Forgetting to set environment variables on server. Not handling Node version mismatch.\n\n**Edge Cases:** For static sites, use `nuxt generate` and deploy to S3\u002FCDN. For hybrid, use `routeRules` in config.\n\n**Security Best Practices:** Never run `npm install` on production server; use built artifact. Use non-root user.\n\n**Optimization Strategies:** Use `npm ci` instead of install. Cache `.nuxt` folder. Use `--preset` for target environment.\n\n**Deployment Considerations:** For zero-downtime, use PM2 cluster mode with reload (`pm2 reload`).\n\n**Monitoring Recommendations:** Monitor PM2 status, memory usage. Use Sentry for SSR errors.\n\n**Scaling Considerations:** For high-scale, deploy to Kubernetes with Nitro preset.\n\n**Interview Tip:** Emphasize that Nuxt 3 (Nitro) deployment is extremely flexible; choose preset based on platform.\n\n**Common Follow-up:** \"How do you handle environment variables in Nuxt SSR?\" (Use `runtimeConfig`)\n\n**Real-world Example:** A news website with Nuxt 3 deploys to Vercel. Every PR gets preview deployment (auto). Merge to main deploys to production with automatic CDN invalidation. Build time: 2 minutes, deploy time: 30 seconds.",[284,285,286,120,287],"nuxt","ssr","nitro","vercel",{"id":289,"category":290,"question":291,"answer":292,"level":182,"tags":293},113,"Laravel Deployment Pipeline","How do you deploy a Laravel application with CI\u002FCD?","**Concept Explanation:** Laravel deployment requires PHP environment, Composer dependencies, environment configuration, database migrations, and queue workers. CI\u002FCD pipeline should run PHPUnit tests, build assets (npm), and deploy to server (VPS, Forge, Envoyer). Zero-downtime deploys using symlinks are common.\n\n**CI\u002FCD Workflow Explanation:** On push, run `composer install`, `npm ci`, PHPUnit, then build assets. Deploy stage copies code to new release directory, runs migrations, updates symlink, restarts queue workers.\n\n**Internal Pipeline Flow:** Checkout → Install Composer deps → Install NPM deps → Compile assets → Run PHPUnit → Build artifact (zip) → Deploy → Run migrations → Update symlink → Restart workers.\n\n**Setup Explanation (Laravel Forge):** Forge provides webhook triggers; can call via GitHub Actions.\n\n**YAML Configuration Example (Deploy to VPS):**\n```yaml\njobs:\n  test:\n    runs-on: ubuntu-latest\n    services:\n      mysql:\n        image: mysql:8\n        env: { MYSQL_DATABASE: test, MYSQL_ROOT_PASSWORD: root }\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - uses: shivammathur\u002Fsetup-php@v2\n        with: { php-version: '8.2', extensions: mbstring, dom, fileinfo }\n      - run: composer install\n      - run: npm ci\n      - run: npm run production\n      - run: php artisan migrate --env=testing\n      - run: php artisan test\n  deploy:\n    needs: test\n    if: github.ref == 'refs\u002Fheads\u002Fmain'\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - name: Deploy via SSH\n        uses: appleboy\u002Fssh-action@v1.0.0\n        with:\n          host: ${{ secrets.VPS_HOST }}\n          username: ${{ secrets.VPS_USER }}\n          key: ${{ secrets.SSH_KEY }}\n          script: |\n            cd \u002Fvar\u002Fwww\u002Flaravel\n            git pull origin main\n            composer install --no-dev --optimize-autoloader\n            npm ci && npm run production\n            php artisan migrate --force\n            php artisan queue:restart\n            php artisan config:cache\n            php artisan route:cache\n            php artisan view:cache\n            sudo systemctl reload php8.2-fpm\n```\n\n**Practical Example:** A Laravel e-commerce site. CI runs PHPUnit and Dusk browser tests. On merge to main, deployment script runs migrations, caches config, restarts queue workers.\n\n**Production Scenarios:** Zero-downtime using symlinks: deploy to `\u002Freleases\u002F{timestamp}`, then symlink `\u002Fcurrent`.\n\n**Debugging Strategies:** Check Laravel logs (`storage\u002Flogs`). Use `php artisan tinker` for debugging.\n\n**Common Mistakes:** Running migrations on every deploy without checking if needed. Not optimizing Composer autoloader for production.\n\n**Edge Cases:** Queue workers must be restarted to pick up new code. Use `php artisan queue:restart`.\n\n**Security Best Practices:** Don't commit `.env`; use environment secrets. Use `--force` for migrations only in production after validation.\n\n**Optimization Strategies:** Use `composer install --no-dev`. Cache npm dependencies. Use `php artisan config:cache` to reduce config loading.\n\n**Deployment Considerations:** Use deployment tool like Envoyer for zero-downtime with rollback capabilities.\n\n**Monitoring Recommendations:** Monitor queue worker memory. Use Laravel Telescope in production.\n\n**Scaling Considerations:** For multiple servers, use deploy tool that supports rolling deploys.\n\n**Interview Tip:** Emphasize that Laravel's config caching and route caching are critical for performance but can cause issues if migrations change them.\n\n**Common Follow-up:** \"How do you handle database migrations in Laravel CI\u002FCD?\"\n\n**Real-world Example:** A Laravel SaaS platform uses GitHub Actions to deploy to 10 servers via Envoyer. The pipeline runs 500+ PHPUnit tests, builds assets, then deploys using blue-green strategy with health checks. Rollback is one-click via Envoyer.",[294,295,296,297,119],"laravel","php","composer","migrations",{"id":299,"category":300,"question":301,"answer":302,"level":182,"tags":303},114,"Node.js Deployment Pipeline","What is a production-grade Node.js deployment pipeline?","**Concept Explanation:** A Node.js deployment pipeline includes: linting, unit tests, integration tests, building (TypeScript transpilation), security scanning, packaging (Docker or tarball), and deployment to servers (VPS, ECS, Kubernetes). Key aspects: zero-downtime, environment configuration, and process management.\n\n**CI\u002FCD Workflow Explanation:** On PR: run lint, unit tests, integration tests (with test DB). On merge to main: build, run e2e tests, create Docker image, push to registry, deploy to staging, then production with approval.\n\n**Internal Pipeline Flow:** Checkout → Install → Lint → Unit test → Build (TypeScript) → Docker build → Security scan → Push to registry → Deploy to staging → E2E tests → Deploy to production.\n\n**Setup Explanation:** Use `actions\u002Fsetup-node`, `npm ci`, `npm run build`. For Docker, use `docker\u002Fbuild-push-action`.\n\n**YAML Configuration Example (Node.js with Docker and ECS):**\n```yaml\nname: Node.js Pipeline\non: [pull_request, push]\njobs:\n  test:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-node@v4\n        with: { node-version: '20', cache: 'npm' }\n      - run: npm ci\n      - run: npm run lint\n      - run: npm run test:unit\n      - run: npm run test:integration\n  docker:\n    needs: test\n    if: github.ref == 'refs\u002Fheads\u002Fmain'\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - name: Build and push\n        uses: docker\u002Fbuild-push-action@v5\n        with:\n          push: true\n          tags: myapp:${{ github.sha }}\n  deploy-staging:\n    needs: docker\n    runs-on: ubuntu-latest\n    environment: staging\n    steps:\n      - name: Deploy to ECS\n        run: |\n          aws ecs update-service --cluster staging --service myapp --task-definition myapp:${{ github.sha }}\n          aws ecs wait services-stable --cluster staging --service myapp\n  e2e:\n    needs: deploy-staging\n    runs-on: ubuntu-latest\n    steps:\n      - run: npm run test:e2e -- --base-url=https:\u002F\u002Fstaging.myapp.com\n  deploy-prod:\n    needs: e2e\n    runs-on: ubuntu-latest\n    environment: production\n    steps:\n      - run: aws ecs update-service --cluster prod --service myapp --task-definition myapp:${{ github.sha }}\n```\n\n**Practical Example:** A Node.js REST API. CI runs tests, builds Docker image, pushes to ECR. CD deploys to ECS Fargate with rolling update.\n\n**Production Scenarios:** For high throughput, use Kubernetes deployment with horizontal pod autoscaling.\n\n**Debugging Strategies:** Use `kubectl logs` for container logs. Enable Node.js debugging port in staging.\n\n**Common Mistakes:** Not handling graceful shutdown (SIGTERM). Missing health checks causing rolling updates to fail.\n\n**Edge Cases:** Database migrations must be backward compatible; run before new version starts.\n\n**Security Best Practices:** Scan Docker images with Trivy. Use non-root user in Dockerfile. Never log secrets.\n\n**Optimization Strategies:** Use multi-stage Docker builds. Cache `node_modules`. Use `npm ci --production` in final stage.\n\n**Deployment Considerations:** Use ECS rolling update (max 200% capacity) for zero downtime.\n\n**Monitoring Recommendations:** Use PM2 or ECS service auto-recovery. Monitor memory leaks (Node.js `--max-old-space-size`).\n\n**Scaling Considerations:** For serverless, deploy to AWS Lambda with `@vercel\u002Fncc` to bundle.\n\n**Interview Tip:** Emphasize that Node.js memory leaks and event loop blocking are common production issues; CI should include stress tests.\n\n**Common Follow-up:** \"How do you handle environment variables in Node.js deployment?\"\n\n**Real-world Example:** A real-time chat app with Node.js uses GitHub Actions to deploy to Kubernetes on GKE. The pipeline runs 3000+ tests, builds Docker image (optimized from 1.2GB to 350MB using multi-stage), and deploys to staging with canary (5% traffic) before full rollout.",[175,155,304,109,24],"ecs",[306,318,325,335,344,353,363,372,378,386,395,405,414,424,433],{"id":307,"category":308,"question":309,"answer":310,"level":311,"tags":312},201,"Kubernetes CI\u002FCD","How do you implement CI\u002FCD for Kubernetes deployments using GitHub Actions?","**Concept Explanation:** CI\u002FCD for Kubernetes involves building container images, pushing to registry, updating Kubernetes manifests (YAML), and applying changes using `kubectl` or GitOps tools like ArgoCD. Deployments use strategies like rolling update, blue-green, or canary. GitHub Actions can interact with Kubernetes using `kubectl` or `helm`.\n\n**CI\u002FCD Workflow Explanation:** Build Docker image → Push to registry → Update image tag in deployment YAML → `kubectl apply` → Wait for rollout status → Verify health.\n\n**Internal Pipeline Flow:** Checkout → Docker build → Push → Update manifest (sed or yq) → kubectl apply → kubectl rollout status.\n\n**Setup Explanation:** Create kubeconfig secret in GitHub Secrets. Use `azure\u002Fk8s-deploy` or `actions-hub\u002Fkubectl` actions.\n\n**YAML Configuration Example:**\n```yaml\njobs:\n  deploy:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - uses: docker\u002Flogin-action@v3\n        with: { registry: ghcr.io, username: ${{ github.actor }}, password: ${{ secrets.GITHUB_TOKEN }} }\n      - run: docker build -t ghcr.io\u002Fmyapp\u002Fmyapp:${{ github.sha }} .\n      - run: docker push ghcr.io\u002Fmyapp\u002Fmyapp:${{ github.sha }}\n      - name: Update manifest\n        run: |\n          sed -i 's|image:.*|image: ghcr.io\u002Fmyapp\u002Fmyapp:${{ github.sha }}|' k8s\u002Fdeployment.yaml\n      - name: Deploy to Kubernetes\n        uses: azure\u002Fk8s-deploy@v5\n        with:\n          namespace: default\n          manifests: k8s\u002Fdeployment.yaml\n          kubeconfig: ${{ secrets.KUBECONFIG }}\n```\n\n**Practical Example:** A microservice on EKS. CI builds image, pushes to ECR. CD updates deployment image tag and applies using kubectl. Rolling update ensures zero downtime.\n\n**Production Scenarios:** Use GitOps with ArgoCD: CI only updates image tag in Git repo; ArgoCD syncs automatically.\n\n**Debugging Strategies:** `kubectl describe pod`, `kubectl logs`, `kubectl rollout history`.\n\n**Common Mistakes:** Not setting `imagePullPolicy: Always` causing old image reuse. Not handling namespace contexts.\n\n**Edge Cases:** Deployment failed rollout triggers rollback; have rollback job.\n\n**Security Best Practices:** Use OIDC for cluster access; never store kubeconfig. Use short-lived tokens.\n\n**Optimization Strategies:** Cache Docker layers; use Kaniko for in-cluster builds. Use `kubectl diff --dry-run` first.\n\n**Deployment Considerations:** Use Helm charts for complex applications; Helm `upgrade --install`.\n\n**Monitoring Recommendations:** Integrate with ArgoCD UI; monitor rollout status via Slack alerts.\n\n**Scaling Considerations:** For multi-cluster, use ArgoCD with cluster secrets.\n\n**Interview Tip:** Emphasize GitOps (ArgoCD\u002FFlux) as the preferred pattern for Kubernetes CD: the cluster pulls from Git, not CI pushes.\n\n**Common Follow-up:** \"How do you rollback a Kubernetes deployment?\"\n\n**Real-world Example:** A fintech company uses GitHub Actions to build images and update image tags in a GitOps repo. ArgoCD watches the repo and deploys to production clusters across 3 regions. Rollback is `git revert` + ArgoCD sync.","advanced",[313,314,315,316,317],"kubernetes","kubectl","gitops","argocd","helm",{"id":319,"category":320,"question":321,"answer":322,"level":311,"tags":323},202,"GitOps","What is GitOps and how do you implement it with ArgoCD and GitHub Actions?","**Concept Explanation:** GitOps is a pattern where Git is the single source of truth for infrastructure and application configuration. The desired state is stored in Git, and an operator (ArgoCD, Flux) continuously reconciles the live environment to match Git. CI only updates Git (image tags, configs); CD is automatic sync.\n\n**CI\u002FCD Workflow Explanation:** CI builds image → pushes registry → updates deployment manifest in Git repo (image tag) → commits & pushes → ArgoCD detects change → applies to cluster.\n\n**Internal Pipeline Flow:** Build image → Test → Update manifest file (using `yq` or `sed`) → Git commit → Git push → ArgoCD syncs cluster.\n\n**Setup Explanation:** Install ArgoCD in cluster. Create Application pointing to Git repo. Give ArgoCD read access (SSH key).\n\n**YAML Configuration Example (CI updating Git):**\n```yaml\n- name: Update manifest\n  run: |\n    yq eval '.spec.template.spec.containers[0].image = \"myapp:${{ github.sha }}\"' -i k8s\u002Fdeployment.yaml\n- name: Commit and push\n  run: |\n    git config user.name \"github-actions\"\n    git add k8s\u002Fdeployment.yaml\n    git commit -m \"Update image to ${{ github.sha }}\"\n    git push origin main\n```\nArgoCD Application:\n```yaml\napiVersion: argoproj.io\u002Fv1alpha1\nkind: Application\nspec:\n  source:\n    repoURL: https:\u002F\u002Fgithub.com\u002Fmyorg\u002Fconfig\n    path: k8s\n  destination:\n    server: https:\u002F\u002Fkubernetes.default.svc\n  syncPolicy:\n    automated:\n      prune: true\n      selfHeal: true\n```\n\n**Practical Example:** A team uses GitOps: developers merge PR → CI builds image → CI updates image tag in manifest repo → ArgoCD syncs production within minutes.\n\n**Production Scenarios:** For multi-env, use separate branches or folders (staging\u002Fprod).\n\n**Debugging Strategies:** Check ArgoCD UI for sync errors. `kubectl describe app -n argocd`.\n\n**Common Mistakes:** Giving CI direct cluster access (bypassing GitOps). Not using `selfHeal` causing drift.\n\n**Edge Cases:** Secret management (SealedSecrets, ExternalSecrets). ConfigMap updates require rolling pods.\n\n**Security Best Practices:** Use SSH deploy keys for Git. Use sealed secrets in Git. ArgoCD should have least privilege.\n\n**Optimization Strategies:** Use `syncPolicy.automated.prune` to remove stale resources. Use `ignoreDifferences` for fields managed by cluster.\n\n**Deployment Considerations:** For canary, use Argo Rollouts with analysis.\n\n**Monitoring Recommendations:** ArgoCD provides Prometheus metrics; set alert on sync failures.\n\n**Scaling Considerations:** For many apps, use ApplicationSet with generator.\n\n**Interview Tip:** Emphasize that GitOps shifts CD left: deployment is just updating a YAML file, not running scripts.\n\n**Common Follow-up:** \"How do you handle secrets in GitOps?\" (Use SealedSecrets, SOPS, or ExternalSecrets)\n\n**Real-world Example:** A large e-commerce company moved from Jenkins pushing to clusters to ArgoCD GitOps. Deployments went from 45 minutes to 5 minutes, and rollbacks are `git revert`.",[315,316,324,313],"flux",{"id":326,"category":327,"question":328,"answer":329,"level":311,"tags":330},203,"Infrastructure as Code","How do you integrate Infrastructure as Code (Terraform) into CI\u002FCD pipelines?","**Concept Explanation:** IaC in CI\u002FCD means automatically applying infrastructure changes when code is merged. Terraform workflows: `terraform plan` (CI) and `terraform apply` (CD). Use Terraform Cloud, GitHub Actions, or Atlantis. State must be managed remotely (S3, GCS, Terraform Cloud).\n\n**CI\u002FCD Workflow Explanation:** On PR: `terraform fmt -check`, `terraform plan`, post comment with plan. On merge to main: `terraform apply -auto-approve`. Production may require manual approval.\n\n**Internal Pipeline Flow:** Checkout → Setup Terraform → `terraform init` → `terraform validate` → `terraform plan` (CI) → (on main) `terraform apply` → Outputs.\n\n**Setup Explanation:** Configure remote backend in `terraform { backend \"s3\" {...} }`. Use OIDC for cloud provider authentication.\n\n**YAML Configuration Example:**\n```yaml\njobs:\n  terraform-plan:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: hashicorp\u002Fsetup-terraform@v3\n      - run: terraform init\n      - run: terraform plan -out=tfplan\n      - uses: actions\u002Fupload-artifact@v4\n        with: { name: tfplan, path: tfplan }\n  terraform-apply:\n    needs: terraform-plan\n    if: github.ref == 'refs\u002Fheads\u002Fmain'\n    environment: production\n    steps:\n      - uses: hashicorp\u002Fsetup-terraform@v3\n      - uses: actions\u002Fdownload-artifact@v4\n        with: { name: tfplan }\n      - run: terraform apply tfplan\n```\n\n**Practical Example:** AWS infrastructure (VPC, subnets, EC2). CI runs plan on PR, posts comment. On merge, apply runs automatically.\n\n**Production Scenarios:** For sensitive changes, use `apply` only on tagged releases or workflow_dispatch with approval.\n\n**Debugging Strategies:** `terraform show tfplan` to inspect. `terraform state list`.\n\n**Common Mistakes:** Not locking state (use DynamoDB). Running `apply` without plan. Hardcoding secrets in `.tf` files.\n\n**Edge Cases:** Drift detection: `terraform plan` will show changes; have pipeline auto-reconcile or alert.\n\n**Security Best Practices:** Never commit `.tfstate`. Use OIDC for cloud access. Use `sensitive = true` for outputs.\n\n**Optimization Strategies:** Cache `.terraform` directory. Use `-parallelism` for large plans.\n\n**Deployment Considerations:** Use Terraform workspaces for env separation.\n\n**Monitoring Recommendations:** Log all `apply` changes via S3 bucket logging. Integrate with CloudTrail.\n\n**Scaling Considerations:** For multi-region, use Terragrunt or module composition.\n\n**Interview Tip:** Emphasize that `terraform plan` must always be run in CI before merge to prevent surprises.\n\n**Common Follow-up:** \"How do you handle Terraform state locking in CI?\"\n\n**Real-world Example:** A startup uses GitHub Actions to manage AWS infrastructure. Every PR shows plan. Merge triggers apply. One bad plan (deleting production database) was caught in PR, preventing disaster.",[331,332,223,333,334],"terraform","iac","plan","apply",{"id":336,"category":337,"question":338,"answer":339,"level":311,"tags":340},204,"Advanced Docker Pipelines","What are advanced Docker build optimizations in CI\u002FCD (layer caching, multi-stage builds, buildx)?","**Concept Explanation:** Advanced Docker builds reduce image size and build time. Multi-stage builds separate build and runtime environments. Layer caching uses Docker cache to avoid rebuilding unchanged layers. Buildx enables multi-platform builds (linux\u002Famd64, arm64) and advanced cache backends (registry cache, inline cache).\n\n**CI\u002FCD Workflow Explanation:** Use `docker build` with `--cache-from` to pull cache from registry. Use GitHub Actions cache for layers. Multi-stage: builder stage compiles, final stage copies only artifacts.\n\n**Internal Pipeline Flow:** Check cache → Build each stage → Push image with cache metadata → On next run, reuse cache.\n\n**Dockerfile Example (multi-stage):**\n```dockerfile\n# Builder\nFROM node:20 AS builder\nWORKDIR \u002Fapp\nCOPY package*.json .\u002F\nRUN npm ci\nCOPY . .\nRUN npm run build\n\n# Runtime\nFROM node:20-slim\nWORKDIR \u002Fapp\nCOPY --from=builder \u002Fapp\u002Fdist .\u002Fdist\nCOPY --from=builder \u002Fapp\u002Fnode_modules .\u002Fnode_modules\nCMD [\"node\", \"dist\u002Findex.js\"]\n```\n\n**YAML Configuration Example (Buildx with cache):**\n```yaml\n- name: Set up Docker Buildx\n  uses: docker\u002Fsetup-buildx-action@v3\n- name: Build and push\n  uses: docker\u002Fbuild-push-action@v5\n  with:\n    push: true\n    tags: myapp:latest\n    cache-from: type=gha\n    cache-to: type=gha,mode=max\n    platforms: linux\u002Famd64,linux\u002Farm64\n```\n\n**Practical Example:** A Node.js app with 200MB node_modules. Multi-stage reduces final image from 1.2GB to 150MB. Cache speeds up builds from 5 min to 30 sec.\n\n**Production Scenarios:** Use `--cache-from` from registry for fast builds. Use `--no-cache` only for security rebuilds.\n\n**Debugging Strategies:** `docker buildx build --progress=plain` to see steps. Inspect layers with `dive`.\n\n**Common Mistakes:** Not invalidating cache correctly (`RUN` order matters). Using huge base images (ubuntu vs alpine).\n\n**Edge Cases:** Buildkit cache mount (`--mount=type=cache`) for package managers (npm, apt) to persist across builds.\n\n**Security Best Practices:** Use distroless or scratch for final stage. Scan image with Trivy.\n\n**Optimization Strategies:** Combine `RUN` commands to reduce layers. Use `.dockerignore`. Use Alpine base for smaller size.\n\n**Deployment Considerations:** For air-gapped environments, use local registry mirror.\n\n**Monitoring Recommendations:** Track image size and build time trends.\n\n**Scaling Considerations:** Buildx with remote driver (Kubernetes) for distributed builds.\n\n**Interview Tip:** Emphasize multi-stage builds are non-negotiable for production; they reduce attack surface and deployment time.\n\n**Common Follow-up:** \"How do you handle npm cache in Docker builds?\"\n\n**Real-world Example:** A Java Spring Boot app with multi-stage build reduced image from 800MB to 120MB. Caching `mvn dependency:go-offline` reduced build time from 10min to 2min, saving $1000\u002Fmonth in CI runner costs.",[155,341,342,250,343],"multi-stage","buildx","image-optimization",{"id":345,"category":346,"question":347,"answer":348,"level":311,"tags":349},205,"Multi-Region Deployments","How do you implement multi-region deployment strategies with GitHub Actions?","**Concept Explanation:** Multi-region deployment replicates applications across geographic regions for high availability, low latency, and disaster recovery. CI\u002FCD must deploy to multiple regions in parallel or sequentially, manage region-specific configs, and coordinate traffic routing (Route53 latency-based, Global Accelerator).\n\n**CI\u002FCD Workflow Explanation:** Build image once, push to multi-region registry (ECR replicas). Deploy to each region (parallel jobs). After deployment, update DNS routing or load balancer weights.\n\n**Internal Pipeline Flow:** Build image → Push to primary registry → Replicate to regional registries → Parallel deploy to region A, B, C → Smoke tests per region → Update Traffic Manager\u002FRoute53.\n\n**Setup Explanation:** Use matrix strategy with region list. Use `needs` to wait for all regions.\n\n**YAML Configuration Example:**\n```yaml\njobs:\n  deploy:\n    strategy:\n      matrix:\n        region: [us-east-1, eu-west-1, ap-southeast-1]\n    runs-on: ubuntu-latest\n    steps:\n      - name: Deploy to ${{ matrix.region }}\n        run: |\n          aws ecs update-service --cluster myapp --service myapp --region ${{ matrix.region }}\n  update-dns:\n    needs: deploy\n    runs-on: ubuntu-latest\n    steps:\n      - run: aws route53 change-resource-record-sets ...\n```\n\n**Practical Example:** A global SaaS deploys to 3 AWS regions. Users are routed to nearest region via Route53 latency records.\n\n**Production Scenarios:** For disaster recovery, deploy active-passive: primary region active, others stand by.\n\n**Debugging Strategies:** Check per-region deployment logs. Use AWS Health Dashboard for region status.\n\n**Common Mistakes:** Not syncing database across regions (use Aurora Global Database). Deploying incompatible versions across regions.\n\n**Edge Cases:** Partial failure – have rollback that reverts all regions.\n\n**Security Best Practices:** Use VPC endpoints per region. Ensure IAM roles are replicated.\n\n**Optimization Strategies:** Use parallel matrix to reduce deployment time. Use `fail-fast: false` to allow other regions to complete even if one fails.\n\n**Deployment Considerations:** Use AWS CodeDeploy with deployment groups across regions.\n\n**Monitoring Recommendations:** Use CloudWatch cross-region dashboards. Set up regional health checks.\n\n**Scaling Considerations:** For many regions (>10), use Infrastructure as Code (Terraform) to manage.\n\n**Interview Tip:** Emphasize that multi-region CI\u002FCD must handle stateful data (databases, session stores). Stateless apps are easier.\n\n**Common Follow-up:** \"How do you synchronize database across regions?\" (Use Aurora Global Database, DynamoDB Global Tables)\n\n**Real-world Example:** A gaming company deploys to 6 AWS regions using GitHub Actions matrix. Build once, push to ECR with replication enabled, then parallel deploy. Global load balancer routes players to closest region. During a US-East outage, traffic shifted automatically to EU-West within 2 minutes.",[350,351,223,352],"multi-region","high-availability","global-deployment",{"id":354,"category":355,"question":356,"answer":357,"level":311,"tags":358},206,"Advanced Rollback Systems","What are advanced rollback strategies including automated canary analysis and automatic rollback?","**Concept Explanation:** Advanced rollback uses real-time metrics to decide if deployment is healthy. Canary analysis compares metrics (error rate, latency) between new and old versions. If metrics degrade, automatic rollback triggers. This requires integration with monitoring systems (Prometheus, Datadog, CloudWatch) and deployment orchestration.\n\n**CI\u002FCD Workflow Explanation:** Deploy canary (5% traffic) → Wait for analysis window → Compare metrics → If healthy, increase to 100% → If unhealthy, rollback immediately.\n\n**Internal Pipeline Flow:** Deploy canary → Enable traffic split → Query metrics API (e.g., Prometheus) → Statistical test (t-test, threshold) → Decision → Either continue or rollback.\n\n**Setup Explanation:** Use Flagger, Argo Rollouts, or custom script with monitoring API.\n\n**YAML Configuration Example (Argo Rollouts):**\n```yaml\napiVersion: argoproj.io\u002Fv1alpha1\nkind: Rollout\nspec:\n  strategy:\n    canary:\n      steps:\n      - setWeight: 5\n      - pause: { duration: 1m }\n      - analysis:\n          templates:\n          - templateName: success-rate\n      - setWeight: 100\n---\napiVersion: argoproj.io\u002Fv1alpha1\nkind: AnalysisTemplate\nspec:\n  metrics:\n  - name: success-rate\n    provider:\n      prometheus:\n        query: |\n          sum(rate(http_requests_total{status!~\"5..\"}[1m])) \u002F\n          sum(rate(http_requests_total[1m]))\n        interval: 1m\n    failureCondition: result \u003C 0.95\n```\n\n**Practical Example:** A payment gateway deploys new version to 5% of users. If error rate > 2% during 2 minutes, auto-rollback.\n\n**Production Scenarios:** Use for high-risk features or infrastructure changes. Integrate with business metrics (conversion rate).\n\n**Debugging Strategies:** Log analysis decisions; check metric queries manually.\n\n**Common Mistakes:** Not having baseline metrics. Short analysis window causing false positives.\n\n**Edge Cases:** Network partitions or monitoring down; rollback must have manual fallback.\n\n**Security Best Practices:** Ensure metric endpoints are authenticated.\n\n**Optimization Strategies:** Use Bayesian analysis for more intelligent decisions.\n\n**Deployment Considerations:** For database migrations, canary only works if schema is backward-compatible.\n\n**Monitoring Recommendations:** Alert on high rollback rate; investigate root cause.\n\n**Scaling Considerations:** For many services, use service mesh with built-in analysis (Istio + Flagger).\n\n**Interview Tip:** Emphasize that automated rollback is a game-changer for deployment confidence. Netflix's \"Automated Canary Analysis\" is industry standard.\n\n**Common Follow-up:** \"What metrics are best for automated rollback?\" (Error rate, latency, throughput, business KPIs)\n\n**Real-world Example:** Netflix's Spinnaker with Kayenta analyzes canary health using Bayesian statistics. They canary every deployment to 1% of traffic for 10 minutes. If failure detected, rollback is automatic, avoiding incidents on 99% of bad deploys.",[230,359,360,361,362],"auto-rollback","analysis","prometheus","argo-rollouts",{"id":364,"category":365,"question":366,"answer":367,"level":311,"tags":368},207,"Pipeline Security","How do you secure CI\u002FCD pipelines against supply chain attacks, credential leaks, and malicious code injection?","**Concept Explanation:** CI\u002FCD security includes: hardening runners (isolated, ephemeral), using OIDC (no static secrets), pinning actions by SHA, scanning dependencies (Dependabot, Snyk), signing artifacts (cosign), and enforcing least privilege (GITHUB_TOKEN permissions). Prevent script injection by not interpolating untrusted variables into `run` commands.\n\n**CI\u002FCD Workflow Explanation:** Security must be layered: code scanning (SAST), dependency scanning, container scanning, secret detection (GitHub Secret Scanning), and runtime security (no privileged runners).\n\n**Internal Pipeline Flow:** Pre-commit hooks → secret scanning on push → dependency audit → SAST → build in isolated runner → sign image → scan image → deploy → runtime policy enforcement.\n\n**Setup Explanation:** Use `actions\u002Fcheckout` with `persist-credentials: false`. Set `permissions` at workflow level.\n\n**YAML Configuration Example (secure workflow):**\n```yaml\nname: Secure CI\non: [push]\npermissions:\n  contents: read  # minimal\n  id-token: write # for OIDC\njobs:\n  build:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fcheckout@v4\n        with:\n          persist-credentials: false\n      - name: Scan secrets\n        uses: trufflehog\u002Ftrufflehog@v3.63\n      - name: SAST\n        uses: github\u002Fcodeql-action\u002Finit@v3\n      - run: npm ci\n      - run: npm audit\n      - name: Docker build\n        run: docker build .\n      - name: Scan image\n        uses: aquasecurity\u002Ftrivy-action@master\n        with: { image-ref: myapp, severity: HIGH }\n```\n\n**Practical Example:** A financial app pipeline fails if any high-severity vulnerability found, prevents deployment to prod.\n\n**Production Scenarios:** Use SLSA framework for build integrity. Use Sigstore for signing.\n\n**Debugging Strategies:** Review security logs; use `ACTIONS_RUNTIME_TOKEN` only when needed.\n\n**Common Mistakes:** Running scripts from PR branches without review. Using `pull_request_target` incorrectly.\n\n**Edge Cases:** Fork PRs have no access to secrets; run only lint\u002Ftest.\n\n**Security Best Practices:** Use ephemeral self-hosted runners for sensitive jobs. Rotate all secrets quarterly.\n\n**Optimization Strategies:** Cache dependency scans results. Use `paths-ignore` for non-code changes.\n\n**Deployment Considerations:** Require signed commits for production deployments.\n\n**Monitoring Recommendations:** Enable GitHub's security tab. Track SBOM for each release.\n\n**Scaling Considerations:** Use GitHub Advanced Security for enterprise.\n\n**Interview Tip:** Emphasize that CI\u002FCD pipelines are a high-value attack target. Treat them with same security as production.\n\n**Common Follow-up:** \"How do you prevent malicious code from entering the pipeline?\"\n\n**Real-world Example:** Codecov breach (2021) where attackers injected secrets via CI. After the incident, companies pinned actions by SHA, added OIDC, and limited GITHUB_TOKEN permissions.",[136,369,370,371,269],"supply-chain","sast","sbom",{"id":373,"category":374,"question":375,"answer":376,"level":311,"tags":377},208,"Performance Optimization","How do you optimize GitHub Actions performance for large monorepos? (caching, self-hosted, matrix optimization, selective execution)","**Concept Explanation:** Large monorepo CI performance requires: selective execution (affected projects), remote caching (Nx, Turborepo), self-hosted large runners, matrix optimization (split tests), and job-level concurrency. Goal: keep CI under 10 minutes.\n\n**CI\u002FCD Workflow Explanation:** Use `nx affected:test` to run only changed projects. Use Nx Cloud or GitHub Actions cache to reuse build outputs across runs. Use parallel matrix to split test suites.\n\n**Internal Pipeline Flow:** Detect changed files → Map to projects → Restore cache → Build affected projects → Run affected tests → Save cache.\n\n**Setup Explanation:** Configure Nx with `nx.json`. Use `nx-set-shas` action.\n\n**YAML Configuration Example (Nx monorepo):**\n```yaml\njobs:\n  build:\n    steps:\n      - uses: actions\u002Fcheckout@v4\n        with: { fetch-depth: 0 }\n      - uses: nrwl\u002Fnx-set-shas@v4\n      - run: npm ci\n      - run: npx nx workspace-lint\n      - run: npx nx affected --target=lint --parallel=3\n      - run: npx nx affected --target=test --parallel=3 --ci --code-coverage\n      - run: npx nx affected --target=build --parallel=3\n```\nCache node_modules:\n```yaml\n- uses: actions\u002Fcache@v4\n  with:\n    path: ~\u002F.npm\n    key: ${{ runner.os }}-node-${{ hashFiles('package-lock.json') }}\n```\n\n**Practical Example:** A monorepo with 50 projects; CI went from 45min to 8min using affected detection and caching.\n\n**Production Scenarios:** Use remote caching with Nx Cloud to share artifacts across CI runners.\n\n**Debugging Strategies:** Use `nx graph` to see dependencies. Profile tasks with `nx run-many --target=test --profile`.\n\n**Common Mistakes:** Not `fetch-depth: 0` causing incorrect affected detection. Not caching `node_modules` per project.\n\n**Edge Cases:** Changes in shared library affect many projects; `affected` still tests all dependents, which is necessary.\n\n**Security Best Practices:** Self-hosted runners must be isolated per repo.\n\n**Optimization Strategies:** Use `parallel` and `max-parallel`. Use `--skip-nx-cache` for debugging.\n\n**Deployment Considerations:** Deployment should only run for changed projects.\n\n**Monitoring Recommendations:** Track CI time per project; identify slow ones for refactor.\n\n**Scaling Considerations:** For massive monorepos (Google scale), use Bazel with remote execution.\n\n**Interview Tip:** Emphasize that modern monorepo CI depends on affected commands and caching. Without these, CI becomes unmanageable.\n\n**Common Follow-up:** \"How do you handle flaky tests in monorepo CI?\"\n\n**Real-world Example:** A company with 200 microservices in a monorepo used Nx and GitHub Actions. CI time dropped from 2 hours to 15 minutes. They saved $10k\u002Fmonth in runner costs by not building everything every time.",[240,241,250,251,242],{"id":379,"category":380,"question":381,"answer":382,"level":311,"tags":383},209,"Zero-Downtime Deployments","What are advanced zero-downtime deployment patterns (readiness probes, connection draining, traffic shifting) and how do you implement them?","**Concept Explanation:** Zero-downtime deployments ensure no user impact during updates. Key patterns: readiness\u002Fliveness probes (k8s), load balancer connection draining (ELB), traffic shifting (blue-green, canary), and graceful shutdown (SIGTERM handling). For databases, use backward-compatible schema changes and dual writes during transition.\n\n**CI\u002FCD Workflow Explanation:** Deploy new version without removing old one, wait for health checks, then shift traffic. Old version is removed only after new version is stable.\n\n**Internal Pipeline Flow:** Start new pods (k8s) → Wait for readiness probes → Add to service (load balancer) → Remove old pods after drain period.\n\n**Setup Explanation:** Kubernetes: `spec.strategy.rollingUpdate.maxSurge=25%, maxUnavailable=0`. Use `terminationGracePeriodSeconds` for draining.\n\n**YAML Configuration Example (Kubernetes rolling update):**\n```yaml\napiVersion: apps\u002Fv1\nkind: Deployment\nspec:\n  strategy:\n    type: RollingUpdate\n    rollingUpdate:\n      maxSurge: 1\n      maxUnavailable: 0\n  template:\n    spec:\n      containers:\n      - name: app\n        readinessProbe:\n          httpGet: { path: \u002Fhealth, port: 8080 }\n          initialDelaySeconds: 5\n        lifecycle:\n          preStop:\n            exec:\n              command: [\"\u002Fbin\u002Fsh\", \"-c\", \"sleep 30\"]\n```\n\n**Node.js graceful shutdown:**\n```js\nprocess.on('SIGTERM', () => {\n  server.close(() => {\n    console.log('Closed remaining connections');\n    process.exit(0);\n  });\n  setTimeout(() => process.exit(1), 10000);\n});\n```\n\n**Practical Example:** A payment API deploys with rolling update. New pods start; when ready, traffic shifts. Old pods receive SIGTERM, finish in-flight requests (30s grace). Zero customers see errors.\n\n**Production Scenarios:** For stateful apps, use Blue-Green with DB migration compatibility.\n\n**Debugging Strategies:** Check pod events: `kubectl describe pod`. Monitor load balancer draining logs.\n\n**Common Mistakes:** Not setting `maxUnavailable: 0` causing downtime. Short termination grace causing connection reset.\n\n**Edge Cases:** Database migrations: add columns before new version, remove after old version no longer needed.\n\n**Security Best Practices:** Health checks should not expose internal details.\n\n**Optimization Strategies:** Use pod anti-affinity to spread across nodes.\n\n**Deployment Considerations:** For AWS, use NLB with connection draining.\n\n**Monitoring Recommendations:** Track deployment events; alert on long drain times.\n\n**Scaling Considerations:** For many replicas, set `maxSurge` to smaller value to avoid resource spikes.\n\n**Interview Tip:** Emphasize that zero-downtime requires coordination between application (SIGTERM handling) and orchestration (readiness probes).\n\n**Common Follow-up:** \"How do you handle WebSocket connections in zero-downtime deployments?\"\n\n**Real-world Example:** A trading platform uses Kubernetes with `maxUnavailable: 0`. During deploy, new pods start and become ready (health checks pass). Old pods get SIGTERM and finish open orders before exiting. No trade is dropped.",[221,313,384,385],"graceful-shutdown","readiness-probe",{"id":387,"category":388,"question":389,"answer":390,"level":311,"tags":391},210,"Progressive Delivery","What is progressive delivery and how do you integrate feature flags into CI\u002FCD?","**Concept Explanation:** Progressive delivery combines canary deployments, feature flags, and A\u002FB testing to reduce risk. Feature flags decouple deployment from release: code is deployed but hidden behind flags. Flags can be gradually rolled out to users (percentage, user segments). CI\u002FCD pipeline deploys code with flags off, then gradually turns them on.\n\n**CI\u002FCD Workflow Explanation:** Deploy new version with feature flag default off → Test in production (internal users) → Gradually enable flag (1%, 10%, 50%) → Monitor metrics → Fully enable → Remove flag code in next release.\n\n**Internal Pipeline Flow:** Build code with flag placeholder → Deploy to all environments with flag off → CI\u002FCD triggers flag rollout API (LaunchDarkly, Split) → Monitor → Rollback by turning flag off.\n\n**Setup Explanation:** Use LaunchDarkly, Flagsmith, or open-source (Unleash). In code, use `if (flagEnabled) newFeature else oldBehavior`.\n\n**YAML Configuration Example (LaunchDarkly rollout after deploy):**\n```yaml\njobs:\n  deploy:\n    steps:\n      - name: Deploy to prod\n        run: .\u002Fdeploy.sh\n      - name: Enable flag for 10%\n        run: |\n          curl -X PATCH https:\u002F\u002Fapp.launchdarkly.com\u002Fapi\u002Fv2\u002Fflags\u002Fdefault\u002Fnew-feature \\\n          -H \"Authorization: ${{ secrets.LD_TOKEN }}\" \\\n          -d '{\"patch\": [{\"op\":\"replace\",\"path\":\"\u002Ftargeting\u002F0\u002Frollout\",\"value\":10}]}'\n```\n\n**Practical Example:** A checkout page redesign is deployed with flag `new_checkout` off. After verifying 1% of users, flag increased to 100% over 1 hour. Bug found? Turn flag off instantly, no redeploy.\n\n**Production Scenarios:** Use for kill switches (disable broken feature immediately). Use for canary by user segment (internal beta users).\n\n**Debugging Strategies:** Flag evaluation logs; A\u002FB testing analytics.\n\n**Common Mistakes:** Not removing old flag code causing technical debt. Flags not cleaned up after full rollout.\n\n**Edge Cases:** Flag cache latency (seconds). For critical, use flag provider with local evaluation.\n\n**Security Best Practices:** Flag API tokens should be short-lived. Audit flag changes.\n\n**Optimization Strategies:** Use local evaluation SDK to reduce latency.\n\n**Deployment Considerations:** Flag state must be stored externally (LaunchDarkly, etc.) not in code.\n\n**Monitoring Recommendations:** Track flag evaluation rates; monitor flag change log.\n\n**Scaling Considerations:** For high-volume apps, use CDN-backed flag delivery.\n\n**Interview Tip:** Emphasize that feature flags enable trunk-based development and continuous deployment without risk.\n\n**Common Follow-up:** \"How do you test code that depends on feature flags?\"\n\n**Real-world Example:** Netflix's deployment pipeline uses feature flags for almost every change. They deploy code multiple times per hour but enable flags gradually. A problematic feature was disabled globally in 2 seconds after anomaly detection, preventing outage.",[392,393,394,230],"feature-flags","progressive-delivery","launchdarkly",{"id":396,"category":397,"question":398,"answer":399,"level":311,"tags":400},211,"Serverless Deployment","How do you deploy serverless applications (AWS Lambda) with GitHub Actions?","Concept Explanation: Serverless deployments use infrastructure-as-code (SAM, Serverless Framework, CDK). CI\u002FCD builds deployment package (zip or container image), runs integration tests, and deploys to AWS Lambda. Deployments are fast and involve traffic shifting (aliases, weights) for zero-downtime.\n\nCI\u002FCD Workflow Explanation: Build → Package (zip) → Upload to S3 → Deploy via CloudFormation → Smoke test → Shift traffic (if alias).\n\nInternal Pipeline Flow: Checkout → Setup Node\u002FPython → Install deps → Run tests → Build (zip) → Upload to S3 → Deploy SAM → Run post-deploy tests.\n\nSetup Explanation: Use aws-actions\u002Fsetup-sam. Add deploy step.\n\nYAML Configuration Example (SAM):\nyaml\njobs:\n deploy:\n runs-on: ubuntu-latest\n steps:\n - uses: actions\u002Fcheckout@v4\n - uses: aws-actions\u002Fsetup-sam@v2\n - uses: aws-actions\u002Fconfigure-aws-credentials@v4\n with:\n role-to-assume: arn:aws:iam::xxx:role\u002Fsam-deploy-role\n - run: sam build\n - run: sam deploy --no-confirm-changeset --stack-name myapp --capabilities CAPABILITY_IAM\n\n\nPractical Example: A CRUD API with Lambda + DynamoDB. CI runs tests, then sam deploy updates CloudFormation stack with zero-downtime via Lambda aliases.\n\nProduction Scenarios: Use --fail-on-empty-changeset to detect drift. Use sam deploy --guided for first-time.\n\nDebugging Strategies: Check CloudWatch logs for Lambda. sam logs --stack-name myapp --tail.\n\nCommon Mistakes: Not setting TIMEOUT environment variable causing cold starts. Too large zip package (>50MB can't update inline, use S3).\n\nEdge Cases: Lambda versioning and aliases for blue-green: deploy to new version, then update alias weight.\n\nSecurity Best Practices: Use least-privilege IAM role. Store secrets in Parameter Store or Secrets Manager.\n\nOptimization Strategies: Use Lambda layers for dependencies. Use container images for large runtimes.\n\nDeployment Considerations: For gradual deployments, use CodeDeploy with Linear10PercentEvery1Minute.\n\nMonitoring Recommendations: Use AWS X-Ray. Monitor Lambda errors and duration.\n\nScaling Considerations: For high-throughput, increase memory (more CPU). Use provisioned concurrency.\n\nInterview Tip: Emphasize that serverless deployment is simpler but has constraints: package size, cold starts, timeout.\n\nCommon Follow-up: 'How do you handle database migrations in serverless?' (Run migrations before deploying new Lambda version)\n\nReal-world Example: A startup used GitHub Actions to deploy 50 Lambdas via SAM. Deployment time went from 10 minutes manual to 2 minutes automated. Automatic rollback via CloudFormation saved them during a bad deployment.",[401,402,403,404,223],"serverless","lambda","sam","serverless-framework",{"id":406,"category":407,"question":408,"answer":409,"level":311,"tags":410},212,"Edge Deployment","How do you deploy applications to edge (Cloudflare Workers, Vercel Edge) using CI\u002FCD?","Concept Explanation: Edge deployment pushes code to globally distributed edge nodes (Cloudflare Workers, Vercel Edge Functions, Fastly Compute). CI\u002FCD uses CLI tools (wrangler, vercel). Edge deployments are instant (cold start low) and often have version rollback via API.\n\nCI\u002FCD Workflow Explanation: Build edge bundle → Run tests (local edge runtime) → Deploy to edge staging → E2E tests → Deploy to production (with gradual rollout if supported).\n\nInternal Pipeline Flow: Checkout → Install deps → Build (esbuild) → Run tests → Deploy to Cloudflare Workers (using wrangler) → Validate.\n\nSetup Explanation: Use cloudflare\u002Fwrangler-action for Workers. Use amondnet\u002Fvercel-action for Vercel.\n\nYAML Configuration Example (Cloudflare Workers):\nyaml\njobs:\n deploy:\n runs-on: ubuntu-latest\n steps:\n - uses: actions\u002Fcheckout@v4\n - uses: actions\u002Fsetup-node@v4\n - run: npm ci\n - run: npm test\n - name: Deploy Worker\n uses: cloudflare\u002Fwrangler-action@v3\n with:\n apiToken: ${{ secrets.CF_API_TOKEN }}\n accountId: ${{ secrets.CF_ACCOUNT_ID }}\n command: deploy\n\n\nPractical Example: A global API deployed to Cloudflare Workers. On merge to main, wrangler deploy pushes to production. Rollback is wrangler rollback.\n\nProduction Scenarios: For canary on Workers, use routes with percentage (Workers supports gradual rollout via --routes).\n\nDebugging Strategies: wrangler tail streams logs. wrangler dev local testing.\n\nCommon Mistakes: Not respecting edge runtime limitations (no Node.js APIs). Large bundle size causing cold start.\n\nEdge Cases: Environment variables must be set via wrangler secret or --env files.\n\nSecurity Best Practices: Never commit .env. Use API tokens with minimal permissions (Workers: edit, not deploy for prod).\n\nOptimization Strategies: Use wrangler deploy --minify. Bundle with esbuild. Use KV for persistence.\n\nDeployment Considerations: For Vercel, every PR gets preview deployment automatically.\n\nMonitoring Recommendations: Use Cloudflare Analytics. Enable Workers Logpush.\n\nScaling Considerations: Edge scales infinitely; no need to worry.\n\nInterview Tip: Emphasize that edge deployment is nearly instantaneous and globally distributed, but has stricter execution limits (CPU time, memory).\n\nCommon Follow-up: 'How do you handle secrets in edge deployments?' (Use environment variables or KV with encryption)\n\nReal-world Example: An authentication service moved to Cloudflare Workers. CI\u002FCD deploys to 275 edge locations in 10 seconds. Pre-GitHub Actions, deployments took 30 minutes across regions.",[411,412,287,413],"edge","cloudflare-workers","wrangler",{"id":415,"category":416,"question":417,"answer":418,"level":311,"tags":419},213,"AWS CI\u002FCD","How do you build a complete AWS CI\u002FCD pipeline using CodePipeline, CodeBuild, and CodeDeploy?","Concept Explanation: AWS native CI\u002FCD: CodePipeline orchestrates stages (Source → Build → Deploy). CodeBuild runs build commands (tests, packaging). CodeDeploy deploys to EC2, ECS, or Lambda. Pipeline can be triggered from GitHub, CodeCommit, or S3. Blue-green deployments, manual approvals, and rollbacks are built-in.\n\nCI\u002FCD Workflow Explanation: Source stage pulls from GitHub. Build stage compiles and runs tests. Deploy stage uses CodeDeploy to deploy to EC2 or ECS with AppSpec file.\n\nInternal Pipeline Flow: CodePipeline artifact passes between stages. CodeBuild uses buildspec.yml. CodeDeploy uses appspec.yml.\n\nSetup Explanation: Use AWS console or CloudFormation. Define pipeline stages. Use codebuild-project and codedeploy-app.\n\nbuildspec.yml example:\nyaml\nversion: 0.2\nphases:\n install:\n runtime-versions: { nodejs: 20 }\n commands: [npm ci]\n build:\n commands: [npm run build]\n post_build:\n commands: [npm test]\nartifacts:\n files: [ '**\u002F*' ]\n base-directory: dist\n\n\nappspec.yml (EC2):\nyaml\nversion: 0.0\nos: linux\nfiles:\n - source: \u002F\n destination: \u002Fvar\u002Fwww\u002Fmyapp\nhooks:\n AfterInstall:\n - location: scripts\u002Finstall_deps.sh\n ApplicationStart:\n - location: scripts\u002Fstart_server.sh\n\n\nPractical Example: A Node.js app deployed to EC2. Push to GitHub triggers CodePipeline, runs tests, deploys to staging, then after approval to production.\n\nProduction Scenarios: Use CodeDeploy with blue-green for ECS to minimize downtime.\n\nDebugging Strategies: Check CodeBuild logs, CodeDeploy deployment logs (EC2 agent logs).\n\nCommon Mistakes: Not setting IAM roles correctly. CodeDeploy agent not installed on EC2.\n\nEdge Cases: CodeBuild may have long queue times; use reserved capacity.\n\nSecurity Best Practices: Use Session Manager instead of SSH keys. Use Secrets Manager for secrets.\n\nOptimization Strategies: Use CodeBuild local builds for testing. Use custom Docker images for faster builds.\n\nDeployment Considerations: Use deployment groups with load balancer for zero-downtime.\n\nMonitoring Recommendations: CloudWatch Events for pipeline failures. SNS notifications.\n\nScaling Considerations: For many pipelines, use Infrastructure as Code (CDK) to manage.\n\nInterview Tip: Emphasize that AWS CodePipeline is fully managed and integrates deeply with other AWS services, but may be less flexible than GitHub Actions.\n\nCommon Follow-up: 'How do you implement manual approval in CodePipeline?'\n\nReal-world Example: A regulated company uses AWS CodePipeline with manual approval gates before production deployment. The pipeline includes security scans (SAST) in CodeBuild, then approval from compliance team, then CodeDeploy to production.",[223,420,421,422,423],"codepipeline","codebuild","codedeploy","cicd",{"id":425,"category":426,"question":427,"answer":428,"level":311,"tags":429},214,"Disaster Recovery","How do you design CI\u002FCD pipelines for disaster recovery and business continuity?","Concept Explanation: DR in CI\u002FCD ensures ability to recover infrastructure and applications in a different region\u002Fcloud after disaster. Pipeline must be able to deploy to DR environment on demand or regularly test failover. Use Infrastructure as Code to rebuild entire stack, cross-region replication of artifacts, and automated failover testing.\n\nCI\u002FCD Workflow Explanation: Regular pipeline deploys to primary region. DR pipeline (or same with different config) deploys to DR region. Failover test pipeline runs periodically (e.g., monthly) to verify DR deployment.\n\nInternal Pipeline Flow: Build image once → Push to multi-region registry → Deploy to primary region → (scheduled) Deploy to DR region → Smoke test DR → (failover) Switch DNS.\n\nSetup Explanation: Use Terraform to define infrastructure. Use GitHub Actions matrix for regions. Use Route53 health checks and failover records.\n\nYAML Configuration Example (DR deployment):\nyaml\njobs:\n deploy-dr:\n if: github.event_name == 'schedule' # monthly DR test\n runs-on: ubuntu-latest\n steps:\n - name: Deploy to DR region\n run: |\n aws ecs update-service --cluster myapp-dr --service myapp --region eu-west-1\n - name: Validate DR deployment\n run: curl https:\u002F\u002Fdr.myapp.com\u002Fhealth\n - name: Failover test\n run: aws route53 change-resource-record-sets --change-batch '{\n \"Changes\":[{\n \"Action\":\"UPSERT\",\n \"ResourceRecordSet\":{\n \"Name\":\"api.myapp.com\",\n \"Type\":\"A\",\n \"Failover\":\"PRIMARY\",\n \"SetIdentifier\":\"dr-test\",\n \"HealthCheckId\":\"...\"}}] }'\n\n\nPractical Example: A fintech app has primary in us-east-1, DR in eu-west-1. Monthly pipeline deploys to DR and tests failover, then fails back.\n\nProduction Scenarios: RTO (Recovery Time Objective) \u003C 1 hour requires fully pre-provisioned DR environment.\n\nDebugging Strategies: Simulate region failure by disabling primary in load balancer.\n\nCommon Mistakes: Not testing DR regularly; database not replicated; DR environment stale.\n\nEdge Cases: DNS propagation delay (TTL). Cache warming in DR region.\n\nSecurity Best Practices: DR environment should have same security posture. IAM roles must be replicated.\n\nOptimization Strategies: Use infrastructure as code to rebuild DR on demand (lower cost).\n\nDeployment Considerations: Database replication (Aurora Global, DynamoDB Global Tables).\n\nMonitoring Recommendations: Monitor replication lag; test DR automatically monthly.\n\nScaling Considerations: For multi-region active-active, pipeline deploys to all regions simultaneously.\n\nInterview Tip: Emphasize that DR is not just infrastructure – pipeline code, artifacts, and secrets must also be recoverable.\n\nCommon Follow-up: 'How do you test DR without impacting production?'\n\nReal-world Example: A SaaS provider uses GitHub Actions to deploy to DR environment weekly. The pipeline runs end-to-end tests using a copy of production data (anonymized). Failover to DR takes 15 minutes (RTO) with zero data loss (RPO zero).",[430,431,432,350],"disaster-recovery","dr","failover",{"id":434,"category":435,"question":436,"answer":437,"level":311,"tags":438},215,"Self-Healing Pipelines","What are self-healing deployment pipelines (automatic retry, flaky test quarantine, auto-rollback)?","Concept Explanation: Self-healing pipelines automatically mitigate transient failures. Techniques: retry flaky steps (with exponential backoff), quarantine flaky tests (mark as not blocking), auto-rollback on deployment failure, and auto-retry of failed jobs (e.g., runner outage).\n\nCI\u002FCD Workflow Explanation: Use continue-on-error for non-critical steps, retry steps using repeat (composite actions). For tests, catalog flaky tests and automatically re-run them; if still fail, mark as failure.\n\nInternal Pipeline Flow: Step fails → Check retry policy → Wait → Retry up to N times → If still fail, either continue or fail pipeline based on criticality.\n\nSetup Explanation: GitHub Actions has continue-on-error and timeout-minutes. For retry, use nick-fields\u002Fretry action.\n\nYAML Configuration Example (retry flaky step):\nyaml\n- name: Retry test\n uses: nick-fields\u002Fretry@v2\n with:\n timeout_minutes: 10\n max_attempts: 3\n command: npm run test:e2e\n\n\nFlaky test quarantine (pseudocode):\nyaml\n- name: Run tests\n run: npm run test\n- name: Retry failed flaky tests\n if: failure()\n run: npm run test:flaky-only\n\n\nAuto-rollback on deployment failure (Kubernetes):\nyaml\n- name: Deploy\n run: kubectl apply -f deployment.yaml\n- name: Check rollout\n run: kubectl rollout status deployment\u002Fmyapp\n- name: Rollback on failure\n if: failure()\n run: kubectl rollout undo deployment\u002Fmyapp\n\n\nPractical Example: A pipeline with end-to-end tests that sometimes fail due to network. Retry 3 times, then fail. This reduces false failures by 90%.\n\nProduction Scenarios: For critical deployments, auto-rollback is mandatory. For pre-merge CI, retries are acceptable.\n\nDebugging Strategies: Log number of retries. Track flaky tests in database.\n\nCommon Mistakes: Retrying too many times (slow pipeline). Not distinguishing flaky vs real failures.\n\nEdge Cases: Infrastructure outage (S3) causing retry to also fail; pipeline must eventually fail.\n\nSecurity Best Practices: Don't retry steps that may have side effects (database migrations).\n\nOptimization Strategies: Use repeat only on idempotent steps. Use max_attempts: 2 for most.\n\nDeployment Considerations: Auto-rollback may cause cascading failures; have circuit breaker.\n\nMonitoring Recommendations: Track retry and rollback rates; identify underlying issues.\n\nScaling Considerations: For many pipelines, use centralized retry policy configuration.\n\nInterview Tip: Emphasize that self-healing pipelines reduce toil but can mask real problems. Monitor failure patterns.\n\nCommon Follow-up: 'How do you identify flaky tests automatically?'\n\nReal-world Example: A large monorepo had 20% of CI failures due to flaky tests. Adding retry (3 attempts) reduced false failures to 2%, saving 4000 developer hours per year.",[439,440,359,441],"self-healing","retry","flaky-tests",1779734544542]