DOP-C02 Configuration Management and IaC Practice Question
A company uses AWS CloudFormation to manage its infrastructure. The CloudFormation template includes a custom resource backed by an AWS Lambda function that validates a condition and returns a value. During a stack update, the custom resource fails, and the stack rolls back. The DevOps engineer needs to debug the issue. Which steps should be taken to troubleshoot the custom resource failure?
⚠ Common exam trap
Candidates may expect CloudFormation stack events to provide Lambda function logs, but stack events only show the failure status and, if the custom resource provider returns a reason, that reason; they do not contain the function's stdout/stderr. CloudWatch Logs is the source for the actual execution output.
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
✓
View the Amazon CloudWatch Logs log group for the Lambda function to see the function's output and error messages.
AWS Lambda functions invoked by CloudFormation custom resources automatically send their logs to Amazon CloudWatch Logs. By examining the log group named `/aws/lambda/<function-name>`, the DevOps engineer can view the function's `stdout`, `stderr`, and any `print()` or `console.log()` statements, which will contain the exact error messages or return values that caused the custom resource to fail. This is the most direct and reliable method to debug the failure without modifying the stack or waiting for a new update.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
View the Amazon CloudWatch Logs log group for the Lambda function to see the function's output and error messages.
Why this is correct
Custom resource Lambda functions emit all stdout, stderr, and unhandled exceptions to their CloudWatch Logs log group, typically named /aws/lambda/<function-name>. Inspecting that log stream gives you the exact Python/Node.js stack trace and any print statements from the function, which is the definitive first diagnostic step for a CloudFormation custom resource failure. The CloudFormation event itself will only tell you that the Lambda failed, so this is where the actual error message lives.
- ✗
Update the Lambda function code to include additional logging and then re-execute the stack update.
Why it's wrong here
Modifying the Lambda code to add logging and then re-running the stack update is a blind change: you haven't examined the existing logs, so you don't know whether the failure is due to invalid response data, a missing permission, or a runtime exception. Re-executing with additional instrumentation might reproduce the issue, but it wastes time and can alter the custom resource's behavior, and if the root cause is an IAM or network issue, extra logs won't reveal it. You should first inspect the current CloudWatch Logs stream, not change code speculatively.
- ✗
Check the Amazon S3 bucket where the Lambda function code is stored for any access denied errors.
Why it's wrong here
An S3 access denied error would prevent Lambda from even downloading the deployment package at function creation or invocation time, so the function would never start and would produce no execution logs. If the custom resource function has a log group with entries, then code retrieval already succeeded, and S3 bucket policy issues are not the cause. Additionally, S3 access problems would surface as a CREATE_FAILED with a clear 'Access Denied' message in the CloudFormation stack event, not as a runtime error inside the function.
- ✗
Review the CloudFormation stack events in the AWS Management Console for detailed error messages from the Lambda function.
Why it's wrong here
CloudFormation stack events provide the status of each resource (for example CREATE_FAILED) and a short status reason that often merely says 'Resource creation cancelled' or 'See the details in CloudWatch Logs', but they do not include the Lambda function's stdout, stderr, or stack trace. These events are useful for identifying which resource failed and when, yet they lack the detailed output needed to diagnose a custom resource script's internal error. Therefore, while reviewing stack events is a reasonable triage step, it is not where the detailed Lambda error messages reside.
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.