AWS DevOps Professional Certification

Explanation:

For cross-account deployments in CodePipeline, the CodePipeline service role in the tools account must have sts:AssumeRole permission for the cross-account role in the target account. Additionally, the cross-account role must have a trust policy allowing the tools account. However, the question states the cross-account role "exists," implying it's configured correctly, so the most likely issue is the CodePipeline service role permissions. The S3 bucket must be accessible cross-account (via bucket policy), but the error message specifically indicates an assume role issue.

Explanation:

cache:
  paths:
    - '/root/.m2/**/*'

Explanation:

When Auto Scaling launches new instances during a CodeDeploy deployment, those instances might receive the old AMI version. To ensure new instances get the current deployment, configure an Auto Scaling lifecycle hook that triggers a CodeDeploy deployment to newly launched instances. This ensures consistency across all instances in the deployment group. Option D would work but creates operational complexity and potential availability issues. Option C changes the deployment model entirely. Option B (immutable) is a Beanstalk concept, not CodeDeploy.

Explanation:

CodeBuild is ideal for running integration tests within a pipeline. The default timeout is 60 minutes (configurable up to 8 hours), which accommodates the 15-minute test. Using a custom Docker image with pre-installed test frameworks optimizes build time. Option A is partially correct but doesn't mention the custom image optimization. Option B would complete before tests finish. Option C introduces manual intervention unnecessarily.

Explanation:

CodeDeploy's Canary10Percent10Minutes deployment configuration shifts exactly 10% of traffic to the new version, waits 10 minutes (allowing monitoring and potential rollback), then shifts the remaining 90%. This matches the requirement exactly. Linear10PercentEvery1Minute would incrementally shift 10% every minute, completing in 10 minutes total. Option C requires manual configuration. Option D is manual and doesn't automate the full shift.

Explanation:

AWS Secrets Manager is designed for storing and automatically rotating credentials. It provides native integration with RDS, Redshift, and DocumentDB for automatic rotation, and supports custom rotation Lambda functions for other credential types. CodeBuild can reference Secrets Manager secrets in the buildspec using secrets-manager environment variable references. Parameter Store (option B) can store secrets but doesn't have built-in rotation; you'd need to implement custom rotation. Option A doesn't support rotation. Option D is operationally complex.

Explanation:

{
  "source": ["aws.codecommit"],
  "detail-type": ["CodeCommit Repository State Change"],
  "detail": {
    "referenceType": ["branch"],
    "referenceName": ["main"]
  }
}

Explanation:

Creating a custom Docker image with pre-installed tools is the most efficient approach. The custom image can be stored in Amazon ECR and referenced in the CodeBuild project configuration. This eliminates installation time completely for each build. Option A with caching might help but still requires initial installation in each new build environment. Option C (EC2 build fleet) introduces unnecessary complexity. Option D still requires extraction/installation time.

Explanation:

{
  "source": ["aws.codedeploy"],
  "detail-type": ["CodeDeploy Deployment State-change Notification"],
  "detail": {
    "state": ["FAILURE"]
  }
}

Explanation:

• Two target groups (blue and green)
• CodeDeploy shifts traffic between target groups
• CloudWatch alarms can trigger automatic rollback if error thresholds are exceeded
• Configurable traffic shifting (all-at-once, canary, linear)

The rollback configuration in CodeDeploy can specify alarms that, when triggered, automatically roll back the deployment by shifting traffic back to the original target group.

Explanation:

aws codeartifact login --tool npm --repository my-repo --domain my-domain --domain-owner 111122223333

Explanation:

• SNS topic for notification (emails the security team)
• Custom approval message with deployment details
• Optional URL to review changes
• Comments field for approval documentation

• Who approved/rejected (IAM identity)
• When the action was taken
• Comments provided

This information is available in CloudTrail and pipeline history for audit purposes. Option B could work but adds complexity. Options C and D don't provide the workflow CodePipeline approval actions offer.

Explanation:

reports:
  coverage-report:
    files:
      - 'coverage/clover.xml'
    file-format: CLOVERXML  # or COBERTURAXML, JACOCOXML, etc.

Explanation:

For monorepo patterns with selective builds:

1. Receive CodeCommit events
2. Use Git APIs to determine changed files
3. Start only the relevant pipelines using start-pipeline-execution

This is a common pattern because CodePipeline doesn't natively support path-based filtering. The Lambda approach offers more flexibility for complex monorepo structures.

AWS has also introduced pipeline triggers with filtering capabilities in CodePipeline, which can filter based on file paths in newer versions.

Explanation:

• Application Load Balancer with two target groups
• ECS service configured for CodeDeploy deployment controller
• appspec.yml defining the task definition and container details
• CodePipeline action type: Deploy > Amazon ECS (Blue/Green)

• Creating replacement task set
• Traffic shifting (all-at-once, canary, linear)
• Health checks and CloudWatch alarm monitoring
• Automatic rollback on failures

The standard ECS deployment action (option A) only supports rolling updates, not blue/green.

Explanation:

artifacts:
  files:
    - 'app/**/*'
    - 'config/*.json'
  exclude-paths:
    - 'node_modules/**/*'
    - 'test/**/*'
  base-directory: dist

• Excluding test files, documentation, source maps
• Compressing artifacts
• Using artifact caching instead of passing large unchanged files

Option B adds cost and minimal benefit for inter-service transfers. Option A is for packages, not build artifacts.

Explanation:

For on-premises servers with CodeDeploy:

1. CodeDeploy Agent must be installed and running on each server
2. IAM User credentials (access key/secret key) must be configured because on-premises servers cannot use IAM instance profiles (those are EC2-only)

• Access S3 buckets containing deployment artifacts
• Communicate with CodeDeploy service

Configuration file location: /etc/codedeploy-agent/conf/codedeploy.onpremises.yml contains the IAM credentials and region.

Option B is incorrect because instance profiles are EC2-specific. Option D (SSM) is not required for CodeDeploy (though it can complement it).

Explanation:

• OWASP Dependency-Check
• Snyk
• npm audit / pip-audit
• Trivy for container images

phases:
  build:
    commands:
      - npm audit --audit-level=critical
      - snyk test --severity-threshold=critical

Pipeline stops if CodeBuild reports failure. Option D (CodeGuru Security) is newer and can be integrated but the question implies more general vulnerability scanning.

Explanation:

• New version deployed to a fresh set of instances
• Configurable percentage of traffic routed to new version
• Evaluation period for monitoring
• Automatic rollback if health checks fail
• Quick rollback by terminating new instances

This matches the requirements of running both versions simultaneously for comparison. Option C (blue/green with CNAME swap) also works but doesn't allow percentage-based traffic splitting. Option B (immutable) replaces instances but doesn't maintain both versions simultaneously after deployment completes.

Explanation:

• Creates an artifact bucket in the target region (or uses one you specify)
• Replicates necessary artifacts to the target region's bucket
• Handles encryption key management across regions

• Specifying the region for each action
• Ensuring IAM roles have cross-region permissions
• KMS keys in each region if using customer-managed keys

This is configured in the pipeline structure by setting the region property on actions that need to run in different regions.

Explanation:

CodePipeline doesn't have a native "wait" action. Options include:

1. Pipeline pauses at approval action
2. Scheduled event triggers Lambda after wait period
3. Lambda approves the pending action via API

Option B with manual approvals works but requires human intervention. There's no "wait action" in CodePipeline (option A), and CodeDeploy configurations don't control inter-stage timing (option D).

Explanation:

CodeCommit provides:

1. Approval Rule Templates: Define rules requiring specific numbers of approvals and optionally specific approvers (by IAM ARN or wildcard patterns)

1. Branch-level Permissions: IAM policies can restrict push access to specific branches:

{
  "Effect": "Deny",
  "Action": ["codecommit:GitPush"],
  "Resource": "arn:aws:codecommit:*:*:repo-name",
  "Condition": {
    "StringEqualsIfExists": {
      "codecommit:References": ["refs/heads/main"]
    }
  }
}

The combination ensures only merged pull requests (after approval) update the main branch. Option D doesn't work because local hooks can be bypassed.

Explanation:

• Specify VPC ID
• Specify private subnet IDs (CodeBuild runs in these subnets)
• Specify security group IDs

• CodeBuild can access VPC resources (RDS, ElastiCache, etc.)
• For internet access (downloading dependencies), you need NAT Gateway or VPC endpoints
• Consider using S3 and CodeArtifact VPC endpoints for build dependencies

Security group must allow outbound traffic to RDS and RDS security group must allow inbound from CodeBuild security group.

Explanation:

For ECS blue/green deployments, CodeDeploy supports Lambda-based hooks:

• BeforeInstall: Runs before replacement task set is created
• AfterInstall: Runs after replacement task set is created but before traffic shifts
• AfterAllowTraffic: Runs after traffic has shifted to replacement

• New task set is running and accessible via test target group
• Production traffic still goes to original task set
• Lambda function can run synthetic tests against test endpoint
• If tests fail, Lambda returns failure and deployment rolls back

Hooks:
  - BeforeAllowTraffic: "ValidateDeploymentLambda"

Explanation:

AWS CodeStar Connections (which replaced GitHub OAuth tokens for CodePipeline) supports trigger configuration with filters:

• Push triggers: Trigger on push to specified branches
• Pull request triggers: Trigger on PR events (opened, updated, merged)
• Tag triggers: Trigger on tag creation

• Pipeline trigger type: Push
• Branch filter: main
• This triggers only when commits land on main (which happens after PR merge)

Alternatively, use EventBridge with GitHub events and filter for merged PR events, then trigger the pipeline.

Explanation:

AWS AppConfig (part of Systems Manager) provides feature flag functionality:

• Feature Flag configuration profile type specifically designed for feature flags
• Supports gradual rollout percentages
• Built-in validation before deployment
• Integration with CloudWatch for monitoring
• Rollback capabilities
• SDK caching for performance

• Creating a feature flag configuration profile
• Defining flags with enabled/disabled states
• Configuring deployment strategy (percentage-based rollout)
• Application polls AppConfig or uses cached configuration

AppConfig is preferred over Parameter Store for feature flags because it provides deployment strategies, validation, and rollback capabilities specifically designed for configuration changes.

Explanation:

CodeBuild supports two capacity types:

1. On-demand (default): Build environments provisioned on-demand; may have slight delays during peak usage

1. Reserved capacity (Fleets): Pre-provisioned build instances that are always available:

• Eliminate cold start delays
• Faster build starts
• Cost-effective for consistent build workloads
• Instances remain available between builds

• Compute type
• Number of instances
• Environment type

For consistent, immediate build starts, reserved capacity fleets are recommended for teams with frequent builds.

Explanation:

For multi-account deployments at scale:

• Stage 1: Source
• Stage 2: Build
• Stage 3: Deploy to Dev + QA (parallel actions, same tier)
• Stage 4: Manual Approval
• Stage 5: Deploy to Staging + UAT (parallel)
• Stage 6: Approval
• Stage 7: Deploy to Prod

This reduces stages while maintaining logical separation.

• CodePipeline triggers Step Functions
• Step Functions manages parallel deployments across accounts
• More flexibility for conditional logic, retries, error handling

For the exam, option D is the more "AWS-native" approach using CodePipeline's parallel actions feature.

Explanation:

• Launches a temporary Auto Scaling group with new version
• Full capacity maintained throughout deployment
• New instances pass health checks before traffic shifts
• Original instances only terminated after new ones are healthy
• If deployment fails, only temporary instances are terminated

1. Original healthy instances continue serving traffic
2. New instances are validated before receiving traffic
3. Traffic only shifts to new instances after health checks pass

Explanation:

CodeDeploy Lambda deployments provide:

1. Alias traffic shifting: Configure in deployment configuration (Canary, Linear, AllAtOnce)

1. Validation hooks: appspec.yml with BeforeAllowTraffic and AfterAllowTraffic hooks

version: 0.0
Resources:
  - MyFunction:
      Type: AWS::Lambda::Function
      Properties:
        Name: "my-function"
        Alias: "prod"
        CurrentVersion: "1"
        TargetVersion: "2"
