DEA-C01 Practice Question 50: Glue Secrets Manager Credentials

This is the documented pattern: "We recommend that you use AWS Secrets Manager to supply connection credentials for your data store. Using Secrets Manager this way lets AWS Glue access your secret at runtime for ETL jobs and crawler runs, and helps keep your credentials secure." The secret holds a username/password pair, the Glue connection references it, and the script contains no credentials at all, so rotating the secret needs no code change or redeployment. One prerequisite is easy to miss: "you must grant your IAM role for AWS Glue permission to retrieve secret values. The AWS managed policy AWSGlueServiceRole doesn't include AWS Secrets Manager permissions."

Option B moves the secret from the script into the job definition, where it is still stored and displayed in plain text, visible in the console, in GetJob API responses, and in job run history for anyone with Glue read access. Rotation still means editing the job.

Option C is better than a hard-coded literal but rebuilds a worse Secrets Manager. There is no rotation support, no versioning, no audited GetSecretValue trail tied to a secret, and anyone with read access to the bucket and decrypt permission on the key gets the password.

Option D has the same shortcomings with an additional one: DynamoDB's encryption at rest protects the storage medium, not the value from any principal allowed to read the item, and the table becomes an unaudited credential store the security team does not know about.

Reference: Storing connection credentials in AWS Secrets Manager