Day 5 - Week 7 Review: All the Pieces of Serverless CI/CD in One Picture

A SaaS team runs 200 Lambda functions with Serverless Framework v3, and the annual cost of the v4 commercial license is a burden. What is the most reasonable migration path?

• AMove to Terraform - rewrite everything in HCL, discard all existing CFN StackSets/drift governance assets, and build new tfstate locking infrastructure (S3+DynamoDB)
• BMove to SAM or CDK - both are Apache 2.0 OSS and keep CFN governance (StackSets, drift)
• CPin to v3 permanently - avoids the upgrade cost, but the end of security patches and new runtime support accumulates long-term operational risk
• DDevelop an in-house IaC tool - no license cost, but you must maintain the entire synthesis, deployment, and rollback engine yourself

You want to bring the P99 latency of a Java Spring Boot Lambda (1GB memory, 80MB package, 8-second init) under 1 second, while also minimizing cost. What is the most effective combination?

• AKeep 100 Provisioned Concurrency always on - cold start becomes 0, but active-time billing runs 24 hours a day, which violates the cost-minimization requirement
• BEnable SnapStart + reinitialize SecureRandom in the Runtime Hook (afterRestore) → reduced to 300-500ms, free of charge
• CRewrite Java entirely in Node.js - init gets faster, but you give up the Spring ecosystem and take on months of refactoring + regression risk
• DSet Reserved Concurrency 100 - it only guarantees a concurrency limit; the 8-second init itself stays the same, so P99 latency does not improve

You must transform and aggregate 50 million JSON objects (average 50KB) in an S3 data lake every day. A 1% failure rate is tolerable, and operational burden must be minimal. What is the most suitable pattern?

• ARun a Spark on EMR cluster permanently - throughput is sufficient, but the operational burden of cluster provisioning, tuning, and patching is large, and the fixed cost is excessive for a daily batch
• BStep Functions Distributed Map + ItemReader: S3 listObjectsV2 + ProcessorConfig: DISTRIBUTED/EXPRESS + ToleratedFailurePercentage: 1
• CInvoke Lambda directly 50 million times, once per object - you would have to implement concurrency limits, throttling, partial-failure tracking, and retry orchestration entirely yourself
• DDiscover the schema with a Glue Crawler, then process - a Crawler is a tool that generates catalog metadata, so it is unsuitable for transforming and aggregating 50 million objects

An API Gateway REST API points to the Lambda Alias live, but every code change triggers an API redeployment, making operations cumbersome. What is the cleanest configuration?

• AStage Variable lambdaAlias=live + ${stageVariables.lambdaAlias} in the Integration URI + add-permission --qualifier live
• BCreate a new API Gateway for every deployment
• CSwitch to a Lambda Function URL
• DAdd CloudFront

A team passed all integration tests with sam local invoke and then deployed to production. Lambda was throttled immediately and API Gateway returned 5xx after a 30-second timeout. What is the most likely cause?

• AA logic bug in the Lambda handler code - if all integration tests passed locally, the same code being throttled immediately only in production cannot be explained by a code bug
• BCreating the ENI when connecting to RDS Proxy inside a VPC takes 8-10 seconds. Locally it runs on the host network, so this latency is not emulated
• CMissing execution IAM Role - without permissions it would fail immediately with AccessDenied, not lead to throttling and then a 30-second timeout
• DAPI Gateway integration misconfiguration - if the mapping were wrong, it would most likely have surfaced first at the local sam local invoke stage

You must include an ML model (2.5GB) in a Lambda zip package. It exceeds the zip limit. What is the most suitable packaging method?

• ASplit into 4 Lambda Layers (not possible, since the limit per Layer is 250MB)
• BLambda Container Image (10GB limit) + your own ECR repository + DockerImageFunction
• CDownload from S3 at runtime every time (10+ seconds of cold start)
• DMount EFS (operationally complex)

In a CodePipeline sequential deployment us-east-1 → eu-west-1 → ap-northeast-2, if an alarm fires at the EUW1 stage, USE1 and EUW1 must be rolled back in reverse order. What is the most suitable configuration?