Hooks:
  - AfterAllowTraffic: "ValidationFunction"

1. Automatic rollback: If validation function returns failure, CodeDeploy automatically shifts traffic back to previous version

The validation Lambda function receives deployment ID and lifecycle hook information, runs tests, and calls put-lifecycle-event-hook-execution-status with Succeeded or Failed.

Explanation:

Tag-based access control in IAM:

1. Tag resources: Each team's pipelines tagged with Team: team-name

1. IAM policy with conditions:

{
  "Effect": "Allow",
  "Action": ["codepipeline:*"],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:ResourceTag/Team": "${aws:PrincipalTag/Team}"
    }
  }
}

1. Tag IAM principals: Users/roles tagged with their team identifier

This scales better than creating resource-specific policies (option C) and doesn't require separate accounts (option A). SCPs (option D) don't provide granular resource-level control.

Explanation:

ECR requires authentication before pushing images. The buildspec must include the ECR login command:

phases:
  pre_build:
    commands:
      - aws ecr get-login-password --region $AWS_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com
  build:
    commands:
      - docker build -t $IMAGE_REPO_NAME:$IMAGE_TAG .
      - docker tag $IMAGE_REPO_NAME:$IMAGE_TAG $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/$IMAGE_REPO_NAME:$IMAGE_TAG
  post_build:
    commands:
      - docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/$IMAGE_REPO_NAME:$IMAGE_TAG

Option B (IAM permissions) would cause a different error message. The "no basic auth credentials" specifically indicates missing login.

Explanation:

Service Control Policies (SCPs) in AWS Organizations can enforce CodeBuild configuration:

{
  "Effect": "Deny",
  "Action": ["codebuild:CreateProject", "codebuild:UpdateProject"],
  "Resource": "*",
  "Condition": {
    "Null": {
      "codebuild:VpcConfig": "true"
    }
  }
}

This prevents creating or updating CodeBuild projects without VPC configuration. For monitoring existing projects, AWS Config rules (option B) complement this by detecting non-compliant resources.

Note: The exact condition key syntax may vary; verify current documentation for precise implementation.

Explanation:

CodePipeline S3 source actions can use:

1. Polling (periodic check): Default behavior, checks every few minutes
2. Event-based (CloudWatch Events): Near real-time triggering

1. Enable "CloudWatch Events" option on the S3 source action
2. CodePipeline automatically creates the necessary CloudWatch Events rule and S3 bucket notification

This configuration detects S3 object creation events and triggers the pipeline within seconds of the upload, compared to polling's multi-minute delay.

Note: S3 bucket must have versioning enabled for change detection with event-based triggers.

Explanation:

CodeDeploy agent logs on EC2 instances contain detailed deployment information:

• Linux: /var/log/aws/codedeploy-agent/codedeploy-agent.log
• Windows: C:\ProgramData\Amazon\CodeDeploy\log\codedeploy-agent.log

• /opt/codedeploy-agent/deployment-root/{deployment-group-id}/{deployment-id}/logs/scripts.log - lifecycle hook script output

• File download status
• Lifecycle hook execution
• Script output and errors
• Deployment timing

The CodeDeploy console (option B) provides high-level status but not detailed instance-level debugging information.

Explanation:

For microservices deployment coordination:

• Coordinate multiple pipeline executions
• Handle dependencies between services
• Implement retry logic and error handling
• Support parallel and sequential deployments
• Maintain state across long-running deployments

Pipeline A completes → EventBridge rule → Triggers Pipeline B

1. Deploy core services (parallel)
2. Wait for all core services to complete
3. Deploy dependent services (parallel)
4. Run integration tests
5. Deploy API gateway service

Option D loses independent service deployments. Option A is limited in flexibility.

Explanation:

For EKS deployments from CodePipeline:

1. CodeBuild project configured with VPC access to EKS cluster
2. Build environment includes kubectl
3. Authentication using IAM role mapped to Kubernetes RBAC

phases:
  install:
    commands:
      - curl -LO "https://dl.k8s.io/release/stable.txt"
      - curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
      - chmod +x kubectl && mv kubectl /usr/local/bin/
  build:
    commands:
      - aws eks update-kubeconfig --name my-cluster --region $AWS_REGION
      - kubectl apply -f kubernetes/

Note: CodeDeploy (option B) doesn't natively support EKS. CloudFormation (option C) can work but is more complex. AWS also offers Controllers for Kubernetes (ACK) for IaC approaches.

Explanation:

CodeCommit's approval rule templates don't support path-based conditions natively. For path-specific approval requirements:

1. Configure CodeCommit trigger for pull request events
2. Lambda function:

• Analyzes changed files in the PR
• If /security/ files are changed, updates required approvals
• Enforces approval from security team members (by IAM ARN)
• Blocks merge until requirements met

• Use CodeCommit APIs to get PR details and file changes
• Create/update approval rules dynamically
• Comment on PR with requirements

This is more complex but necessary for path-based requirements. Standard approval rule templates only support repository-level and branch-level rules.

Explanation:

When accessing S3 objects encrypted with customer-managed KMS keys, the accessing principal needs:

1. S3 permissions (already configured per question)
2. KMS permissions to decrypt the data key

{
  "Effect": "Allow",
  "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
  "Resource": "arn:aws:kms:region:account:key/key-id"
}

• IAM policy on the CodeBuild service role (Option A)
• KMS key policy (Option C - also works but typically both are configured)

For downloads, kms:Decrypt is essential. The error message indicates the service role's IAM policy is missing KMS permissions.

Explanation:

CodeStar Connections integrates with GitHub and respects GitHub's authentication and authorization. However, CodePipeline source actions trigger on commits, not on GitHub's internal status.

phases:
  pre_build:
    commands:
      - |
        # Check if commit was from a merged PR that passed branch protection
        COMMIT_SHA="${CODEBUILD_RESOLVED_SOURCE_VERSION}"
        PR_STATUS=$(curl -s -H "Authorization: token $GITHUB_TOKEN" \
          "https://api.github.com/repos/owner/repo/commits/$COMMIT_SHA/status")
        if [[ $(echo $PR_STATUS | jq -r '.state') != "success" ]]; then
          echo "Commit did not pass required checks"
          exit 1
        fi

This explicitly validates the commit's status before proceeding. GitHub's branch protection prevents merging without passing checks, but this adds defense-in-depth in the pipeline.

Explanation:

CodePipeline supports cross-region actions within the same stage. Configure:

Stage: Deploy
├── Action: Deploy-us-east-1 (region: us-east-1)
└── Action: Deploy-eu-west-1 (region: eu-west-1)

Both actions run in parallel. The stage only completes successfully if ALL actions succeed. If either region's deployment fails, the stage fails and the pipeline stops.

• Artifact buckets in each region
• IAM roles with cross-region permissions
• KMS keys in each region (if using encryption)

This is the native CodePipeline approach for multi-region parallel deployments with coordinated success/failure.

Explanation:

To prevent developers from modifying build commands:

• Build specification: "Insert build commands"
• Enter commands directly in the project configuration

Developers with only source repository access cannot modify the build process. Only users with CodeBuild project modification permissions can change the buildspec.

Explanation:

The lifecycle hook script should implement retry logic:

#!/bin/bash
MAX_RETRIES=5
RETRY_INTERVAL=10

for i in $(seq 1 $MAX_RETRIES); do
  if check_service_available; then
    echo "Service is available"
    exit 0
  fi
  echo "Attempt $i: Service unavailable, waiting ${RETRY_INTERVAL}s..."
  sleep $RETRY_INTERVAL
  RETRY_INTERVAL=$((RETRY_INTERVAL * 2))  # Exponential backoff
done

echo "Service unavailable after $MAX_RETRIES attempts"
exit 1

hooks:
  BeforeInstall:
    - location: scripts/check_service.sh
      timeout: 300  # 5 minutes

CodeDeploy doesn't have built-in hook retry (option C). The script must handle retries internally.

Explanation:

The described requirement doesn't match standard AWS deployment configurations:

• Canary10Percent5Minutes: 10% initially, wait 5 minutes, then 100% (not gradual)
• Linear10PercentEvery2Minutes: Shifts 10% every 2 minutes from the start (no initial wait)

For custom behavior, create a custom deployment configuration:

aws deploy create-deployment-config \
  --deployment-config-name Custom-Canary-Then-Linear \
  --compute-platform Lambda \
  --traffic-routing-config '{
    "type": "TimeBasedLinear",
    "timeBasedLinear": {
      "linearPercentage": 10,
      "linearInterval": 2
    }
  }'

However, the exact requirement (initial canary with wait, then linear) may require combining approaches or accepting the closest standard configuration. The exam may present this as "Custom deployment configuration."

Explanation:

CodePipeline's CodeCommit source action supports two clone modes:

1. Full clone: Includes complete Git history and metadata

• Source action outputs Git repository with full history
• Useful for build processes that need: git log, git describe, branch information

1. Default (zip download): Only current commit files

• Faster for simple builds
• No Git metadata

git describe --tags
git log --oneline -10
git branch -a

Explanation:

Both options work for standardization:

• Create a portfolio with pipeline product
• Product defined using CloudFormation template
• Share portfolio across accounts
• Users launch standardized pipelines with customizable parameters
• Governance through constraints and launch roles
• Version management for pipeline templates

• Deploy identical pipelines across multiple accounts
• Central management of pipeline infrastructure
• Automatic deployment to new accounts via OU targeting

• Self-service pipeline creation by teams
• Parameterized customization within guardrails
• Approval workflows for provisioning

• Identical infrastructure across accounts
• Central IT-managed deployments
• Compliance enforcement

Explanation:

import datetime

def lambda_handler(event, context):
    now = datetime.datetime.utcnow()
    
    # Check if Saturday between 2AM and 6AM UTC
    if now.weekday() == 5 and 2 <= now.hour < 6:
        # Return success to CodePipeline
        codepipeline.put_job_success_result(jobId=event['CodePipeline.job']['id'])
    else:
        # Return failure - blocks deployment
        codepipeline.put_job_failure_result(
            jobId=event['CodePipeline.job']['id'],
            failureDetails={
                'message': 'Deployments only allowed Saturday 2AM-6AM UTC',
                'type': 'JobFailed'
            }
        )

The Lambda approach provides the most flexibility and clear enforcement.

Explanation:

• Git as single source of truth
• Declarative infrastructure/application definitions
• Automated agents that sync actual state to desired state
• Pull-based deployment model

• Continuously monitors Git repository
• Automatically syncs Kubernetes cluster state to match repository
• Reconciliation loop maintains desired state
• True GitOps implementation

• CodePipeline (Option A): Push-based CI/CD, not pure GitOps but common
• App Runner (Option B): Auto-deploys on repository changes (for containers)
• Proton (Option C): Templates for infrastructure/applications

For exam purposes, understand that GitOps is a methodology. AWS provides building blocks, but tools like ArgoCD/Flux provide pure GitOps implementation on EKS.

Explanation:

CodePipeline provides the ability to retry failed stages:

1. Navigate to the failed pipeline execution
2. Click "Retry" on the failed stage
3. Pipeline resumes from that stage using existing artifacts

aws codepipeline retry-stage-execution \
  --pipeline-name MyPipeline \
  --stage-name Deploy \
  --pipeline-execution-id abc123 \
  --retry-mode FAILED_ACTIONS

This uses artifacts from the original execution, avoiding the need to rebuild. Note that retry is only available for the most recent execution of a stage and must be initiated before a new pipeline execution processes that stage.

Explanation:

CodeArtifact with external connections:

1. External connection: Links CodeArtifact repository to public registries (npm, PyPI, Maven Central)

1. Automatic caching: When a package is requested:

• If cached in CodeArtifact → served immediately
• If not cached → fetched from upstream, cached, then served
• Subsequent requests served from cache

aws codeartifact associate-external-connection \
  --domain my-domain \
  --repository my-repo \
  --external-connection public:npmjs

• Faster installs (closer/faster than public internet)
• Availability if upstream is down
• Security scanning of cached packages

