Top 10 AWS Deployment and CI/CD Interview Questions

Welcome back to our AWS Cloud Engineer Interview Series! In Part 1, we covered advanced scenario-based and behavioral questions—exploring VPC architecture, high-level security best practices, and troubleshooting methodologies to showcase your big-picture design skills. In Part 2, we dove into AWS Fundamentals with ten questions on Compute (EC2 instance types, pricing models, Auto Scaling), Storage (S3, EBS, EFS, Glacier), and Databases (RDS, DynamoDB, Aurora), complete with frameworks for structuring your answers and real-world examples. Then, in Part 3, we shifted focus to Networking & Security—examining VPC/subnet design, route tables and NAT gateways, Security Groups vs. NACLs, and IAM (users, groups, roles, policies, and best practices). In Part 4, we turned to Infrastructure as Code—comparing CloudFormation vs. Terraform (modules vs. stacks) and covering drift detection, rollbacks, and version control.

Now, in this final installment, we’ll tackle Deployment & CI/CD—another essential skill set for AWS Cloud Engineers. You’ll find ten common interview questions on:

• CodePipeline & CodeDeploy: Automating your build, test, and deployment stages end-to-end.
• Blue/Green & Canary Deployments: Strategies for minimizing risk, reducing downtime, and rolling back safely.

Each question includes a clear breakdown of what to cover in your response, real-world tie-ins from production scenarios, and tips for demonstrating that you can architect and manage CI/CD pipelines confidently. Mastering these topics shows interviewers you understand how to deliver code rapidly and reliably on AWS. Let’s dive in!

1. “Walk me through the stages of an AWS CodePipeline for a typical web application. How do you integrate CodeBuild and CodeDeploy?”
How to Answer:

• Source Stage:

• Purpose: Detect code changes (e.g., push or pull request) in your source repository (CodeCommit, GitHub, Bitbucket, or S3).
• Key Details: Explain how CodePipeline polls or uses webhooks to trigger. Example: “We store all microservices in a GitHub monorepo and configure a webhook so a push to main automatically starts the pipeline.”

• Build Stage:

• CodeBuild Project: Define a buildspec.yml (or inline) that installs dependencies, compiles code, runs unit tests, and packages artifacts (e.g., a ZIP file, Docker image).
• Environment: Mention using a managed CodeBuild image vs. custom Docker image. Example: “We used the standard AWS Linux 2 runtime with Python 3.9 to run pytest, then uploaded the built artifact to S3.”
• Outputs: Build artifacts (e.g., application binaries, a CloudFormation change set, a Docker image pushed to ECR).

• Test/Approval Stage (Optional):

• Manual Approval: Insert a “Manual Approval” action before deploying to production.
• Automated Testing: Integrate an integration test suite (e.g., via a second CodeBuild job) to run smoke tests against a test environment.
• Example: “After building, we spin up a temporary test stack via CloudFormation, run API integration tests in CodeBuild, then tear down the stack if tests pass.”

• Deploy Stage (CodeDeploy or CloudFormation):

• CodeDeploy Application/Deployment Group:

• Compute Platform: EC2/On-Premises, Lambda, or ECS.
• Deployment Configuration: For EC2, you might choose CodeDeployDefault.OneAtATime (linear), or a custom configuration.

• Deployment Process: CodePipeline pushes the build artifact to S3 or ECR, then triggers CodeDeploy to deploy to target instances (EC2 with CodeDeploy Agent installed) or to an ECS Service.
• Example: “For our Node.js microservices, we built a Docker image, pushed to ECR, and used CodeDeploy’s Blue/Green ECS deployment type. CodePipeline passed the new image URI to CodeDeploy, which updated the ECS service with zero downtime.”

• Post-Deployment Verification (Optional):

• Automated Smoke Tests: Run another CodeBuild job that pings health endpoints on deployed instances.
• Notifications: SNS or ChatOps (Slack) notifications upon successful or failed deployments.

• Real-World Tie-In:

• “In my last role, we had five microservices. Each had its own CodePipeline YAML definition. We used a shared centralized CodeBuild project for running unit tests—passing in the microservice name as an environment variable. After successful build, the pipeline created a CloudFormation change set to compare infrastructure changes (like new load balancer listeners) before invoking CodeDeploy to update our ECS service.”

• Tips:

• Emphasize how you parameterized your pipelines (e.g., using environment variables, parameter overrides).
• Mention how you secured your pipeline (e.g., using KMS-encrypted environment variables, IAM service roles with least privilege).

2. “What is AWS CodeDeploy, and how does it differ between the EC2/On-Premises and Lambda compute platforms?”
How to Answer:

• Purpose of CodeDeploy:

• A fully managed service that automates code deployments to EC2 instances, on-premises servers, Lambda functions, and ECS services.
• Ensures consistent and repeatable deployments—handling in-place, Blue/Green, or Canary strategies.

• EC2/On-Premises Deployments:

• Prerequisites: Install the CodeDeploy agent on each EC2 instance (or on-prem server).
• Application Specification File (appspec.yml):

• Defines hooks (e.g., BeforeInstall, AfterInstall, ApplicationStart) and lists which files to copy where.
• Example snippet:

```
version: 0.0
os: linux
files:
  - source: /
    destination: /var/www/html
hooks:
  BeforeInstall:
    - location: scripts/stop_server.sh
      timeout: 300
      runas: root
  AfterInstall:
    - location: scripts/start_server.sh

```

• Deployment Configurations:

• CodeDeployDefault.OneAtATime (serial), CodeDeployDefault.AllAtOnce, or custom rate-based.
• Creates an Application → Deployment Group → Deployment. Each group maps to one or more EC2 instances (via tags or Auto Scaling groups).

• Rollback Behavior:

• If any hook fails, CodeDeploy can automatically roll back to the previous revision (if enabled).

• Lambda Deployments:

• No Agents Needed: CodeDeploy integrates directly with Lambda’s versioning and aliases.
• Traffic Shifting:

• Define deployment preferences in a JSON file or via the Console (e.g., 10% traffic in 5-minute increments).
• Example: Shift 10% of traffic to new Lambda version every 5 minutes until 100%.

• Automatic Rollback:

• If an alias fails health checks (e.g., 5XX errors exceed threshold), CodeDeploy reverts traffic back to the previous version.

• Example: “We had a Python Lambda behind API Gateway. CodePipeline triggered CodeDeploy to publish a new function version and update the prod alias. We configured a canary traffic shift: 20% traffic for 15 minutes. If logs showed any failures, CodeDeploy rolled back automatically.”

• Key Differences:

• Infrastructure Management:

• EC2/On-Premises: You manage the host OS, install agents, and patch instances.
• Lambda: AWS manages the runtime environment; no agents needed.

• Deployment Granularity:

• EC2: File-based deployments (via appspec.yml), server-side hooks, and instance grouping.
• Lambda: Version/alias based—traffic shifting configurations.

• Rollback Triggers:

• EC2: Based on script exit codes in hooks or custom CloudWatch Alarms.
• Lambda: Formally integrated, since CodeDeploy can monitor alias health automatically.

• Real-World Tie-In:

• “For our Java microservices on EC2, we used appspec.yml to handle stopping the Tomcat server, deploying the new WAR file, and restarting. For a new Go function we built as Lambda, we leveraged Lambda traffic shifting to gradually move 50% of users over for 10 minutes. In both cases, CodePipeline handled invoking CodeDeploy so our devs didn’t need to SSH into servers or update aliases manually.”

• Tips:

• Highlight how your IAM roles were scoped for CodeDeploy (e.g., granting S3 read access for artifacts, EC2 Describe/Tag permissions to locate instances).
• Mention any custom health checks you implemented (e.g., using CloudWatch Alarms for EC2 or Canary tests for Lambda).

3. “Describe how you would implement an automated build and test stage using CodePipeline and CodeBuild. How do you manage secrets such as API keys or database credentials?”
How to Answer:

• Pipeline Configuration:

• Source (GitHub/CodeCommit): Store application code along with a buildspec.yml in the repository root.
• CodeBuild Project:

• Reference your buildspec.yml, which defines phases: install, pre_build, build, post_build.
• Example buildspec.yml:

```
version: 0.2
env:
  variables:
    ENV: "staging"
phases:
  install:
    runtime-versions:
      java: openjdk11
      nodejs: 14
    commands:
      - npm install
  pre_build:
    commands:
      - echo Logging in to Docker registry...
      - $(aws ecr get-login --no-include-email --region $AWS_DEFAULT_REGION)
  build:
    commands:
      - npm test
      - npm run build
      - docker build -t $IMAGE_REPO_NAME:$IMAGE_TAG .
  post_build:
    commands:
      - docker push $IMAGE_REPO_NAME:$IMAGE_TAG
      - printf '[{"name":"%s","imageUri":"%s"}]' $CONTAINER_NAME $IMAGE_URI > imagedefinitions.json
artifacts:
  files:
    - imagedefinitions.json

```

• Managing Secrets:

• Parameter Store (SSM):

• Store database passwords, API tokens in SSM Parameter Store (SecureString).
• In CodeBuild’s environment variables, reference the Parameter Store key:

```
env:
  parameter-store:
    DB_PASSWORD: "/prod/db/password"

```

• CodeBuild’s service role needs ssm:GetParameters permission.

• Secrets Manager:

• Alternatively, store credentials in AWS Secrets Manager and grant the CodeBuild role secretsmanager:GetSecretValue.
• Retrieve secrets via the AWS SDK in build commands:

```
export DB_PASSWORD=$(aws secretsmanager get-secret-value \
  --secret-id myprod/dbpassword \
  --query SecretString --output text)

```

• Automated Testing:

• Unit Tests: Run npm test or pytest in the build phase.
• Integration Tests (Optional): Use a short-lived test environment or use in-memory DB mocking.
• Code Coverage & Reports: Use tools like coverage.py or JaCoCo, store reports in S3 for visibility.

• IAM Role Considerations:

• CodeBuild Service Role:

• Permissions to read source code (e.g., codecommit:GetBranch or git clone via CodePipeline).
• Read/write permissions to S3 or ECR (for artifacts).
• Access to SSM or Secrets Manager.
• If running Terraform or CloudFormation in build, include those permissions as needed.

• Real-World Tie-In:

• “In a recent project, we had five microservices written in Python. Each had its own CodeBuild. We used Parameter Store to store AWS access keys for a third-party analytics API. The buildspec invoked pytest with coverage, then uploaded coverage reports to an S3 bucket so the QA team could review. Only if tests passed did CodePipeline proceed to the deployment stage.”

• Tips:

• Emphasize the use of environment-specific Parameter Store paths (e.g., /prod/app/db_username vs. /staging/app/db_username) to avoid leaking secrets across environments.
• Mention how you locked down the CodeBuild role to only the minimum necessary permissions (least privilege).

4. “How do you configure a CodeDeploy Blue/Green deployment for an ECS service? What are the key configuration steps?”
How to Answer:

• Prerequisites:

• ECS Cluster & Service: An existing ECS cluster running your task definition.
• Target Groups & Load Balancer: One or more ALB target groups—one for “blue” (current) and one for “green” (replacement).
• CodeDeploy ECS Application & Deployment Group:

• In the CodeDeploy Console, create an “ECS” application.
• Create a Deployment Group specifying:

• The ECS cluster name.
• The ECS service name.
• Blue/Green Deployment type.
• Two target groups (Production and Test) and listener ports.

• Task Definition Revisions:

• Every time you want to deploy a new version, register a new task definition revision (e.g., updating the container image tag).
• Your CodePipeline build stage outputs an imagedefinitions.json file that maps container names to image URIs. CodePipeline passes this to the CodeDeploy deploy action.

