A new ECS task definition revision for a document OCR service is ready. Where should it be verified before production?
Select an answer to reveal the explanation.
Short Explanation
New task revisions earn their keep in a test cluster under synthetic load—not on election-day production. ECR having the image is necessary, not sufficient. Burning the old revision before you prove the new one is how rollbacks vanish.
Full Explanation
A new ECS task definition revision for a document OCR service should be deployed and verified in a test cluster or service with synthetic load before promoting to production. Verifying the revision under AWS networking, IAM, and scaling conditions catches municipal OCR issues that a laptop docker run will miss. Production should receive only revisions that survived a controlled non-prod service exercise.
Pushing the revision straight to the production service because ECR tags imply production readiness fails—tags do not equal environmental verification. Skipping cluster testing and only docker running on a laptop without AWS task networking fails conceptually by omitting cloud runtime realities. Deleting the previous production revision immediately so rollback is impossible fails as an anti-pattern that removes the safety net.
Exam caveat: synthetic load should resemble deed/document sizes and concurrency without using real restricted court documents in lower environments when policy forbids it. Operational check: deploy the revision to the test service, run synthetic OCR jobs, compare error rates and latency to baseline, then promote the same task definition revision identifier to production.