Explanation:

In CodeDeploy blue/green deployments, the terminateBlueInstancesOnDeploymentSuccess setting controls what happens to original instances:

1. Terminate after wait period: Keeps blue instances for specified duration
2. Terminate immediately: Removes blue instances right after traffic shift
3. Keep alive: Never automatically terminates blue instances

{
  "blueGreenDeploymentConfiguration": {
    "terminateBlueInstancesOnDeploymentSuccess": {
      "action": "TERMINATE",
      "terminationWaitTimeInMinutes": 1440  // 24 hours
    }
  }
}

During this window, rollback to blue instances is near-instant (traffic shift). After the window, blue instances are terminated.

Explanation:

When lifecycle hook scripts fail:

1. Non-zero exit code = hook failure = instance deployment failure
2. Scripts must explicitly exit with status 0 for success

1. Check the script on a failed instance:

1. Common issues:

• Script doesn't have execute permissions
• Script has syntax errors
• Dependencies not installed
• Script doesn't handle errors properly
• Missing shebang (#!/bin/bash)

1. CodeDeploy agent log:

The deployment group configuration and IAM roles are less likely to cause AfterInstall script failures (those would cause earlier failures).

Explanation:

CodeDeploy supports CloudWatch alarms as automatic rollback triggers:

1. Create CloudWatch alarm:

• Metric: CPUUtilization
• Threshold: 80%
• Period and evaluation settings appropriate for post-deployment monitoring

1. Configure deployment group:

{
  "autoRollbackConfiguration": {
    "enabled": true,
    "events": ["DEPLOYMENT_STOP_ON_ALARM"]
  },
  "alarmConfiguration": {
    "alarms": [
      {"name": "HighCPU-Alarm"}
    ],
    "enabled": true
  }
}

If the alarm enters ALARM state during or shortly after deployment, CodeDeploy automatically rolls back.

Explanation:

CodeDeploy deployment groups can target multiple Auto Scaling groups:

• All ASGs should receive the same deployment
• You want unified deployment management
• You need consistent deployment configuration across ASGs

• AllAtOnce for fastest deployment (higher risk)
• Custom configuration specifying percentage or fixed number

• Batch sizes appropriate for risk tolerance
• Monitoring during deployment
• Rollback triggers configured

Explanation:

If deployment succeeded but application isn't working:

• Hook might not be implemented (no validation)
• Hook validation might be insufficient
• Hook might not exit with failure on actual problems

#!/bin/bash
# Check if application is responding
RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" http://localhost:8080/health)
if [ "$RESPONSE" != "200" ]; then
  echo "Health check failed"
  exit 1
fi
echo "Application healthy"
exit 0

If no ValidateService hook exists, the deployment succeeds based on file deployment and earlier hooks, not actual application functionality.

• ApplicationStart hook - verify it actually started the application
• Application logs for startup errors

Explanation:

CodeDeploy doesn't automatically monitor CloudWatch metrics for rollback. You must explicitly configure:

1. CloudWatch alarms that trigger on error conditions:

{
  "alarmConfiguration": {
    "enabled": true,
    "alarms": [{"name": "Lambda-Error-Rate-Alarm"}]
  }
}

1. Automatic rollback on alarm:

{
  "autoRollbackConfiguration": {
    "enabled": true,
    "events": ["DEPLOYMENT_STOP_ON_ALARM"]
  }
}

Without this configuration, the deployment continues regardless of errors. The canary period gives you TIME to monitor, but doesn't provide automatic metric-based rollback unless configured.

This is a common exam topic: CodeDeploy alarm-based rollback requires explicit configuration.

Explanation:

For on-premises instance registration with CodeDeploy:

1. Prerequisite: Create an IAM user for the on-premises instance

• Generate access keys
• Attach policy with CodeDeploy permissions

1. Registration (Option C or A):

# Using CLI/API (can be scripted in config management)
aws deploy register-on-premises-instance \
  --instance-name server-001 \
  --iam-user-arn arn:aws:iam::account:user/codedeploy-user

# Configure instance with credentials
aws deploy install \
  --config-file /etc/codedeploy-agent/conf/codedeploy.onpremises.yml

1. Add to deployment group:

aws deploy add-tags-to-on-premises-instances \
  --instance-names server-001 \
  --tags Key=Environment,Value=Production

Configuration management tools (Ansible, Puppet, Chef) can execute these commands during server provisioning.

Explanation:

In ECS blue/green deployments:

1. New task set created with new task definition
2. Traffic gradually shifted to new task set
3. After successful traffic shift, old task set waits for termination
4. After termination wait time, old tasks are terminated

{
  "blueGreenDeploymentConfiguration": {
    "terminationWaitTimeInMinutes": 60
  }
}

• Old tasks remain running (for potential rollback)
• New tasks serve production traffic
• Both task sets exist simultaneously

After wait time expires, old task set is terminated. This is expected behavior, not an error.

Explanation:

"The specified key does not exist" error indicates S3 access issues:

1. Bundle exists in S3:

• Verify the artifact key path is correct
• Check if the revision was successfully uploaded
• Verify the S3 bucket and key in deployment configuration

1. IAM permissions:

• EC2 instance role needs s3:GetObject on the artifact
• If cross-account, both bucket policy and IAM role needed
• If KMS encrypted, need kms:Decrypt

1. Network access:

• Instance can reach S3 (internet gateway, NAT, or VPC endpoint)
• Security groups allow outbound HTTPS
• NACLs allow S3 traffic

1. S3 bucket configuration:

• Bucket policy doesn't explicitly deny
• Bucket isn't in a different region without proper configuration

The error message typically means the object truly doesn't exist at that key, but access issues can produce similar errors.

Explanation:

AWS provides codedeploy-local CLI for local testing:

gem install aws-codedeploy-agent

codedeploy-local \
  --bundle-location /path/to/application \
  --type directory \
  --deployment-group myDeploymentGroup

• Tests appspec.yml syntax
• Executes lifecycle hooks locally
• Validates deployment bundle structure
• Debugging without AWS deployment costs/time

• Simulates deployment process
• Not all features available locally
• Network-dependent features may not work

This is useful for rapid iteration on appspec.yml and deployment scripts before actual AWS deployments.

Explanation:

• Deploys to 50% of instances at a time
• Maintains 50% healthy capacity throughout
• Built-in AWS deployment configuration

aws deploy create-deployment-config \
  --deployment-config-name Fast50Percent \
  --minimum-healthy-hosts type=FLEET_PERCENT,value=50

This allows customization while maintaining 50% capacity.

• HalfAtATime: Exactly 50% deploys at once
• Custom: Can specify different parallelism while maintaining 50% minimum healthy

For fastest deployment with 50% capacity, HalfAtATime deploys half the fleet simultaneously, which is the maximum parallelism possible while maintaining 50% healthy hosts.

Explanation:

When deregistering instances from load balancers:

• ALB/NLB settings specify how long to wait for in-flight requests
• Default: 300 seconds
• If too short, existing requests are dropped

1. Deregister from target group
2. Wait for connection draining to complete
3. Then proceed with deployment

#!/bin/bash
INSTANCE_ID=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)

# Deregister from target group
aws elbv2 deregister-targets \
  --target-group-arn $TARGET_GROUP_ARN \
  --targets Id=$INSTANCE_ID

# Wait for draining (check deregistration state)
while true; do
  STATE=$(aws elbv2 describe-target-health \
    --target-group-arn $TARGET_GROUP_ARN \
    --targets Id=$INSTANCE_ID \
    --query 'TargetHealthDescriptions[0].TargetHealth.State' \
    --output text)
  if [ "$STATE" = "unused" ] || [ "$STATE" = "draining" ]; then
    sleep 10
  else
    break
  fi
done

Explanation:

For zero-downtime without blue/green overhead:

• Deploys to one instance at a time
• 9 of 10 instances remain healthy throughout
• Longest deployment time but zero downtime
• No additional infrastructure required

• Similar concept but may deploy to multiple instances
• Can be configured similar to OneAtATime

• OneAtATime: Safest, slowest
• HalfAtATime: Faster, 50% capacity during deployment
• AllAtOnce: Fastest, but causes downtime

For 10 instances with zero-downtime requirement and no infrastructure overhead, OneAtATime sequentially updates each instance while maintaining 90% capacity.

Explanation:

ECS blue/green with CodeDeploy requires:

• Production traffic target group
• Test traffic target group
• Both associated with the ALB (different listener rules or ports)

{
  "serviceName": "my-service",
  "deploymentController": {
    "type": "CODE_DEPLOY"
  }
}

• Application type: ECS
• Deployment group linked to ECS service, cluster, target groups

• ALB listener(s) configured for traffic routing
• Task definition for the service
• appspec.yml defining the deployment

Without both the target groups and the correct deployment controller type, CodeDeploy cannot manage ECS blue/green deployments.

Explanation:

For Lambda functions with aliases:

• Lambda alias points to weighted versions
• During deployment: alias points to original version + new version with weights
• Example at 10% shift: 90% invocations → v1, 10% → v2

• Event source mapping triggers the alias
• Each invocation goes to version based on alias weights
• Individual SQS messages may invoke different versions
• This is request-level shifting, not message-level

• Eventual consistency in Lambda's traffic shifting
• Some SQS messages processed by old version, some by new
• Both versions should be able to handle messages correctly
• Consider idempotency in message processing

Traffic shifting works for all Lambda invocation types (API Gateway, SQS, EventBridge, etc.) because it operates at the alias level.

Explanation:

AWS AppConfig feature flags provide:

1. Purpose-built for feature flags:

• Boolean, number, or JSON flag types
• Percentage-based rollouts
• User segment targeting

1. Safe deployments:

• Validation before deployment
• Gradual rollout strategies
• Automatic rollback on errors

1. Lambda integration:

• AppConfig Lambda extension for efficient caching
• Minimal latency impact
• Automatic refresh of configuration

import appconfig_helper

# Lambda extension handles caching and updates
appconfig = appconfig_helper.AppConfigHelper(
    app='my-app',
    env='production',
    name='feature-flags'
)

def handler(event, context):
    if appconfig.get('new-feature-enabled'):
        return new_feature_code()
    else:
        return original_code()

AppConfig is preferred over Parameter Store for feature flags due to deployment strategies and validation capabilities.

Explanation:

When instances don't receive deployments:

1. No CodeDeploy agent (Option B):

• Agent must be installed and running
• Check: sudo service codedeploy-agent status
• Agent communicates with CodeDeploy service

1. Instance launched after deployment:

• True, but for Auto Scaling groups, lifecycle hooks can trigger deployment
• For standalone EC2, needs separate mechanism

1. AMI without agent:

• If using custom AMI, agent must be included
• Or use user data to install agent on launch

1. Install CodeDeploy agent
2. For future instances, include agent in AMI or user data
3. Use Auto Scaling lifecycle hooks for automatic deployment

For instances matching tag criteria but not receiving deployments, verify agent status first.

Explanation:

For single-instance zero-downtime deployment:

1. Launch new instance
2. Deploy to new instance
3. Test new instance
4. Swap Elastic IP from old to new
5. Terminate old instance

This provides near-zero-downtime (seconds for IP reassignment).

1. Use weighted routing to current instance
2. Launch new instance with deployment
3. Add new instance to Route 53 with weight
4. Gradually shift traffic
5. Remove old instance

• Requires DNS client cache considerations
• More complex setup
• Longer transition period

For single-instance scenarios, Option B with Elastic IP is cleaner and faster for cutover.

Explanation:

AfterAllowTraffic hook for Lambda:

1. Hook is a Lambda function
2. Receives deployment lifecycle event
3. Must call CodeDeploy to report status

import boto3

codedeploy = boto3.client('codedeploy')

