Customer data resides in a PostgreSQL database inside a VPC and must be transformed by AWS Glue into analytics data in S3.
Keep credentials out of code and make the network and JDBC settings reusable across jobs.
Which design is most appropriate?
Define a reusable Glue JDBC connection with the VPC settings and retrieve credentials from Secrets Manager instead of embedding them in the ETL code.
Detailed explanation
The destination, subnet, security group, and JDBC settings are reusable and secrets are kept outside the job code.
The destination, subnet, security group, and JDBC settings are reusable and secrets are kept outside the job code.
This confuses Athena's S3 query boundary with external database connectivity and expands network and credential exposure.
This confuses Athena's S3 query boundary with external database connectivity and expands network and credential exposure.
Hard-coded credentials increase exposure and do not provide a reusable JDBC job connection.
Hard-coded credentials increase exposure and do not provide a reusable JDBC job connection.
An S3 Gateway Endpoint is a private route to S3, not a JDBC connection to a database.
An S3 Gateway Endpoint is a private route to S3, not a JDBC connection to a database.
Check official documentation
Compare the following points with the official documentation.
AWS Glue ConnectionのJDBC、VPC接続、Secrets Manager参照の公式説明を確認する。
Official references
What to confirm
JDBC/ODBC接続設定、Secrets Manager、S3エンドポイント、Athenaの役割を区別できる。
Key points
- JDBC
- Glue Connection
- VPC reachability
- Secrets Manager
Notes
- Environment: AWS公式DEA-C01試験ガイドと各サービスの公式ドキュメントの確認
- Confirm the relevant DEA-C01 Skill and current AWS service documentation.
Foundation review
Connection reuse
Share validated network and driver settings across ETL jobs.
Secret boundary
Retrieve credentials at runtime and prevent them from appearing in code or logs.