Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For DVA-C02 candidates, the confusion often lies in why CloudFormation reports a successful API update, yet new API methods return 404 errors. In production, this boils down to knowing exactly how API Gateway deployments work and the role of explicit deployment steps to expose new resources/methods to stages. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
ZenTech Solutions maintains a serverless web application with an Amazon API Gateway REST API frontend. The API and its resources are deployed using AWS CloudFormation. The deployment pipeline is managed via AWS CodePipeline, which automatically deploys changes using CloudFormation updates.
Initially, the CloudFormation template defines the API with various resources and methods, successfully deployed and reachable via the configured stage URL.
Recently, the development team updated the CloudFormation template to add a new resource path and additional HTTP methods under this resource. After updating the CloudFormation stack and seeing the UPDATE_COMPLETE status, they notice that invoking the new methods returns HTTP 404 (Not Found) errors, even though the stack update was successful.
The Requirement: #
Identify the necessary step to ensure the newly added API Gateway resources and methods become accessible after the CloudFormation stack update.
The Options #
- A) Specify the disable-rollback option during the update-stack operation.
- B) Unset the CloudFormation stack failure options.
- C) Add an AWS CodeBuild stage to CodePipeline to run the
aws apigateway create-deploymentAWS CLI command. - D) Add an action to CodePipeline to run the
aws cloudfront create-invalidationAWS CLI command.
Google adsense #
leave a comment:
Correct Answer #
C
Quick Insight: The Developer Imperative #
- For Developers: API Gateway requires an explicit deployment to the stage to make new methods active. CloudFormation updates resources and configuration, but unless a new
AWS::ApiGateway::Deploymentresource is triggered (or deployment made via CLI/API), the stage remains linked to the old API definition, resulting in 404 errors on new paths.
Content Locked: The Expert Analysis #
You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?
The Expert’s Analysis #
Correct Answer #
Option C
The Winning Logic #
- In AWS API Gateway, a REST API deployment resource (
AWS::ApiGateway::Deployment) represents a snapshot of the API configuration at a point in time. - The associated
Stageresource points to a specificDeployment. - Updating or adding resources/methods in the CloudFormation template creates new API configuration, but unless a new
Deploymentis created and associated with theStage, the stage URL serves the last deployed snapshot. - CloudFormation does create the deployment resource, but if its logical ID is unchanged, CloudFormation considers the deployment unchanged and does not create a new deployment (so the stage remains linked to the old snapshot).
- Therefore, a manual or pipeline-executed call to
aws apigateway create-deployment(or updating the deployment resource to force new deploy) is needed to update the stage with the latest API changes.
The Trap (Distractor Analysis): #
-
Option A: disable-rollback
Changing rollback settings affects error handling on failures. It does not influence API Gateway deployment behavior or 404 issues. -
Option B: Unset CloudFormation stack failure options
This is unrelated to deployment updates or API Gateway method availability. -
Option D: CloudFront invalidation
CloudFront invalidations clear cache in a CDN, but API Gateway stage calls are routed directly and not cached via CloudFront by default. This does not fix missing method 404 errors.
The Technical Blueprint #
# CLI command to create a new deployment explicitly after API changes
aws apigateway create-deployment \
--rest-api-id <rest-api-id> \
--stage-name <stage-name> \
--description "Redeploy API after adding new resources"
The Comparative Analysis #
| Option | API Complexity | Performance Impact | Use Case |
|---|---|---|---|
| A | None (rollback flag) | None | Error handling, unrelated to deployment |
| B | None (stack failure settings) | None | Unrelated to API behavior |
| C | Medium (explicit deployment API call) | Low to medium | Proper approach to update deployed API stage |
| D | Low (CloudFront invalidation) | None for API Gateway | Used for static content caching layers only |
Real-World Application (Practitioner Insight) #
Exam Rule #
For the exam, always remember: Updating API Gateway methods or resources requires a fresh deployment to the stage.
Real World #
In production pipelines, teams leverage CloudFormation resource logical ID changes (e.g., append timestamp) or separate deploy commands to trigger new deployments. Without this, new API capabilities remain invisible, causing confusion and troubleshooting delays.
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.