DOP-C02 SDLC Automation Practice Question
A DevOps engineer is troubleshooting a failed AWS CloudFormation stack update. The stack contains an AWS::Lambda::Function resource. The update failed with the error 'Resource creation cancelled' after a timeout. The engineer wants to view the logs from the Lambda function during the stack update to diagnose the issue. What should the engineer do?
⚠ Common exam trap
A common mix-up: candidates confuse CloudFormation stack events (which show resource-level status) with the actual application logs from the Lambda function, leading them to choose Option D instead of recognizing that CloudWatch Logs is the correct source for debugging function execution failures.
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
✓
Access the CloudWatch Logs log group for the Lambda function
AWS Lambda automatically sends function execution logs to Amazon CloudWatch Logs. When a Lambda function is invoked during a CloudFormation stack update (e.g., via a custom resource or a function that runs as part of the update), all stdout, stderr, and logging statements are captured in a log group named /aws/lambda/<function-name>. Accessing this log group allows the engineer to view detailed error messages, stack traces, or timeout-related output that caused the 'Resource creation cancelled' failure.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use AWS CodeBuild to build and test the function locally
Why it's wrong here
AWS CodeBuild is a managed continuous integration service that compiles, tests, and produces build artifacts; it does not execute or inspect a deployed Lambda function. Running a build or test in CodeBuild validates code syntax and unit tests, but it cannot surface runtime errors that occurred during the CloudFormation stack update, because the invoked Lambda runs inside AWS Lambda and its output is captured by CloudWatch Logs, not by CodeBuild.
- ✗
Enable detailed CloudFormation logging in the stack template
Why it's wrong here
CloudFormation does not have a 'detailed logging' option that captures Lambda function output; templates only declare the desired infrastructure state, and the service records resource lifecycle events in stack metadata. While you can enable CloudTrail for detailed API activity, there is no setting in the stack template to stream or store the function's stdout, stderr, or exception traces. Runtime logs are never written back to CloudFormation—they reside only in the Lambda function's CloudWatch Logs log group.
- ✓
Access the CloudWatch Logs log group for the Lambda function
Why this is correct
AWS Lambda automatically writes all execution logs—including output from print() statements, exception stack traces, and custom log messages—to a dedicated CloudWatch Logs log group named /aws/lambda/<function-name>. When the stack update fails, the Lambda function's runtime error is recorded as a log event, which you can view in the CloudWatch Logs console to pinpoint the root cause. Be sure to check the log stream that matches the exact timestamp of the failed update, and remember that logs are retained based on the log group's retention policy.
- ✗
Review the CloudFormation stack events in the AWS Management Console
Why it's wrong here
The CloudFormation stack events view in the console displays lifecycle status changes for each resource, such as UPDATE_IN_PROGRESS, UPDATE_COMPLETE, or UPDATE_FAILED, along with a brief service-level status message like 'Package body could not be read'. However, it does not show the runtime output printed by your Lambda function; if a custom-resource handler calls an API that fails, the stack event only indicates the resource failed, without the exception details or error message. Stack events are designed for infrastructure tracking, not code debugging, so the actual function logs must be retrieved from CloudWatch Logs.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
About these practice questions
One of 1,298 original DOP-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.