def handler(event, context):
    deployment_id = event['DeploymentId']
    lifecycle_event_hook_execution_id = event['LifecycleEventHookExecutionId']
    
    try:
        # Run tests against deployed function
        test_result = run_integration_tests()
        
        if test_result['passed']:
            status = 'Succeeded'
        else:
            status = 'Failed'
            
    except Exception as e:
        status = 'Failed'
    
    # Report back to CodeDeploy
    codedeploy.put_lifecycle_event_hook_execution_status(
        deploymentId=deployment_id,
        lifecycleEventHookExecutionId=lifecycle_event_hook_execution_id,
        status=status
    )

If status is 'Failed', CodeDeploy automatically rolls back the deployment.

Explanation:

Deployment speed analysis:

• 50 instances × (deployment time per instance)
• If each takes ~1 minute, total = ~50 minutes
• Safest but slowest

• 25 instances deploy simultaneously
• Then remaining 25
• Roughly 2× faster than OneAtATime
• Maintains 50% capacity

• 90% of instances can deploy simultaneously
• Only 5 instances must remain healthy
• Much faster, but higher risk if deployment fails
• 45 instances deploy at once, then remaining 5

• Fastest but causes complete outage if issues
• No capacity during deployment

Explanation:

When CodeDeploy creates replacement Auto Scaling group for blue/green:

• ASG configuration (min, max, desired, health checks)
• Tags
• Load balancer/target group associations

• Launch template version (if "Latest" was specified)
• Launch configuration (if modified between deployment creation and execution)

• Use specific launch template versions, not "Latest"
• Or use deployment group settings to explicitly specify launch template version

For exam: Understand that blue/green copies ASG at deployment time, and "Latest" version references can cause unexpected changes.

Explanation:

CodeDeploy itself doesn't have built-in approval workflows. Implement approvals in CodePipeline:

{
  "stageName": "Production",
  "actions": [
    {
      "name": "ManualApproval",
      "actionTypeId": {
        "category": "Approval",
        "owner": "AWS",
        "provider": "Manual"
      },
      "configuration": {
        "NotificationArn": "arn:aws:sns:...",
        "CustomData": "Please review deployment before approving"
      }
    },
    {
      "name": "DeployToProduction",
      "actionTypeId": {
        "category": "Deploy",
        "provider": "CodeDeploy"
      }
    }
  ]
}

{
  "Effect": "Allow",
  "Action": "codepipeline:PutApprovalResult",
  "Resource": "arn:aws:codepipeline:*:*:pipeline-name/Production/*"
}

Only specified users can approve. All approval actions are logged in CloudTrail.

Explanation:

ECS cluster "draining" state:

1. Cluster deletion initiated - Cluster is being deleted
2. Container instance draining - Instances marked for removal
3. Capacity provider changes - Underlying capacity being modified

• Cluster must be able to run both original and replacement task sets
• Draining state prevents new task placement

1. Wait for drain operation to complete
2. If cluster being deleted, cancel or use different cluster
3. Verify sufficient capacity for both task sets
4. Check capacity provider status

Explanation:

CodeDeploy doesn't have built-in deployment sequencing within a deployment group.

1. Create separate deployment groups:

• DeploymentGroup-EC2 targeting EC2 instances
• DeploymentGroup-OnPrem targeting on-premises servers

1. Orchestrate with CodePipeline:

Stage: Deploy-EC2
  Action: Deploy to DeploymentGroup-EC2

Stage: Validate
  Action: Run validation tests/approval

Stage: Deploy-OnPrem
  Action: Deploy to DeploymentGroup-OnPrem

• Allows validation between deployments
• Provides clear deployment sequencing
• Enables rollback at each stage

Alternative: Manual deployment sequencing via CLI/SDK.

Explanation:

For graceful shutdown during CodeDeploy:

• Runs before new revision is installed
• Purpose: Stop running application gracefully
• Executes scripts from PREVIOUS deployment
• Ideal for cleanup, connection draining, state saving

#!/bin/bash
# scripts/application_stop.sh

# Signal application to start graceful shutdown
kill -SIGTERM $(cat /var/run/app.pid)

# Wait for application to finish processing
sleep 30

# Verify application stopped
if pgrep -f "myapp" > /dev/null; then
  echo "Application didn't stop gracefully, forcing..."
  kill -9 $(cat /var/run/app.pid)
fi

BeforeBlockTraffic is for in-place deployments with load balancer integration (removing from LB before stopping).

Explanation:

Lifecycle hook purposes:

• Application files deployed but app not yet started
• Perfect for: configuration application, permissions, external config sync
• Configuration management (Ansible, Puppet, Chef) integration point

#!/bin/bash
# Sync configuration from external system
/opt/configuration-management/sync-config.sh

# Apply environment-specific settings
ansible-playbook /opt/playbooks/configure-app.yml

# Set file permissions
chown -R app:app /var/www/app

1. BeforeInstall - pre-deployment tasks
2. Install - files copied
3. AfterInstall - configure installed files ← External config here
4. ApplicationStart - start application
5. ValidateService - verify application works

Configuration should be applied before the application starts (AfterInstall), not after (ValidateService).

Explanation:

Important clarification about CodeDeploy behavior:

• Deploys to X instances simultaneously (based on minimum healthy hosts)
• Waits for those to complete
• Then continues to next instances
• All within a single deployment operation

• Pause between batches for monitoring
• Time-based delays between instance updates

Stage 1: Deploy (10% of instances)
Stage 2: Wait (Lambda with sleep or Step Functions)
Stage 3: Deploy (next 10%)
...

• Orchestrate multiple smaller deployments
• Add wait states between deployments

Explanation:

For database migrations that must complete before ANY deployment:

• Migrations run once, before deployment starts
• Single execution, not per-instance
• Can fail pipeline before any CodeDeploy activity
• Clear separation of concerns

• Hooks run on EACH instance
• Migrations would run multiple times (race conditions, failures)
• First instance might succeed, subsequent fail on already-migrated DB
• No rollback capability for partial deployments

Pipeline:
├── Source
├── Build (CodeBuild)
├── Migrate (CodeBuild - run DB migrations)
│   └── Fails here = no deployment
└── Deploy (CodeDeploy - application code)

phases:
  build:
    commands:
      - npm run db:migrate

Explanation:

CodeDeploy Lambda hooks have specific requirements:

• Lambda deployment lifecycle hooks have their own timeout
• Default hook timeout: 1 hour (configurable)
• But the hook Lambda function must RESPOND to CodeDeploy

1. Run for 8 minutes
2. Complete its work
3. Exit without calling put_lifecycle_event_hook_execution_status
4. CodeDeploy waits for response until timeout

def handler(event, context):
    # Do validation work (up to 8 minutes)
    perform_validation()
    
    # MUST report status back to CodeDeploy
    codedeploy = boto3.client('codedeploy')
    codedeploy.put_lifecycle_event_hook_execution_status(
        deploymentId=event['DeploymentId'],
        lifecycleEventHookExecutionId=event['LifecycleEventHookExecutionId'],
        status='Succeeded'  # or 'Failed'
    )

Without this callback, CodeDeploy assumes the hook is still running.

Explanation:

Blue/green deployments have multiple health check layers:

• Path, port, protocol
• Healthy/unhealthy thresholds
• Interval and timeout

• ELB health check type (instances must pass ALB checks)
• Or EC2 health check type (basic EC2 status)

• System status, instance status

• ALB says healthy, but CodeDeploy has different threshold
• CodeDeploy's evaluation period differs from ALB
• Code Deploy waits for configurable duration for instances to become healthy

# Check deployment events
aws deploy get-deployment \
  --deployment-id d-123456 \
  --query 'deploymentInfo.deploymentOverview'

Check CodeDeploy deployment group health check settings and compare with ALB target group settings for consistency.

Explanation:

CodeDeploy doesn't have native deployment window scheduling. Implement via pipeline:

import datetime
from pytz import timezone

def handler(event, context):
    est = timezone('America/New_York')
    now = datetime.datetime.now(est)
    
    # Check if within business hours
    if now.weekday() < 5 and 9 <= now.hour < 17:
        # Proceed with deployment
        return put_success(event)
    else:
        # Calculate wait time until next window
        wait_message = calculate_next_window(now)
        return put_failure(event, wait_message)

1. EventBridge + Lambda: Pause pipeline outside hours
2. Step Functions: Implement wait until business hours
3. Approval action: Automated approval only during hours

For exam: Know that CodeDeploy itself doesn't have window scheduling; implement at pipeline level.

Explanation:

AWS SAM integrates CodeDeploy for gradual deployments:

MyFunction:
  Type: AWS::Serverless::Function
  Properties:
    AutoPublishAlias: live
    DeploymentPreference:
      Type: Linear10PercentEvery1Minute
      Alarms:
        - !Ref AliasErrorMetricAlarm
      Hooks:
        PreTraffic: !Ref PreTrafficHookFunction
        PostTraffic: !Ref PostTrafficHookFunction

1. New Lambda version on each deployment
2. CodeDeploy application and deployment group
3. Alias updates with traffic shifting
4. Alarm-based rollback configuration

• Canary10Percent5Minutes, Canary10Percent10Minutes, etc.
• Linear10PercentEvery1Minute, Linear10PercentEvery2Minutes, etc.
• AllAtOnce

SAM handles the CodeDeploy resource creation, simplifying serverless CI/CD.

Explanation:

Multiple approaches for environment-specific config:

# scripts/configure_environment.sh (AfterInstall)
ENV=$(curl -s http://169.254.169.254/latest/meta-data/tags/instance/Environment)

case $ENV in
  development)
    cp /opt/config/dev.properties /var/app/config/app.properties
    ;;
  staging)
    cp /opt/config/staging.properties /var/app/config/app.properties
    ;;
  production)
    cp /opt/config/prod.properties /var/app/config/app.properties
    ;;
esac

