A staging CloudFormation deploy for a clerk fee API reports CREATE_COMPLETE, but the first runtime GetItem against DynamoDB fails with AccessDenied. Integration tests catch it before promotion. What does this validate about environment testing?
Select an answer to reveal the explanation.
Short Explanation
Building the house is not the same as unlocking the front door. The stack can finish while the Lambda role still lacks dynamodb:GetItem. Integration tests that call the real path catch that—do not treat CREATE_COMPLETE as permission proof.
Full Explanation
A staging CloudFormation deploy for a clerk fee API that reports CREATE_COMPLETE while the first runtime GetItem against DynamoDB fails with AccessDenied shows that successful stack deploy is not enough; integration tests must exercise runtime IAM authorization paths the application uses. CREATE_COMPLETE proves resources exist, not that the Lambda role can GetItem on the intended table. Municipal environment testing validates runtime permissions before promotion.
Claiming AccessDenied means CloudFormation cannot create IAM roles so the deploy status was wrong fails—roles can create successfully yet lack needed data-plane actions. Skipping integration tests once CloudFormation returns CREATE_COMPLETE fails conceptually by equating provisioning with authorization correctness. Fixing GetItem failures only after the same code is live in production fails by delaying detection until citizen impact.
Exam caveat: least-privilege gaps often appear only on secondary paths (GSI queries, BatchGet, TTL deletes)—test the actions the code actually calls. Operational check: run integration tests that perform the fee API's DynamoDB operations after every staging deploy, fail promotion on AccessDenied, and adjust IAM in the template—not via silent console grants.