← DOP-C02·Amazon Web Services

DOP-C02 SDLC Automation Practice Question

Exhibit

Refer to the exhibit.

```
Resources:
  MyLambdaFunction:
    Type: AWS::Lambda::Function
    Properties:
      Code:
        S3Bucket: my-lambda-bucket
        S3Key: my-function.zip
      Handler: index.handler
      Role: !GetAtt LambdaExecutionRole.Arn
      Runtime: python3.9
  MyLambdaVersion:
    Type: AWS::Lambda::Version
    Properties:
      FunctionName: !Ref MyLambdaFunction
  MyAlias:
    Type: AWS::Lambda::Alias
    Properties:
      FunctionName: !Ref MyLambdaFunction
      FunctionVersion: !Ref MyLambdaVersion
      Name: prod
  LambdaExecutionRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: lambda.amazonaws.com
            Action: sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
```

A DevOps engineer creates a CloudFormation stack with the above template. After creation, they want to update the Lambda function code by uploading a new zip file to the S3 bucket and updating the S3Key property. However, the stack update fails because the Lambda function is published as a version and the alias points to that version. What is the most likely reason for the update failure?

⚠ Common exam trap

Test-takers frequently assume CloudFormation can update any resource, but they overlook the immutable nature of Lambda versions, which causes the update to fail even when the alias is present.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The AWS::Lambda::Version resource is immutable and cannot be updated.

The AWS::Lambda::Version resource is immutable by design; once created, it cannot be updated or replaced. When a CloudFormation stack includes a Lambda version and an alias pointing to that version, any attempt to update the function code (e.g., by changing the S3Key property) triggers an update to the AWS::Lambda::Version resource, which CloudFormation cannot perform because versions are immutable. This causes the stack update to fail.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
The AWS::Lambda::Version resource is immutable and cannot be updated.
Why this is correct
The AWS::Lambda::Version resource is immutable; once a Lambda version is published, its code and configuration are fixed and cannot be modified in place. CloudFormation therefore rejects any update attempt that alters existing AWS::Lambda::Version properties, reporting that the resource cannot be updated. To change the version, you must create a new version (e.g., by changing the logical ID or using SAM's AutoPublishAlias) and then redirect the alias. This is exactly why the stack update fails.
✗
The alias must be deleted before updating the function code.
Why it's wrong here
Deleting the alias is neither required nor sufficient to fix this failure. An AWS::Lambda::Alias is a mutable pointer to a function version, and CloudFormation can freely update the alias's Version property during stack updates. The alias does not lock the function code or prevent the creation of a new version. The underlying blocker is the immutable AWS::Lambda::Version resource, not the alias.
✗
The IAM role does not have permission to update the function.
Why it's wrong here
The IAM role attached to the Lambda function controls what the function can do at runtime, such as accessing other AWS services. CloudFormation stack updates are executed with the caller's IAM credentials, not the Lambda execution role's permissions. Nothing in the scenario suggests the caller lacks lambda:UpdateFunctionCode or cloudformation:UpdateStack privileges. Therefore, permission on the function's execution role is not the reason for the error.
✗
The function code cannot be updated because the S3 bucket is in a different region.
Why it's wrong here
There is no evidence in the scenario that the S3 bucket is in a different region, and that is not a typical cause for this CloudFormation error. Even if the S3 bucket were in another region, AWS Lambda requires the source code bucket to be in the same region (unless using cross-region replication), and CloudFormation would surface an 'S3 bucket in different region' validation error, not an 'unable to update' error. The actual failure is triggered by the immutable AWS::Lambda::Version resource.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

DOP-C02 SDLC Automation Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question