# scripts/configure_environment.sh
ENV=$(curl -s http://169.254.169.254/latest/meta-data/tags/instance/Environment)

aws ssm get-parameters-by-path \
  --path "/${ENV}/app/config" \
  --output text > /var/app/config/app.properties

• Configuration changes without redeployment
• Encryption for sensitive values
• Audit trail of changes
• Version control

Explanation:

For Docker container deployments on EC2 with CodeDeploy:

#!/bin/bash
# Stop existing container
docker stop my-app-container || true
docker rm my-app-container || true

#!/bin/bash
# Login to ECR
aws ecr get-login-password --region $AWS_REGION | \
  docker login --username AWS --password-stdin $ECR_REGISTRY

# Pull latest image
docker pull $ECR_REGISTRY/my-app:$VERSION

# Start container
docker run -d \
  --name my-app-container \
  -p 80:80 \
  $ECR_REGISTRY/my-app:$VERSION

• Install phase copies files from S3 (scripts, configs)
• Docker image pull happens in hooks, not Install
• Version can be passed via environment variable or appspec

The deployment bundle contains scripts and configuration, not the Docker image itself.

Explanation:

ECS "steady state" requires all tasks to be running and healthy. Failure causes:

• Invalid image reference
• Incorrect environment variables
• Resource limits too low
• Missing IAM permissions

• Not enough CPU/memory in cluster
• No available container instances
• Fargate capacity not available

• Container starts but health check fails
• Load balancer health check path incorrect
• Application startup time exceeds health check grace period

# Check ECS service events
aws ecs describe-services \
  --cluster my-cluster \
  --services my-service \
  --query 'services[0].events[:10]'

# Check stopped tasks
aws ecs describe-tasks \
  --cluster my-cluster \
  --tasks <task-id> \
  --query 'tasks[0].stoppedReason'

Check ECS events and stopped task reasons for specific failure cause.

Explanation:

Environment-specific deployment considerations:

Production: Linear10PercentEvery10Minutes
Non-prod: Linear10PercentEvery1Minute or AllAtOnce

Faster in non-prod for quick feedback.

Production alarm: Error rate > 5%
Non-prod alarm: Error rate > 1%

Catch problems earlier in lower environments.

• Same deployment TYPE (e.g., blue/green)
• Faster time intervals in non-prod
• Similar but appropriately-scaled thresholds
• Test rollback procedures in non-prod

Explanation:

For post-traffic-shift bake time:

import time
import boto3

def handler(event, context):
    deployment_id = event['DeploymentId']
    hook_execution_id = event['LifecycleEventHookExecutionId']
    
    cloudwatch = boto3.client('cloudwatch')
    codedeploy = boto3.client('codedeploy')
    
    # Monitor for 30 minutes
    end_time = time.time() + (30 * 60)
    
    while time.time() < end_time:
        # Check metrics
        if check_error_metrics(cloudwatch):
            # Errors detected - fail deployment
            codedeploy.put_lifecycle_event_hook_execution_status(
                deploymentId=deployment_id,
                lifecycleEventHookExecutionId=hook_execution_id,
                status='Failed'
            )
            return
        time.sleep(60)  # Check every minute
    
    # Bake time completed successfully
    codedeploy.put_lifecycle_event_hook_execution_status(
        deploymentId=deployment_id,
        lifecycleEventHookExecutionId=hook_execution_id,
        status='Succeeded'
    )

Explanation:

"No instances found" error troubleshooting:

1. Auto Scaling group targeting:

• Verify ASG name is correct in deployment group
• ASG must exist and have running instances
• Instances must be InService state

1. Tag-based targeting:

• If configured with tags, instances must match tags
• Multiple tag conditions use AND logic
• Check tag key/value spelling

• Deployment group references ASG that was deleted/recreated
• ASG name changed but deployment group not updated
• Mixed targeting (expecting ASG but configured for tags)

# Check deployment group configuration
aws deploy get-deployment-group \
  --application-name MyApp \
  --deployment-group-name MyDG \
  --query 'deploymentGroupInfo.autoScalingGroups'

# Verify ASG
aws autoscaling describe-auto-scaling-groups \
  --auto-scaling-group-names MyASG

Explanation:

Standardizing CodeDeploy configurations:

Resources:
  DeploymentGroup:
    Type: AWS::CodeDeploy::DeploymentGroup
    Properties:
      ApplicationName: !Ref Application
      DeploymentConfigName: CodeDeployDefault.AllAtOnce
      AutoRollbackConfiguration:
        Enabled: true
        Events:
          - DEPLOYMENT_FAILURE
          - DEPLOYMENT_STOP_ON_ALARM
      AlarmConfiguration:
        Enabled: true
        Alarms:
          - Name: !Ref ErrorAlarm

• Version-controlled infrastructure
• Consistent deployment group creation
• Parameterized for different environments

• Pre-deployment validation of deployment group configuration
• CI/CD check before allowing deployments
• Audit trail of changes

AWS Config (Option C) can detect drift but not enforce settings proactively.

Explanation:

CodeDeploy lifecycle hook timeout:

hooks:
  ValidateService:
    - location: scripts/run_tests.sh
      timeout: 3600  # Maximum: 3600 seconds (1 hour)

• Default timeout: 3600 seconds
• Maximum timeout: 3600 seconds
• If script doesn't complete within timeout, hook fails
• Hook failure causes deployment failure (unless configured otherwise)

• Break tests into smaller scripts
• Run tests asynchronously (script returns, tests continue)
• Use external systems for long-running validations
• Consider moving tests to separate pipeline stage

For 10-minute tests, the default timeout is sufficient. Check if script is hanging or tests are actually taking longer than expected.

Explanation:

CodeDeploy doesn't have native AZ-aware deployment ordering. Implement via:

1. Tag instances by AZ:

• Tag: AZ: us-east-1a
• Tag: AZ: us-east-1b

1. Create deployment groups per AZ:

• DeploymentGroup-AZ-1a (targets AZ: us-east-1a)
• DeploymentGroup-AZ-1b (targets AZ: us-east-1b)

1. Pipeline orchestration:

Stage: Deploy-AZ-1a
  Action: Deploy to DeploymentGroup-AZ-1a
  
Stage: Validate-AZ-1a
  Action: Health check / manual approval
  
Stage: Deploy-AZ-1b
  Action: Deploy to DeploymentGroup-AZ-1b

Explanation:

Traffic shifting behavior clarification:

• Each NEW invocation is routed based on current alias weights
• During traffic shift: some invocations go to v1, some to v2
• After shift complete: all invocations go to new version

1. Connection reuse: Some SDKs/clients reuse connections
2. Provisioned concurrency: Old version PC instances still exist
3. Step Functions/SQS: Messages queued before shift complete
4. Event source mapping: Takes time to fully shift

# Check alias configuration
aws lambda get-alias \
  --function-name MyFunction \
  --name live

# Should show 100% to new version

If alias shows 100% new version but old version still invoked, check client connection patterns and event sources.

Explanation:

CodeDeploy applications are platform-specific:

• EC2/On-premises
• Lambda
• ECS

CodePipeline:
├── Source Stage
├── Build Stage
├── Deploy Stage (parallel actions):
│   ├── Action: Deploy to EC2 (CodeDeploy EC2 app)
│   ├── Action: Deploy to Lambda (CodeDeploy Lambda app)
│   └── Action: Deploy to ECS (CodeDeploy ECS app)

1. Create separate CodeDeploy applications:

• MyApp-EC2 (platform: Server)
• MyApp-Lambda (platform: Lambda)
• MyApp-ECS (platform: ECS)

1. CodePipeline Deploy stage with parallel actions

1. Build stage produces artifacts for all platforms

This provides unified pipeline with platform-appropriate deployments.

Explanation:

CodeDeploy notification options:

def lambda_handler(event, context):
    deployment_id = event['detail']['deploymentId']
    state = event['detail']['state']
    
    message = f"CodeDeploy deployment {deployment_id}: {state}"
    
    # Post to Slack
    slack_webhook = os.environ['SLACK_WEBHOOK']
    requests.post(slack_webhook, json={'text': message})

{
  "source": ["aws.codedeploy"],
  "detail-type": ["CodeDeploy Deployment State-change Notification"],
  "detail": {
    "state": ["START", "SUCCESS", "FAILURE"]
  }
}

• Native AWS Chatbot integration with Slack
• Configure SNS topic notifications
• Chatbot formats and delivers to Slack

Both approaches work. AWS Chatbot is simpler if you have standard notifications. Lambda provides more customization.

Explanation:

ASG lifecycle hooks for CodeDeploy require:

AutoScaling group → Launching → Pending:Wait → CodeDeploy deploys → Complete lifecycle → InService

• Hook timeout must exceed: agent installation + deployment time
• Default: 3600 seconds (1 hour)
• If timeout expires, instance transitions based on default action

{
  "Action": [
    "autoscaling:CompleteLifecycleAction",
    "autoscaling:RecordLifecycleActionHeartbeat"
  ],
  "Resource": "*"
}

• Hook exists for EC2_INSTANCE_LAUNCHING
• Hook HeartbeatTimeout is sufficient
• CodeDeploy service role has ASG permissions
• CodeDeploy agent is in AMI or installed via user data

Explanation:

For 1% canary deployments:

aws deploy create-deployment-config \
  --deployment-config-name Canary1Percent1Hour \
  --compute-platform Lambda \
  --traffic-routing-config '{
    "type": "TimeBasedCanary",
    "timeBasedCanary": {
      "canaryPercentage": 1,
      "canaryInterval": 60
    }
  }'

• 1% traffic to new version
• 60-minute evaluation period
• Then 100% shift if successful

{
  "alarmConfiguration": {
    "enabled": true,
    "alarms": [{"name": "Lambda-Errors"}]
  },
  "autoRollbackConfiguration": {
    "enabled": true,
    "events": ["DEPLOYMENT_STOP_ON_ALARM"]
  }
}

AWS-provided configurations use 10% minimum for canary. Custom configurations allow lower percentages.

Explanation:

Connection drops during traffic shift have two causes:

• Linear10PercentEvery1Minute: Gradual shift
• Canary10Percent10Minutes: Test with 10% first

aws elbv2 modify-target-group-attributes \
  --target-group-arn $TG_ARN \
  --attributes Key=deregistration_delay.timeout_seconds,Value=300

• Linear traffic shift gives time for monitoring
• Deregistration delay allows requests on old tasks to complete
• New requests go to new tasks

• Application graceful shutdown handling
• Connection timeout settings
• Health check intervals

Explanation:

Long-term rollback options:

{
  "blueGreenDeploymentConfiguration": {
    "terminateBlueInstancesOnDeploymentSuccess": {
      "action": "TERMINATE",
      "terminationWaitTimeInMinutes": 10080  // 7 days
    }
  }
}

{
  "terminateBlueInstancesOnDeploymentSuccess": {
    "action": "KEEP_ALIVE"
  }
}

Instances remain until manually terminated. Rollback by traffic shift or ASG swap.

• Keep AMI or snapshot of previous version
• Maintain previous version in a scaled-down ASG
• Create rollback deployment if needed

For exam: Understand the cost implications of keeping old environments running.

Explanation:

AllAtOnce behavior depends on minimum healthy hosts:

• minimumHealthyHosts: type: HOST_COUNT, value: 0
• With this setting: Any failures = deployment fails
• But successfully deployed instances KEEP the new version

• Deployment status: FAILED (not all instances succeeded)
• 3 instances have new version
• 2 instances have old version (deployment failed on them)

• Deployment status: SUCCEEDED (3 meets minimum)
• 3 instances have new version
• 2 instances need follow-up deployment

{
  "autoRollbackConfiguration": {
    "enabled": true,
    "events": ["DEPLOYMENT_FAILURE"]
  }
}

Explanation:

"Stop on first failure" implementation:

• Deploys to one instance at a time
• If instance fails, deployment stops immediately
• No additional instances are attempted
• Provides stop-on-first-failure behavior

Instance 1: Success ✓ → Continue
Instance 2: Success ✓ → Continue
Instance 3: Failure ✗ → Stop deployment
Instance 4: Not attempted
Instance 5: Not attempted

• Sequential deployment
• Failure immediately fails the entire deployment
• No additional instances are affected

• HalfAtATime: Continues with remaining instances in the batch
• AllAtOnce: All instances attempted regardless of failures

For strict stop-on-first-failure, OneAtATime is the answer.

Explanation:

Preventing unintended resource replacement:

1. Create change set instead of direct update
2. Lambda analyzes change set for replacements:

def analyze_change_set(change_set_id):
    changes = cfn.describe_change_set(ChangeSetName=change_set_id)
    
    for change in changes['Changes']:
        if change['ResourceChange']['Replacement'] == 'True':
            return 'REJECT'
    
    return 'APPROVE'

1. Pipeline approval based on analysis

{
  "Statement": [{
    "Effect": "Deny",
    "Action": "Update:Replace",
    "Principal": "*",
    "Resource": "LogicalResourceId/MyDatabase"
  }]
}

Stack policies protect specific resources but require knowing which to protect. Change set analysis provides dynamic checking.

Explanation:

Using CreationPolicy and cfn-signal:

Resources:
  MyEC2Instance:
    Type: AWS::EC2::Instance
    CreationPolicy:
      ResourceSignal:
        Count: 1
        Timeout: PT15M  # 15 minutes
    Metadata:
      AWS::CloudFormation::Init:
        config:
          packages:
            yum:
              httpd: []
          services:
            sysvinit:
              httpd:
                enabled: true
                ensureRunning: true
    Properties:
      UserData:
        Fn::Base64: !Sub |
          #!/bin/bash -xe
          yum update -y aws-cfn-bootstrap
          /opt/aws/bin/cfn-init -v \
            --stack ${AWS::StackName} \
            --resource MyEC2Instance \
            --region ${AWS::Region}
          /opt/aws/bin/cfn-signal -e $? \
            --stack ${AWS::StackName} \
            --resource MyEC2Instance \
            --region ${AWS::Region}

1. CreationPolicy makes CloudFormation wait for signal
2. cfn-signal sends success/failure based on cfn-init exit code ($?)
3. Stack fails if timeout or failure signal received

Explanation:

StackSets automatic deployment:

StackSet:
  AutoDeployment:
    Enabled: true
    RetainStacksOnAccountRemoval: false

StackSetDeploymentTargets:
  OrganizationalUnitIds:
    - ou-abc123