• A3 CFN Deploy Actions, one per Region + Manual Approval, with an operator manually rolling back USE1 and EUW1 in reverse order from the console when an alarm fires - human intervention violates the RTO
• BStep Functions Action + ASL that accumulates deploymentId in each Region's ResultPath + Choice for the alarm check + Catch for automatic reverse RollbackEUW1 → RollbackUSE1
• CImplement 3-Region deployment, alarm checking, and reverse rollback logic all inline in a single Lambda - branching, retries, and reverse compensating transactions get tangled in code, making debugging and observability impossible
• DSplit into 3 independent Pipelines, one per Region - each pipeline is unaware of the others, so it cannot express sequential cross-Region dependency or reverse rollback of USE1 when EUW1 fails

For a production deployment there is a 3-stage approval: security team → DevOps team → automatic deployment. If there is no response within 7 days at each stage it is automatically canceled, and notification is through a Slack interactive message. What is the most suitable workflow engine and pattern?

• AChain 3 CodePipeline ManualApprovalActions for the security team, DevOps, and deployment stages - approval works, but the 7-day auto-cancel timer and the authenticated callback flow for Slack interactive messages must be implemented separately
• BStandard Step Functions + .waitForTaskToken 3 times + SNS→Slack→Lambda (SendTaskSuccess) + TimeoutSeconds: 604800
• CExpress Step Functions + StartSyncExecution handling the 3-stage approval - Express does not support TaskToken and has a 5-minute maximum execution, so waiting 7 days is impossible
• DEventBridge Scheduler triggering the approval stages by cron - it is a periodic execution tool, so it cannot express waiting for human approval, callbacks, or reverse branching

A team is using sam sync --watch in the production environment. A few days later the next regular sam deploy overwrote all the hotswap changes. What is the most accurate explanation of the cause?

• Asam sync patches code directly with the update-function-code API → the CFN stack state and reality diverge (drift) → the next sam deploy overwrites the changes based on the CFN state, so the hotswap disappears
• BA runtime bug in the Lambda function code itself invalidated the hotswap changes - a code bug has no causal relationship with a regular deployment overwriting changes
• CA Region mismatch between the sync target and the deploy target applied it to a different function - in a workflow using the same profile and stack there is no structural reason for the Regions to diverge
• DConflicts between multiple Lambda Layer versions rolled the code back - Layer version conflicts only cause deployment failures; they do not silently revert hotswap changes

A company manages 1,500 Lambda functions with CDK. Each team keeps writing similar function patterns (Lambda + DynamoDB + API Gateway + IAM grant + X-Ray + Powertools) over and over. How do you ensure operational standardization and reusability?

• AHave all teams share and use only SAM Policy Templates - IAM policy boilerplate shrinks, but there is no reusable unit that abstracts the whole Lambda+Dynamo+API+X-Ray pattern, so the repeated writing remains
• BWrite an in-house L3 Construct library - publish a Construct such as StandardApiFunction that abstracts the standard pattern (security, tagging, logging, tracing)
• CPut CloudFormation YAML templates in a shared folder and copy them - copy-paste based, so patterns drift, and when the standard changes you must fix 1,500 places one by one
• DConsolidate the 1,500 function codebases into a single monorepo - it only gathers code in one place without abstraction and just increases coupling between teams

A team runs production with CDK Pipelines and selfMutation: true enabled. One day they pushed a wrong pipeline definition and deployed a pipeline that broke self-mutation. The next execution started with the broken pipeline and cannot recover normally. What is the most appropriate prevention and recovery strategy?

• APermanently disable selfMutation - prevents broken-pipeline incidents, but gives up the core value of GitOps "the pipeline is code too" automatic updating entirely
• BMaintain Break-glass IAM permissions + manually roll back the pipeline definition from the console + validate in advance with cdk diff on feature branches + separated per-Stage testing
• CWait for recovery through an AWS Support case alone - depends on external response time so the RTO cannot be controlled, and it does not prevent self-mutation from recurring
• DDelete and recreate the Pipeline every time an incident occurs - it recovers, but bootstrap, permissions, and artifacts are reset each time, so cost, downtime, and human error balloon

A payment company designs its payment-processing workflow as follows: validation (50ms) → authentication (100ms) → charge (150ms) → recording (50ms). A synchronous response through API Gateway is required, at 500 calls per second. What is the most suitable workflow engine and invocation pattern?

• AImplement all 4 stages inline in a single Lambda
• BExpress Step Functions + StartSyncExecution + API Gateway AWS service integration (target arn:aws:apigateway:...:states:action/StartSyncExecution)
• CStandard Step Functions + StartExecution + result polling
• DStep Functions is unsuitable - inline Lambda is always faster