• Traffic Routing Configuration:

• Canary or Linear Settings (Optional):

• Define how traffic shifts from blue to green (e.g., 10% every 5 minutes).
• Or do “All at Once” (instant cutover) if you have confidence in the image.

• Deployment Steps:

1.                      Build Stage: Build Docker image, push to ECR, produce imagedefinitions.json.
2.                      Deploy Stage (CodeDeploy):

• CodeDeploy creates new Task Definition revision (with updated image).
• ECS spins up green tasks behind the test target group.
• Health checks run (ELB health checks).
• When green tasks pass health checks, CodeDeploy shifts traffic on the ALB listener to the green target group (according to your chosen traffic-shift strategy).
• Once all traffic is on green, CodeDeploy deregisters blue tasks.

• Rollback Behavior:

• If new tasks fail health checks within the configured waiting period, CodeDeploy automatically shifts traffic back to blue tasks and stops the green tasks.
• You can configure alarms (CloudWatch Alarms) to trigger immediate rollback if error rates spike.

• Example:

• “We had a Node.js service running behind an ALB. Our pipeline’s deploy stage was configured with CodeDeploy’s ‘Canary 10% every 2 minutes.’ When we pushed a critical security patch, CodeDeploy gradually shifted traffic to the new version. Only 10% of users saw the update initially. CloudWatch metrics monitored 5XX errors—when none were detected after 10 minutes, CodeDeploy completed the deployment. If a 5XX spike occurred, it immediately rolled back to the previous version.”

• Tips:

• Highlight how you handled zero-downtime deployments for stateful microservices—e.g., using session affinity or migrating sessions to DynamoDB to prevent logouts.
• Mention how you validated ECS health checks (correct application port, path) before declaring green tasks healthy.

5. “Explain how you would set up a fully automated CI/CD pipeline for a serverless (Lambda) application using CodePipeline, CodeBuild, and CodeDeploy. What are the unique considerations?”
How to Answer:

• Source Stage:

• Repository: CodeCommit or GitHub. Include your Lambda function code plus an AWS SAM (Serverless Application Model) or CloudFormation template (e.g., template.yaml).

• Build Stage (CodeBuild):

• SAM Build & Package: In buildspec.yml

```
version: 0.2
phases:
  install:
    runtime-versions:
      python: 3.9
    commands:
      - pip install aws-sam-cli
  build:
    commands:
      - sam build --use-container
      - sam package --output-template-file packaged.yaml --s3-bucket my-sam-artifacts
artifacts:
  files:
    - packaged.yaml

```

• Artifacts: The packaged.yaml (CloudFormation with S3 references for Lambda code).

• Deploy Stage (CodeDeploy for Lambda):

• Create Application & Deployment Group:

• Choose compute platform = Lambda.
• Specify the Lambda function name, alias (e.g., prod), and traffic-shift configuration (Canary or Linear).

• Alias Management:

• SAM/CloudFormation template should already define a Lambda alias (e.g.,

```
MyFunction:
  Type: AWS::Serverless::Function
  Properties:
    Handler: app.lambda_handler
    Runtime: python3.9
    CodeUri: s3://my-sam-artifacts/abcdef.zip
    AutoPublishAlias: prod
    DeploymentPreference:
      Type: Canary10Percent5Minutes

```

• SAM’s DeploymentPreference in the template automatically configures CodeDeploy preferences.

• Unique Considerations for Lambda:

• Cold Starts: Monitor initialization latency, especially if switching from low‐traffic versions.
• Permissions:

• CodeBuild role needs permissions to run sam package (S3 PutObject, CloudFormation actions).
• CodeDeploy role needs lambda:UpdateFunctionCode, lambda:PublishVersion, lambda:UpdateAlias, and CloudWatch permissions for health monitoring.

• Alias & Versioning: Every deployment creates a new published version (e.g., 1, 2, 3). Traffic shifting via alias (e.g., prod) ensures seamless transition.

• Automated Testing Stage (Optional):

• Integration Tests: After packaged.yaml, spin up a temporary test stack (e.g., sam deploy --stack-name test-stack) and run end-to-end API Gateway tests in CodeBuild.
• Clean Up: Destroy test stack on success or failure to avoid resource sprawl.

• Example:

• “We built a Python-based REST API for customer onboarding. Developers pushed to dev branch → CodePipeline triggered → CodeBuild used sam build and sam package → Packaged template uploaded to S3 → CodePipeline invoked CodeDeploy via CloudFormation change set to publish a new Lambda version → Traffic shifted 50% immediately, then 100% after 15 minutes if no errors surfaced. For every push to main, we ran integration tests against a temporary stack before deploying to production.”

• Tips:

• Emphasize how you managed version drift between template.yaml and packaged.yaml.
• Mention how you monitored Lambda metrics (e.g., Invocation errors, duration) during Canary shifts.
• Discuss how you cleaned up old Lambda versions (e.g., via a scheduled Lambda or CodeBuild job) to avoid hitting the 1,000-version quota.

6. “What is a Blue/Green deployment, and how do you implement it for an EC2-based application without using CodeDeploy?”
How to Answer:

• Definition:

• A Blue/Green deployment maintains two identical environments: Blue (current production) and Green (new version). You switch traffic between them to minimize downtime and risk.

• EC2 Approach (Classic/ALB Load Balancer):

1.                      Blue Environment:

• Auto Scaling Group (ASG) “asg-blue” with EC2 instances running version 1.x.
• Associated with an ALB listener rule that forwards traffic to target group “tg-blue.”

2.                      Green Environment:

• ASG “asg-green” created with the new AMI or application version (version 2.x). Initially, set desired capacity to 0 or keep instances out of the ALB.

3.                      Route Traffic:

• After validating green instances (health checks OK), update the ALB listener: change target group from “tg-blue” to “tg-green.”
• Optionally use weighted routing in Route 53 (e.g., 10% traffic to green, wait, then 100% to green).

4.                      Decommission Blue (Optional):

• After monitoring, reduce “asg-blue” desired capacity to zero or delete the ASG.

• Validation Steps:

• Smoke Tests: Before switching, run a health check script or simple HTTP GET on new instances to confirm correct responses.
• Data Considerations:

• If using RDS, ensure database migrations are backward compatible (e.g., write to both Blue and Green).
• For stateful services, consider data sync (e.g., DynamoDB global tables or database replication).

• Rollback Approach:

• Instant Rollback: If errors appear after flipping traffic, roll back by reassigning the ALB listener to “tg-blue.”
• Database Rollback: More complex—either revert schema changes or use a feature-flag to disable new features.

• Real-World Example:

• “For a Java Spring Boot service on EC2, we baked a new AMI with Jenkins. We deployed the green ASG in the same subnets as the blue ASG but kept the Weight in Route 53 at 0%. We then ran automated health checks (via a custom CodeBuild job) against green instances. Once everything passed, we updated Route 53 to shift 100% traffic to green. After 30 minutes of error-free operation, we terminated blue instances. If anything broke, we would instantly revert Route 53 back to blue.”

• Tips:

• Highlight how you managed DNS TTL (e.g., 60 seconds) to minimize caching delays.
• Mention any automation (e.g., Terraform or CloudFormation templates) used to spin up blue and green ASGs identically.
• Emphasize data migration strategies (e.g., backward-compatible database migrations using Liquibase/Flyway).

7. “Explain what a Canary deployment is, and how you would set one up using CodeDeploy or a combination of CloudWatch Alarms and Lambda.”
How to Answer:

• Definition:

• A Canary deployment rolls out changes to a small subset of users first (e.g., 5%), monitors for errors, then gradually increases the percentage until 100%. Minimizes blast radius.

• CodeDeploy Canary Configuration:

• In ECS/Lambda: Use CodeDeploy’s built-in traffic shifting. Specify parameters:

• Canary10Percent5Minutes: Shift 10% of traffic initially, wait 5 minutes, then shift the remaining 90%.
• Canary10Percent10Minutes: Shift 10%, wait 10 minutes, etc.

• In EC2 (with Application Load Balancer):

• DeploymentGroup’s DeploymentConfigName: e.g., CodeDeployDefault.ECSCanary10Percent5Minutes or a custom one.
• CloudWatch Alarms: Configure alarms on metrics like HTTP 5XX or latency. If alarm triggers, CodeDeploy automatically rolls back.

• Manual Lambda + CloudWatch Approach (Without CodeDeploy):

1.                      Deploy New Version to a Separate Alias:

• Publish new Lambda version v2 and create alias canary pointing to v2.

2.                      Update API Gateway Stage with Canary Settings:

• In API Gateway, you can configure a Canary Deployment specifying StageVersion: $LATEST and PercentTraffic: 0.1.
• CloudWatch monitors the canary stage.

3.                      Lambda Function for Traffic Shift:

• Use a scheduled Lambda or Step Functions to increment the percentage (e.g., 10% → 20% → … → 100%).
• At each step, verify metrics by querying CloudWatch metrics (Errors, Throttles). If error threshold exceeded, rollback alias to point back to v1.

4.                      Health Checks & Alarms:

• Create CloudWatch Alarms on Errors or Duration for the canary alias. If alarm enters ALARM state, trigger an SNS topic that invokes a Lambda to revert the alias to primary.

• Key Considerations:

• Monitoring Metrics:

• Error rate (5XX), latency, custom application logs (e.g., business exceptions).

• Rollback Automation:

• Ensure alarms trigger a Lambda that calls UpdateAlias to direct 100% traffic back to stable version.

• Data Consistency:

• If new code writes to a different data schema, use feature flags or dual-writes to avoid data corruption during canary.

• Real-World Example:

• “We had a Go Lambda for processing payments. Using CodeDeploy’s Canary10Percent10Minutes, we deployed version 3 behind the prod alias. CloudWatch monitored Errors percent; if Errors > 1% for 5 minutes, CodeDeploy rolled back. Otherwise after 10 minutes, traffic shifted to 100%. This reduced incidents of accidental errors affecting all users—one canary release caught a dependency mismatch early.”

• Tips:

• Emphasize how CodeDeploy simplifies canary configuration versus building it manually.
• Note how you decided canary percentages (trade-off between risk and test coverage).
• Mention how you instrumented your application with custom CloudWatch metrics for more granular monitoring (e.g., business-specific error codes).

8. “What are the pros and cons of Blue/Green vs. Canary deployments? How do you decide which strategy to use?”
How to Answer:

• Blue/Green Deployment:

• Pros:

• Instant Rollback: Switch back to the blue environment immediately if issues arise.
• Easy Validation: You can perform full QA testing on green before going live.
• Minimal Impact on Users: Cutover is near-instant once green is validated.

• Cons:

• Double Infrastructure Costs: You must provision two complete environments (Blue and Green) simultaneously.
• Data Synchronization Complexity: For stateful services, ensuring the database schema or data is compatible across both can be tricky.

• Use When:

• The application can tolerate the extra cost during deployment windows.
• You need a full production-like environment to run manual QA or load tests before flipping traffic.

• Canary Deployment:

• Pros:

• Reduced Infrastructure Overhead: Only a small percentage of traffic goes to canary—no need to fully duplicate infrastructure.
• Continuous Verification: Monitor real-time metrics on a subset of users, catching issues before wider exposure.

• Cons:

• Longer Deployment Duration: Gradual rollouts can take minutes to hours (depending on step increments).
• Partial Exposure Risk: Some users may still get buggy code during the canary window.

• Use When:

• You want highly controlled, incremental rollouts and can afford a short period of mixed traffic.
• The service architecture (e.g., microservices, stateless APIs) easily supports routing a small percentage to new code.

• Decision Factors:

• Cost Constraints: If budget is tight, canary can reduce the need for full duplicate environments.
• Risk Tolerance: For mission-critical applications (e.g., financial transactions), Blue/Green may be safer because you can test 100% of traffic before cutover.
• Speed of Rollback: Blue/Green rollback is almost instantaneous, while canary might require re-routing traffic in increments.
• Testing Requirements: If you need to run full load tests on the production-like environment, Blue/Green is preferable.

• Real-World Tie-In:

• “When we migrated our monolithic PHP app to microservices, we initially used Blue/Green—spinning up an identical green cluster in ECS Fargate. But because the cost was prohibitive, we shifted to Canary deployments for day-to-day feature releases: 5% of traffic for 10 minutes, then 20% for 10 more, etc. For major platform upgrades (DB engine changes, schema migrations), we still use Blue/Green to fully validate before cutover.”

• Tips:

• Emphasize that you can combine strategies: e.g., use Blue/Green for infrastructure or database changes and Canary for minor code updates.
• Mention how you determined metrics thresholds for rolling forward vs. rolling back (e.g., < 0.5% error rate allowed during Canary).
• Note that for containerized workloads, services like AWS App Mesh or service mesh layers can assist in weighted routing.

9. “How do you minimize downtime during a deployment if your application has a stateful component, such as a relational database?”
How to Answer:

• Schema Migrations (Backward Compatibility):

• Additive Changes First: Always add new columns with default values or nullable constraints so old code still works.
• Two-Phase Migrations:

• Deploy migration that adds new columns or tables.
• Deploy new application version that writes to both old and new structures (dual writes).
• Once the new version is stable, deploy a migration that drops old columns.

• Blue/Green Database Strategies:

• Read Replica Promotion:

• Create a read replica of your primary RDS instance.
• Run schema migration on the replica.
• After verification, switch application to point to the replica (promote to primary).
• This often incurs a brief failover (typically < 60 seconds).

• Rolling Updates (for EC2-backed Databases):

• Multi-AZ RDS Deployments:

• RDS automatically fails over to a standby when the primary is taken offline for maintenance or schema changes.

• Manual Multi-Instance Approach:

• Spin up a new DB instance with updated schema.
• Use AWS DMS (Database Migration Service) to sync data in near-real time.
• Cut over application traffic once data lag is minimal.

• Session Management & Caching:

• Externalize Sessions: Store sessions in Redis/Memcached or DynamoDB so that new application instances can pick up user sessions seamlessly.
• Feature Flags: Gate new code paths (e.g., new database queries) behind feature flags to allow instant rollback without code redeploy.

• Application-Level Graceful Shutdown:

• Register SIGTERM hooks on application containers/EC2 instances to wait for in-flight requests to finish (draining connections) before pulling the instance out of the load balancer.

• Real-World Example:

• “We maintained a PostgreSQL RDS in Multi-AZ. For a large schema refactor—adding and removing columns—we:

• Added new columns with default values in a read replica.
• Pointed application’s CI/CD Canary release (5% traffic) at the updated replica for validation.
• Promoted the replica to primary (auto-failover took ~30 seconds).
• Monitored client errors; none surfaced.
• Completed the migration by dropping old columns in a subsequent maintenance window.”

• Tips:

• Emphasize the importance of robust testing (e.g., running DB migrations on staging with a production-sized dataset).
• Mention how you monitored replication lag (e.g., ReplicaLag CloudWatch metric) to know when it was safe to promote.
• Highlight how you maintained backward compatibility in code and queries.

10. “Your CodePipeline deployment fails halfway through—how do you diagnose and remediate the issue?”
How to Answer:

• Check Pipeline Execution History:

• In the CodePipeline Console, select the failed pipeline execution and examine which stage/action failed (e.g., CodeBuild, CodeDeploy).

• Inspect Logs:

• CodeBuild Build Logs:

• Navigate to the CodeBuild project → “Build history” → Click the failed build → “View logs.”
• Look for compilation errors, test failures, or missing environment variables.

• CodeDeploy Deployment Logs:

• Go to CodeDeploy → Applications → Deployment Groups → Select the failed deployment → Review “View events.”
• SSH onto a failing EC2 instance (if EC2/On-Premises) and check /opt/codedeploy-agent/deployment-root/deployment-logs or scripts/*.log.

• Review IAM Permissions:

• Ensure the CodePipeline service role has permissions for all actions in the pipeline (S3 GetObject, CodeBuild StartBuild, CodeDeploy CreateDeployment).
• Confirm CodeBuild and CodeDeploy roles have permissions to access artifacts, update resources, and access secrets (SSM/Secrets Manager).

• Validate Artifacts & Environment Variables:

• Make sure the build artifact (e.g., ZIP or Docker image) is present in the expected S3 bucket or ECR repository.
• Double-check that required environment variables (database credentials, API endpoints) are correctly defined in build/deploy stages.

• Networking & Security Constraints:

• If CodeBuild cannot reach external resources (e.g., a private NPM registry), verify that the build project is in the correct VPC/subnets with NAT Gateway access.
• If CodeDeploy cannot connect to EC2 instances, ensure the instances have the CodeDeploy agent installed and running, and that Security Groups allow inbound communication on port 22 (for agent) and any custom ports.

• Drill Into Specific Error Messages:

• For build errors, “npm install” failures often indicate missing package.json or locked dependencies.
• For deployment hook failures, check that your appspec.yml paths and hook scripts exist and have execute permissions (chmod +x).

• Rollback or Retry:

• If the pipeline partially deployed resources (e.g., a database migration), assess whether you can manually rollback using database backups or CloudFormation stack rollback.
• For CodeDeploy, if half of your instances are on new code and half on old, use the CodeDeploy Console to initiate a rollback or repair: “Redeploy to the previous revision.”
• Fix the root cause, commit the change, and push to trigger a new pipeline execution.

• Real-World Example:

• “Our deployment broke at the BeforeInstall hook: the script tried to stop a Tomcat service that wasn’t installed on our latest AMI. I SSH’d onto the CodeDeploy agent logs, found the script path mismatch, updated appspec.yml to point to the correct script, and re-ran the pipeline. To prevent recurrence, we added a unit test in CodeBuild that validates file paths referenced by appspec.yml before deploying.”

• Tips:

• Emphasize the importance of automated tests catching syntax errors or missing files before CodeDeploy runs.
• Mention how you configured SNS or ChatOps notifications on pipeline failures so the team was alerted immediately.
• Highlight how you implemented pipeline “gates” (e.g., manual approval) for critical environments to allow a final human check before deploy.

General Tips for Interviewing on Deployment & CI/CD

• Understand the End-to‐End Flow:

• Show you know how source code changes move through each stage: build, test, package, deploy, and verification.

• Tie Answers to Real Impact:

• Quantify how CI/CD automation reduced deployment times (e.g., “from 30 minutes manual to 5 minutes automated”) or reduced rollback incidence (e.g., “zero-downtime deployments saved us from one major user outage per month”).

• Focus on Security & Permissions:

• Discuss how you applied the principle of least privilege to pipeline roles—e.g., CodePipeline role can only trigger CodeBuild and CodeDeploy, but not modify unrelated services.

• Emphasize Observability:

• Describe how you instrumented pipelines with CloudWatch Alarms, Build logs, and custom metrics so you could catch issues early.

• Show Flexibility with Deployment Strategies:

• Mention how you chose Blue/Green vs. Canary based on cost, risk profile, and SLA requirements.

• Be Prepared for Variations:

• Interviewers may ask about alternative tools (e.g., Jenkins, GitLab CI, CircleCI). Be ready to explain why you’d use AWS native services (tight integration, security, managed scaling) versus third-party CI/CD solutions.

By mastering these ten questions—and focusing on how you’ve architected, automated, and maintained CI/CD pipelines—you’ll demonstrate to interviewers that you can deliver code quickly, reliably, and securely on AWS. Good luck!