1. StackSet targets OU (not individual accounts)
2. Automatic deployment enabled
3. When new account joins OU → StackSet automatically deploys
4. When account leaves OU → stacks optionally removed

• AWS Organizations integration
• StackSet created with SERVICE_MANAGED permissions
• Trusted access enabled for CloudFormation StackSets

This provides automatic governance and baseline deployment for new accounts.

Explanation:

Controlling Lambda update behavior:

MyFunction:
  Type: AWS::Lambda::Function
  Properties:
    Code:
      S3Bucket: !Ref DeploymentBucket
      S3Key: !Sub "functions/my-function-${CodeVersion}.zip"

When CodeVersion parameter changes → function code updates When other parameters change → function code doesn't update

sam package --s3-bucket my-bucket

The key is controlling the S3 key changes to match code changes only.

Explanation:

CloudFormation ASG update policies:

MyASG:
  Type: AWS::AutoScaling::AutoScalingGroup
  UpdatePolicy:
    AutoScalingReplacingUpdate:
      WillReplace: true

1. Creates new ASG with updated launch template
2. New instances launch and register with target group
3. Health checks pass → old ASG instances terminate
4. Old ASG deleted

This provides blue/green behavior within CloudFormation.

UpdatePolicy:
  AutoScalingRollingUpdate:
    MinInstancesInService: 1
    MaxBatchSize: 1
    PauseTime: PT10M

For true blue/green: Use AutoScalingReplacingUpdate or external tools (CodeDeploy).

Explanation:

Disabling rollback for debugging:

aws cloudformation update-stack \
  --stack-name my-stack \
  --template-body file://template.yaml \
  --disable-rollback

1. Update fails → stack enters UPDATE_FAILED status
2. Resources remain in their current state (partially updated)
3. Engineer can investigate (check logs, resource state)
4. After investigation, continue or roll back:

aws cloudformation continue-update-rollback --stack-name my-stack

• Development and debugging
• Understanding complex failure scenarios
• NOT recommended for production (leaves stack in inconsistent state)

Explanation:

Managing cross-stack dependencies:

• Stack A exports !Export { Name: VpcId }
• Stack B imports !ImportValue VpcId
• Trying to update Stack A's export fails because it's in use

# Stack A
Resources:
  VpcIdParameter:
    Type: AWS::SSM::Parameter
    Properties:
      Name: /infra/vpc-id
      Type: String
      Value: !Ref VPC

# Stack B
Resources:
  MyResource:
    Properties:
      VpcId: "{{resolve:ssm:/infra/vpc-id}}"

• No hard coupling between stacks
• Values can be updated independently
• Dynamic resolution at deployment time

Cross-stack references via SSM provide more flexibility than CloudFormation exports.

Explanation:

Elastic Beanstalk customization options:

.platform/
  nginx/
    conf.d/
      custom-headers.conf

add_header X-Custom-Header "MyValue";
add_header X-Frame-Options "DENY";

This automatically merges with Nginx configuration.

# .ebextensions/nginx-headers.config
files:
  "/etc/nginx/conf.d/custom-headers.conf":
    mode: "000644"
    owner: root
    group: root
    content: |
      add_header X-Custom-Header "MyValue";

• Cleaner structure
• Survives platform updates better
• Specific directories for known customizations (nginx, hooks)

Option A (SSH) is not reproducible. Option C (custom AMI) adds maintenance burden.

Explanation:

Elastic Beanstalk deployment hooks (Amazon Linux 2):

.platform/hooks/
  prebuild/    # Before application builds
  predeploy/   # After build, before deployment
  postdeploy/  # After deployment complete

.platform/hooks/postdeploy/99_run_migrations.sh

#!/bin/bash
cd /var/app/current
./run-migrations.sh

container_commands:
  01_run_script:
    command: "./post-deploy-script.sh"

• container_commands run BEFORE app is live
• postdeploy hooks run AFTER app is live

For post-deployment with running application, use .platform/hooks/postdeploy/ on Amazon Linux 2.

Explanation:

Atomic infrastructure and application deployment:

Resources:
  # Infrastructure
  MySecurityGroup:
    Type: AWS::EC2::SecurityGroup
    
  MyLoadBalancer:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    
  # Application
  MyLambdaFunction:
    Type: AWS::Lambda::Function
    Properties:
      Code:
        S3Bucket: !Ref DeploymentBucket
        S3Key: !Ref CodeVersion
        
  # Or ECS Service
  MyECSService:
    Type: AWS::ECS::Service

1. CloudFormation creates change set with all changes
2. If any resource fails → entire stack rolls back
3. Both infrastructure and application return to previous state

Source → Build → Deploy (CloudFormation with application code packaged)

CloudFormation's native rollback handles the atomicity requirement.

Explanation:

Duplicate message processing causes:

• Message becomes visible again before processing completes
• Another worker picks up the same message
• Solution: Increase visibility timeout to exceed maximum processing time

• SQS provides "at least once" delivery (standard queues)
• Same message might be delivered multiple times
• Solution: Implement idempotent processing

python
  def process_message(message):
      message_id = message['MessageId']
      if already_processed(message_id):  # Check DynamoDB/cache
          return
      do_work(message)
      mark_processed(message_id)

• Automatically deletes messages after successful processing (HTTP 200)
• Keeps messages visible during processing
• Returns messages to queue on failure

Both visibility timeout adjustment AND idempotent processing are best practices.

Explanation:

Protecting RDS from deletion:

MyDatabase:
  Type: AWS::RDS::DBInstance
  DeletionPolicy: Retain
  Properties:
    ...

When stack is deleted, RDS instance remains (orphaned).

MyDatabase:
  Type: AWS::RDS::DBInstance
  Properties:
    DeletionProtection: true
    ...

Prevents deletion via API/console. Must disable before deleting.

1. DeletionPolicy: Retain - CloudFormation won't delete
2. DeletionProtection: true - Even if someone tries to delete directly, blocked
3. Stack termination protection - Prevents accidental stack deletion

Explanation:

Nested stack update options:

• Child stacks are regular CloudFormation stacks
• Can be updated directly using stack name or ID
• Changes are independent of parent

• Quick fixes to child stack
• Independent component updates
• Parent template doesn't need changes

• Parent template might become out of sync with child state
• Next parent update might cause unexpected child changes
• Drift detection can identify differences

• Coordinated changes across stacks
• Version control of complete infrastructure
• Consistent state management

Explanation:

Credential rotation without deployment:

# Application code
import boto3
import json

def get_db_credentials():
    client = boto3.client('secretsmanager')
    response = client.get_secret_value(SecretId='prod/db-credentials')
    return json.loads(response['SecretString'])

# Connection with refresh
def get_connection():
    creds = get_db_credentials()  # Gets current credentials
    return connect(creds['username'], creds['password'])

• Secrets Manager rotates credentials
• Application fetches new credentials on next call
• No deployment required

ssm = boto3.client('ssm')
password = ssm.get_parameter(Name='/prod/db-password', WithDecryption=True)

• Updating env properties restarts instances
• Credentials visible in Beanstalk console
• No automatic rotation

Explanation:

Custom resource behavior:

import cfnresponse

def handler(event, context):
    try:
        # Do work (10 minutes)
        result = create_external_resource()
        
        # MUST send response
        cfnresponse.send(event, context, cfnresponse.SUCCESS, {
            'ResourceId': result['id']
        })
    except Exception as e:
        cfnresponse.send(event, context, cfnresponse.FAILED, {
            'Error': str(e)
        })

1. Lambda timeout before work completes (Lambda dies, no response)
2. Function completes but doesn't send response (CloudFormation waits)
3. Response sent to wrong URL (misconfigured)

• Check Lambda logs for completion
• Verify cfnresponse.send is called
• Check Lambda timeout (max 15 minutes)

For long-running tasks, use Step Functions or asynchronous pattern with status polling.

Explanation:

Multi-region Beanstalk deployment options:

Parameters:
  Region:
    Type: String
  DatabaseEndpoint:
    Type: String

Resources:
  BeanstalkEnvironment:
    Type: AWS::ElasticBeanstalk::Environment
    Properties:
      OptionSettings:
        - Namespace: aws:elasticbeanstalk:application:environment
          OptionName: DB_ENDPOINT
          Value: !Ref DatabaseEndpoint

Deploy with region-specific parameters.

1. Create environment in one region
2. Save configuration
3. Download and modify for other regions
4. Create environments from saved configs

• Cloning is same-region only
• Doesn't work across regions

Explanation:

Custom resource lifecycle handling:

def handler(event, context):
    request_type = event['RequestType']
    
    if request_type == 'Create':
        dns_record_id = create_dns_record(event['ResourceProperties'])
        response_data = {'RecordId': dns_record_id}
        cfnresponse.send(event, context, cfnresponse.SUCCESS, response_data)
        
    elif request_type == 'Delete':
        record_id = event['PhysicalResourceId']
        delete_dns_record(record_id)
        cfnresponse.send(event, context, cfnresponse.SUCCESS, {})
        
    elif request_type == 'Update':
        # Handle updates
        pass

1. Create: Stack creation or resource addition
2. Update: Resource property changes
3. Delete: Stack deletion or resource removal

• Returned in Create response
• Provided in Update/Delete events
• Used to identify the external resource

The Lambda MUST handle Delete requests for proper cleanup.

Explanation:

Enforcing pipeline-only updates:

{
  "Effect": "Deny",
  "Action": [
    "cloudformation:UpdateStack",
    "cloudformation:DeleteStack",
    "cloudformation:CreateStack"
  ],
  "Resource": "arn:aws:cloudformation:*:*:stack/prod-*/*"
}

{
  "Effect": "Allow",
  "Action": ["cloudformation:*"],
  "Resource": "arn:aws:cloudformation:*:*:stack/prod-*/*"
}

1. Stack termination protection: Prevents accidental deletion
2. Stack policies: Control specific resource modifications
3. SCPs: Organization-level restrictions

Code Change → PR Approval → Pipeline Triggers → 
Pipeline Role → CloudFormation Update

Humans cannot directly modify production stacks; all changes go through pipeline.

Explanation:

Scaling event vs deployment hooks:

• New instances launched from AMI
• Not the same as deployment
• Need hooks that run on instance launch

# .ebextensions/01-scale-commands.config
commands:
  01_run_on_scale:
    command: "/opt/scripts/scale-setup.sh"

OR User Data in launch template customization.

• commands: Run during instance launch (before app deployment)
• container_commands: Run during deployment (leader election available)
• .platform/hooks/: Run during deployment lifecycle

For scaling-only commands (new instances, no deployment), use commands section or instance launch scripts.

Explanation:

CloudFormation drift detection automation:

import boto3

def lambda_handler(event, context):
    cfn = boto3.client('cloudformation')
    
    # List all stacks
    stacks = cfn.list_stacks(StackStatusFilter=['CREATE_COMPLETE', 'UPDATE_COMPLETE'])
    
    for stack in stacks['StackSummaries']:
        # Initiate drift detection
        cfn.detect_stack_drift(StackName=stack['StackName'])

# Schedule with CloudWatch Events (daily)

def check_drift_results(event, context):
    cfn = boto3.client('cloudformation')
    
    drift_status = cfn.describe_stack_resource_drifts(StackName=stack_name)
    
    drifted = [r for r in drift_status['StackResourceDrifts'] 
               if r['StackResourceDriftStatus'] == 'MODIFIED']
    
    if drifted:
        send_alert(drifted)

CloudFormation doesn't have built-in automatic drift detection (Option B doesn't exist).

Explanation:

Enforcing S3 security standards:

# Hook Lambda
def validate_s3_bucket(event):
    resource_properties = event['requestData']['targetLogicalId']['properties']
    
    # Check encryption
    if 'BucketEncryption' not in resource_properties:
        return {'status': 'FAILED', 'message': 'Encryption required'}
    
    # Check public access block
    if 'PublicAccessBlockConfiguration' not in resource_properties:
        return {'status': 'FAILED', 'message': 'Public access block required'}
    
    return {'status': 'SUCCESS'}

