A developer authors an AWS SAM template that declares an AWS::Serverless::Function whose handler code lives in a local src directory and whose dependencies are listed in a requirements.txt file. They run sam build, then sam deploy, and need the local code to end up running in Lambda. Which TWO things does the SAM CLI do during this build-and-deploy flow that plain CloudFormation cannot do on its own? (Select TWO.)
- AIt uploads the built code artifact to an Amazon S3 bucket and rewrites the CodeUri to that S3 location before creating the stack. Correct
- BIt expands the AWS::Serverless transform into native CloudFormation resources such as the function, role and event source mappings. Correct
- CIt provisions the Lambda execution environment directly through the Lambda API, bypassing CloudFormation stack creation entirely.
- DIt stores the function source permanently in AWS CodeArtifact and references the package from there at runtime.
- EIt signs the deployment artifact with AWS Signer and enforces code signing on the function automatically.
Why A is correct: sam build installs dependencies and sam deploy packages the artifact, uploads it to S3, and replaces the local CodeUri with the S3 reference CloudFormation needs.
Why B is correct: The SAM transform macro expands shorthand serverless resources into native types like AWS::Lambda::Function and AWS::IAM::Role so CloudFormation can provision them.
Why C is wrong: Tempting because SAM feels like a deployment tool, but sam deploy works through CloudFormation change sets, not direct Lambda API calls.
Why D is wrong: CodeArtifact hosts language packages for builds, not Lambda deployment artifacts; SAM uploads the zipped code to S3, not CodeArtifact.
Why E is wrong: Code signing is an optional Lambda feature you configure explicitly; the standard sam build and sam deploy flow does not sign artifacts by default.