A nightly batch reconciler with no human operator must call an internal municipal fees API that expects OAuth tokens. Which approach is appropriate?
Select an answer to reveal the explanation.
Short Explanation
Batch jobs are robots—they need client-credentials or IAM, not a human login page. Do not steal a council member’s password for the cron. Machine-to-machine auth is the right badge for a reconciler.
Full Explanation
A nightly batch reconciler with no human operator should obtain access via machine-to-machine OAuth client credentials—or IAM service identity/SigV4 when calling AWS APIs—rather than interactive user login. Client credentials give the batch a rotatable service identity suitable for unattended calls to an internal municipal fees API without hijacking a person’s password, MFA device, or refresh token.
Hard-coding a council member’s Cognito password into the batch job couples a human account to automation and breaks when MFA or password rotation intervenes. Opening the fees API with no authentication because the batch runs inside the VPC ignores defense in depth if any path reaches the API. Emailing a one-time SMS code to an empty mailbox each night is not an automation strategy.
Exam caveat: store client secrets in Secrets Manager or SSM Parameter Store, rotate them, and scope the OAuth client to the fees API audience only. Operational check: run the batch with client-credentials token acquisition, call the fees API successfully, rotate the client secret, and confirm the old secret fails while the new secret succeeds with no human login steps in the job. For municipal workloads, document the chosen pattern in the runbook so the next on-call engineer applies the same control instead of inventing a weaker shortcut under pressure.