AWS::S3::Bucket {
  BucketEncryption.ServerSideEncryptionConfiguration[*].ServerSideEncryptionByDefault.SSEAlgorithm == "aws:kms"
  PublicAccessBlockConfiguration.BlockPublicAcls == true
  PublicAccessBlockConfiguration.BlockPublicPolicy == true
}

• s3-bucket-server-side-encryption-enabled
• s3-bucket-public-read-prohibited

Explanation:

Immutable deployment process:

1. Create temporary Auto Scaling group
2. Launch new instances with new version
3. New instances pass health checks
4. New instances added to load balancer
5. Old instances terminated
6. Temporary ASG deleted

Original ASG: 3 instances (old version)
Temporary ASG: 3 instances (new version)
Total: 6 instances

Original ASG: 3 instances (new version)
Temporary ASG: deleted
Total: 3 instances

• No capacity reduction during deployment
• Quick rollback (terminate temporary ASG)
• Clean instances with new version

Explanation:

CIDR validation options:

Resources:
  CIDRValidation:
    Type: Custom::CIDRValidation
    Properties:
      ServiceToken: !GetAtt ValidationFunction.Arn
      ProposedCIDR: "10.0.0.0/16"
      
  MyVPC:
    Type: AWS::EC2::VPC
    DependsOn: CIDRValidation
    Properties:
      CidrBlock: "10.0.0.0/16"

Lambda checks existing VPCs for overlaps.

# Pre-create hook for AWS::EC2::VPC
def validate_cidr(event):
    proposed_cidr = event['requestData']['targetLogicalId']['properties']['CidrBlock']
    
    # Check existing VPCs
    ec2 = boto3.client('ec2')
    vpcs = ec2.describe_vpcs()
    
    for vpc in vpcs['Vpcs']:
        if cidrs_overlap(proposed_cidr, vpc['CidrBlock']):
            return {'status': 'FAILED', 'message': 'CIDR overlap detected'}
    
    return {'status': 'SUCCESS'}

Hooks are cleaner and don't create resources for validation.

Explanation:

EFS mounting in Elastic Beanstalk:

# .ebextensions/efs-mount.config
packages:
  yum:
    amazon-efs-utils: []

commands:
  01_mount:
    command: |
      mkdir -p /mnt/efs
      mount -t efs fs-12345678:/ /mnt/efs
      
files:
  "/etc/fstab":
    mode: "000644"
    owner: root
    group: root
    content: |
      fs-12345678:/ /mnt/efs efs defaults,_netdev 0 0

1. Security group allowing NFS (port 2049) from Beanstalk instances
2. EFS mount targets in same subnets as Beanstalk instances
3. IAM permissions if using IAM authentication

# .platform/hooks/prebuild/01-mount-efs.sh
#!/bin/bash
yum install -y amazon-efs-utils
mkdir -p /mnt/efs
mount -t efs fs-12345678:/ /mnt/efs

Elastic Beanstalk doesn't have native EFS integration in the console; use .ebextensions or .platform hooks.

Explanation:

AWS::Include behavior:

Transform: AWS::Include
Parameters:
  Location: s3://bucket/snippet.yaml

1. Version in URL: s3://bucket/snippet-v2.yaml
2. S3 versioning + version ID: Reference specific versions
3. Force template change: Any change to parent template triggers re-transform
4. Cache busting: Add parameter that changes template hash

Transform: AWS::Include
Parameters:
  Location: !Sub "s3://bucket/snippets/config-${Version}.yaml"

Where ${Version} is a parameter that changes with snippet updates.

CloudFormation processes transforms fresh on each stack operation if the template itself changes.

Explanation:

StackSet deployment configuration:

aws cloudformation update-stack-set \
  --stack-set-name my-stackset \
  --template-body file://template.yaml \
  --operation-preferences '{
    "RegionConcurrencyType": "PARALLEL",
    "MaxConcurrentCount": 10,
    "FailureToleranceCount": 5
  }'

1. RegionConcurrencyType:

• SEQUENTIAL: One region at a time
• PARALLEL: Multiple regions simultaneously

1. MaxConcurrentCount/Percentage:

• How many accounts can update concurrently
• Balance speed vs. impact of failures

1. FailureToleranceCount/Percentage:

• How many failures before operation stops
• Allows graceful handling of individual account issues

• PARALLEL regions
• MaxConcurrentCount: 10-15 accounts
• This allows ~3-4 waves to complete within 2 hours

Explanation:

Rolling deployment failures:

• New version has bugs or configuration issues
• Fails health checks → instance marked unhealthy
• Auto Scaling terminates and replaces
• Cycle continues

• Large batches reduce capacity significantly
• Remaining instances overwhelmed by traffic
• Performance degradation → health check failures

• Application needs longer startup time
• Times out before reaching healthy state
• Deployment fails and rolls back

1. Check Beanstalk events for specific error messages
2. Review application logs in CloudWatch
3. Test new version in a clone environment
4. Increase health check grace period
5. Reduce batch size for safer rollout

# .ebextensions/healthcheck.config
option_settings:
  aws:elasticbeanstalk:command:
    Timeout: 600
  aws:elasticbeanstalk:healthreporting:system:
    HealthCheckSuccessThreshold: Degraded

Explanation:

Separation strategies:

infra-stack: ALB, VPC, Security Groups
lambda-stack: Lambda function (references infra exports)

# parent-stack
Resources:
  InfraStack:
    Type: AWS::CloudFormation::Stack
    Properties:
      TemplateURL: s3://bucket/infra.yaml
      
  LambdaStack:
    Type: AWS::CloudFormation::Stack
    Properties:
      TemplateURL: s3://bucket/lambda.yaml

• CloudFormation for long-lived infrastructure
• SAM for Lambda (faster iterations)
• SAM integrates with CloudFormation

• Separate things that change at different rates
• Lambda code changes frequently → separate stack
• ALB changes rarely → infrastructure stack
• Use stack outputs/imports or SSM for integration

Explanation:

Restricting Beanstalk configurations:

{
  "Effect": "Allow",
  "Action": "elasticbeanstalk:CreateEnvironment",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "elasticbeanstalk:InVPC": "true"
    }
  }
}

{
  "Effect": "Deny",
  "Action": "ec2:RunInstances",
  "Resource": "arn:aws:ec2:*:*:instance/*",
  "Condition": {
    "ForAnyValue:StringNotLike": {
      "ec2:InstanceType": ["t3.small", "t3.medium"]
    }
  }
}

This prevents Beanstalk from launching unapproved instance types.

{
  "Effect": "Deny",
  "Action": "ec2:RunInstances",
  "Resource": "arn:aws:ec2:*:*:subnet/*",
  "Condition": {
    "ForAnyValue:StringNotEquals": {
      "ec2:Subnet": ["subnet-approved1", "subnet-approved2"]
    }
  }
}

SCPs provide organization-wide enforcement regardless of which service launches resources.

Explanation:

SAM deployment preferences:

Transform: AWS::Serverless-2016-10-31

Resources:
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: app.handler
      Runtime: python3.9
      AutoPublishAlias: live  # Option C - required
      DeploymentPreference:   # Option B - deployment configuration
        Type: Canary10Percent10Minutes
        Alarms:
          - !Ref ErrorAlarm
          - !Ref LatencyAlarm
        Hooks:
          PreTraffic: !Ref PreTrafficHook
          PostTraffic: !Ref PostTrafficHook

1. AutoPublishAlias: Creates new version on each deploy and maintains alias
2. DeploymentPreference: Configures how traffic shifts to new version

• Lambda versions
• CodeDeploy application
• CodeDeploy deployment group
• Alias traffic shifting configuration

Without AutoPublishAlias, there's no alias for traffic shifting. Without DeploymentPreference, deployment is immediate (AllAtOnce).

Explanation:

Template validation tools:

• Validates CloudFormation template syntax
• Checks against CloudFormation specification
• Catches errors before deployment
• Limited policy enforcement

# Rules file
AWS::S3::Bucket {
  BucketEncryption EXISTS
  Tags[*].Key == "Environment"
  LoggingConfiguration EXISTS
}

AWS::EC2::SecurityGroup {
  SecurityGroupIngress[*].CidrIp != "0.0.0.0/0"
}

cfn-guard validate -d template.yaml -r rules.guard

# buildspec.yml
phases:
  build:
    commands:
      - cfn-lint template.yaml
      - cfn-guard validate -d template.yaml -r company-rules.guard

Guard is specifically designed for policy-as-code validation against CloudFormation templates.

Explanation:

Load balancer type migration:

• Load balancer type is an immutable environment configuration
• Cannot be changed after environment creation
• Requires environment recreation

1. Clone environment (or create new) with ALB:

eb clone env-with-clb --environment-name env-with-alb \
  --option-settings option-settings.json

1. Test the new environment
2. Swap CNAMEs:

eb swap env-with-clb --destination-name env-with-alb

1. Terminate old environment

1. Save current configuration
2. Modify saved config for ALB
3. Create new environment from modified config
4. Swap and terminate

This provides zero-downtime migration with ALB benefits.

Explanation:

CloudFormation dependency management:

Resources:
  MySecurityGroup:
    Type: AWS::EC2::SecurityGroup
    
  MyInstance:
    Type: AWS::EC2::Instance
    Properties:
      SecurityGroupIds:
        - !Ref MySecurityGroup  # Implicit dependency

Resources:
  MyDatabase:
    Type: AWS::RDS::DBInstance
    
  MyAppServer:
    Type: AWS::EC2::Instance
    DependsOn: MyDatabase  # Explicit dependency
    Properties:
      # No direct reference to database

• Resources don't reference each other
• Order matters for external reasons
• Custom resources that depend on other resources
• Wait for resource to be fully operational (not just created)

• Ref creates both dependency AND passes value
• DependsOn only creates dependency order

Explanation:

StackSet account exclusions:

aws cloudformation update-stack-set \
  --stack-set-name my-stackset \
  --deployment-targets '{
    "OrganizationalUnitIds": ["ou-abc123"],
    "AccountFilterType": "DIFFERENCE",
    "Accounts": ["111111111111", "222222222222"]
  }'

• INTERSECTION: Deploy only to specified accounts within OUs
• DIFFERENCE: Deploy to all accounts in OUs EXCEPT specified accounts
• UNION: Deploy to OU accounts plus additional accounts

1. Exclude management account:

• Target: All accounts in root OU
• Exclude: Management account

1. Exclude sandbox accounts:

• Target: Production OU
• Exclude: Test/sandbox accounts within that OU

This is cleaner than managing individual account lists for large organizations.

Explanation:

ECR authentication for Beanstalk:

1. IAM Policy:

{
  "Effect": "Allow",
  "Action": [
    "ecr:GetAuthorizationToken",
    "ecr:BatchCheckLayerAvailability",
    "ecr:GetDownloadUrlForLayer",
    "ecr:BatchGetImage"
  ],
  "Resource": "*"
}

1. Assign to Beanstalk instance profile:

1. Dockerrun.aws.json:

{
  "AWSEBDockerrunVersion": "1",
  "Image": {
    "Name": "123456789012.dkr.ecr.us-east-1.amazonaws.com/my-app:latest",
    "Update": "true"
  },
  "Authentication": {
    "Bucket": "not-needed-with-instance-profile"
  }
}

• EC2 instances assume instance profile role
• Docker daemon uses instance metadata for ECR authentication
• No credential management required

Never store credentials (Option A) or make repositories public (Option D).

Explanation:

Handling timing dependencies:

Resources:
  S3Endpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      ServiceName: com.amazonaws.region.s3
      
  MyASG:
    Type: AWS::AutoScaling::AutoScalingGroup
    DependsOn: S3Endpoint

#!/bin/bash
MAX_RETRIES=5
for i in $(seq 1 $MAX_RETRIES); do
  aws s3 cp s3://bucket/app.zip /tmp/app.zip && break
  sleep 10
done

MyASG:
  CreationPolicy:
    ResourceSignal:
      Count: !Ref DesiredCapacity
      Timeout: PT15M

• DependsOn for ordering
• Retry logic for transient issues
• CreationPolicy for completion verification

Explanation:

AWS Service Catalog for template sharing:

1. Product: CloudFormation template packaged as deployable product
2. Portfolio: Collection of products
3. Principal: Users/groups who can access portfolio

# Service Catalog Product
AWSTemplateFormatVersion: '2010-09-09'
Resources:
  Portfolio:
    Type: AWS::ServiceCatalog::Portfolio
    Properties:
      DisplayName: "Approved Infrastructure"
      ProviderName: "Platform Team"
      
  Product:
    Type: AWS::ServiceCatalog::CloudFormationProduct
    Properties:
      Name: "VPC Template"
      Owner: "Platform Team"
      ProvisioningArtifactParameters:
        - Name: "v1.0"
          Info:
            LoadTemplateFromURL: "s3://bucket/templates/vpc-v1.0.yaml"

aws servicecatalog create-portfolio-share \
  --portfolio-id port-123 \
  --organization-node Type=ORGANIZATION,Value=o-abc123

• Version control of templates
• Approval workflow for new versions
• Usage tracking and auditing
• Constraints for parameter validation
• Launch role configuration

Explanation:

Beanstalk scheduled scaling:

aws autoscaling put-scheduled-action \
  --auto-scaling-group-name awseb-e-abc123-stack-AWSEBAutoScalingGroup-xyz \
  --scheduled-action-name scale-up-weekdays \
  --recurrence "0 8 * * 1-5" \
  --min-size 5 \
  --max-size 10 \
  --desired-capacity 5

• 0 8 * * 1-5 = 8:00 AM on Monday-Friday

# .ebextensions/scheduled-scaling.config
Resources:
  ScaleUpWeekdays:
    Type: AWS::AutoScaling::ScheduledAction
    Properties:
      AutoScalingGroupName: 
        Ref: AWSEBAutoScalingGroup
      Recurrence: "0 8 * * 1-5"
      MinSize: 5
      MaxSize: 10
      DesiredCapacity: 5

Both approaches use cron expressions with day-of-week (1=Monday through 7=Sunday or 0=Sunday).

Explanation:

DHCP options propagation:

1. DHCP option set is associated with VPC
2. Instances receive options via DHCP lease
3. Lease renewal happens at specific intervals

• New instances immediately get new options
• Existing instances keep old options until lease renewal
• Lease renewal depends on lease duration (typically hours)

# Option 1: Restart instance networking
sudo dhclient -r && sudo dhclient

# Option 2: Stop and start instance
aws ec2 stop-instances --instance-ids i-1234567890abcdef0
aws ec2 start-instances --instance-ids i-1234567890abcdef0

• Successfully updates DHCP option set
• Successfully associates with VPC
• Cannot force instance DHCP renewal

For exam: Understand that DHCP option propagation has delay; may require instance action.

Explanation:

SSL configuration for Beanstalk:

1. Environment → Configuration → Load Balancer
2. Add listener: Port 443, HTTPS
3. Select ACM certificate from dropdown

# .ebextensions/https.config
option_settings:
  aws:elb:listener:443:
    ListenerProtocol: HTTPS
    SSLCertificateId: arn:aws:acm:region:account:certificate/id
    InstancePort: 80
    InstanceProtocol: HTTP

option_settings:
  aws:elbv2:listener:443:
    ListenerEnabled: true
    Protocol: HTTPS
    SSLCertificateArns: arn:aws:acm:region:account:certificate/id
  aws:elbv2:listener:default:
    ListenerEnabled: false  # Disable HTTP if needed

• ACM: Recommended for ALB/NLB, auto-renewal
• IAM: Legacy, required for Classic Load Balancer in some regions

Both console and .ebextensions approaches work; choose based on environment management preference.

Explanation:

Pre-update snapshots:

Resources:
  PreUpdateSnapshot:
    Type: Custom::Snapshot
    Properties:
      ServiceToken: !GetAtt SnapshotFunction.Arn
      ClusterIdentifier: !Ref AuroraCluster
      
  AuroraCluster:
    Type: AWS::RDS::DBCluster
    DependsOn: PreUpdateSnapshot

Lambda creates snapshot before cluster updates proceed.

For guaranteed pre-update snapshots, custom resources or hooks are necessary; built-in policies don't cover this scenario.

Explanation:

Platform version management:

# .ebextensions/managed-updates.config
option_settings:
  aws:elasticbeanstalk:managedactions:
    ManagedActionsEnabled: true
    PreferredStartTime: "Sun:02:00"
  aws:elasticbeanstalk:managedactions:platformupdate:
    UpdateLevel: minor
    InstanceRefreshEnabled: true

• UpdateLevel: patch, minor, or major
• Automatic updates during maintenance window
• Instance refresh ensures all instances updated

def audit_platform_versions():
    eb = boto3.client('elasticbeanstalk')
    
    # Get latest platform versions
    platforms = eb.list_platform_versions(
        Filters=[{'Type': 'PlatformBranchName', 'Values': ['Python 3.9']}]
    )
    latest = platforms['PlatformSummaryList'][0]['PlatformVersion']
    
    # Check all environments
    envs = eb.describe_environments()
    for env in envs['Environments']:
        if env['PlatformArn'] != latest:
            report_outdated(env)

Combine managed updates for automation with auditing for visibility.

Explanation:

Conditional configuration:

Parameters:
  Environment:
    Type: String
    AllowedValues: [dev, staging, production]

Conditions:
  IsProd: !Equals [!Ref Environment, production]

Resources:
  MyBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub "myapp-${Environment}"
      VersioningConfiguration: !If 
        - IsProd
        - Status: Enabled
        - !Ref AWS::NoValue  # Omit property entirely

VersioningConfiguration: !If 
  - IsProd
  - Status: Enabled
  - Status: Suspended

This explicitly sets versioning status in both cases.

Conditions provide single-template solution for environment-specific configurations.

Explanation:

Worker environment SQS configuration:

# Beanstalk configuration
option_settings:
  aws:elasticbeanstalk:sqsd:
    WorkerQueueURL: https://sqs.region.amazonaws.com/123456789/my-queue
    VisibilityTimeout: 1800  # 30 minutes
    HttpPath: /worker
    MimeType: application/json

• VisibilityTimeout: Time message is hidden after delivery (1800 = 30 min)
• HttpConnections: Maximum concurrent connections to worker
• InactivityTimeout: Time to wait for worker response
• RetentionPeriod: How long messages are kept

1. Set VisibilityTimeout > maximum processing time
2. Set InactivityTimeout appropriately
3. Consider implementing heartbeat pattern for very long jobs

Beanstalk worker settings control how the environment interacts with SQS.

Explanation:

Protecting database resources:

Resources:
  Database:
    Type: AWS::RDS::DBInstance
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain

• Retain: Resource survives stack deletion
• Becomes orphaned (must manage separately)

database-stack:
  - RDS instance
  - Exports: DatabaseEndpoint
  
application-stack:
  - EC2 instances
  - ImportValue: DatabaseEndpoint

• Independent lifecycle management
• Different update frequencies
• Better access control
• Cleaner separation of concerns

{
  "Statement": [{
    "Effect": "Deny",
    "Action": ["Update:Replace", "Update:Delete"],
    "Principal": "*",
    "Resource": "LogicalResourceId/Database"
  }]
}

Prevents accidental updates that would replace/delete database.

Explanation:

Debugging CloudFormation macros:

aws cloudformation describe-template-body \
  --stack-name my-stack

aws cloudformation describe-type \
  --type RESOURCE \
  --type-name Custom::MyResource

# Get the processed template from an existing stack
aws cloudformation get-template \
  --stack-name my-stack \
  --template-stage Processed

• Original: Template as submitted
• Processed: Template after macro execution

def handler(event, context):
    logger.info(f"Input fragment: {event['fragment']}")
    processed = transform(event['fragment'])
    logger.info(f"Output fragment: {processed}")
    return {'requestId': event['requestId'], 'status': 'success', 'fragment': processed}

CloudWatch Logs show macro input/output for each execution.

Explanation:

Connection issues during deployment:

1. Instance marked for removal
2. LB stops sending new connections
3. Existing connections continue for draining timeout
4. After timeout, connections forcibly closed

option_settings:
  aws:elb:policies:
    ConnectionDrainingEnabled: true
    ConnectionDrainingTimeout: 300  # Increase from default 20s

If requests take longer than timeout, they're terminated.

1. Stop accepting new work when SIGTERM received
2. Complete in-flight requests
3. Close connections cleanly
4. Exit when done

# Python example
def shutdown_handler(signum, frame):
    global accepting_requests
    accepting_requests = False
    # Wait for current requests to complete
    wait_for_completion()
    sys.exit(0)

signal.signal(signal.SIGTERM, shutdown_handler)

Explanation:

ECS health check configuration:

1. Task starts
2. ALB immediately health checks
3. App isn't ready → health check fails
4. ECS kills task
5. Loop continues

Resources:
  MyService:
    Type: AWS::ECS::Service
    Properties:
      ServiceName: my-service
      TaskDefinition: !Ref TaskDef
      DesiredCount: 10
      HealthCheckGracePeriodSeconds: 120  # Wait 2 minutes before health checking
      LoadBalancers:
        - ContainerName: app
          ContainerPort: 80
          TargetGroupArn: !Ref TargetGroup

• Gives tasks time to start before ECS evaluates health
• Should exceed application startup time
• Only applies when using load balancer

• Target group health check interval and threshold
• Application startup optimization
• Container health checks vs LB health checks

Explanation:

Change set workflow:

# CodePipeline stage configuration
- Name: CreateChangeSet
  Actions:
    - Name: CreateChangeSet
      ActionTypeId:
        Category: Deploy
        Provider: CloudFormation
      Configuration:
        ActionMode: CHANGE_SET_REPLACE
        StackName: my-stack
        ChangeSetName: pipeline-changeset

- Name: ReviewChanges
  Actions:
    - Name: ManualApproval
      ActionTypeId:
        Category: Approval
        Provider: Manual
      Configuration:
        NotificationArn: !Ref NotifyTopic
        CustomData: "Review CloudFormation changes"

- Name: ExecuteChangeSet
  Actions:
    - Name: ExecuteChangeSet
      ActionTypeId:
        Category: Deploy
        Provider: CloudFormation
      Configuration:
        ActionMode: CHANGE_SET_EXECUTE
        StackName: my-stack
        ChangeSetName: pipeline-changeset

1. CHANGE_SET_REPLACE creates change set (no deployment)
2. Manual approval - reviewer checks change set in console
3. CHANGE_SET_EXECUTE applies changes

• Resources to be added, modified, deleted
• Replacement vs in-place updates
• Property changes

Explanation:

Managing complex stack dependencies:

from aws_cdk import Stack, App
from constructs import Construct

class NetworkStack(Stack):
    def __init__(self, scope: Construct, id: str, **kwargs):
        super().__init__(scope, id, **kwargs)
        self.vpc = ec2.Vpc(self, "VPC")

class DatabaseStack(Stack):
    def __init__(self, scope: Construct, id: str, vpc: ec2.Vpc, **kwargs):
        super().__init__(scope, id, **kwargs)
        rds.DatabaseInstance(self, "DB", vpc=vpc)

class ApplicationStack(Stack):
    def __init__(self, scope: Construct, id: str, vpc: ec2.Vpc, **kwargs):
        super().__init__(scope, id, **kwargs)
        # Use VPC from network stack

app = App()
network = NetworkStack(app, "Network")
database = DatabaseStack(app, "Database", vpc=network.vpc)
application = ApplicationStack(app, "Application", vpc=network.vpc)

# CDK handles dependency ordering and cross-stack references
app.synth()

• Automatic dependency detection
• Type-safe cross-stack references
• Synthesizes to CloudFormation
• Deploy in correct order: cdk deploy --all

# deploy.sh
aws cloudformation deploy --stack-name network --template network.yaml
aws cloudformation deploy --stack-name database --template database.yaml
aws cloudformation deploy --stack-name app --template app.yaml

With exports/imports for references. Works but requires manual ordering.

---