試験SAA-C03-JPN トピック1 問題527 スレッド
Amazon SAA-C03-JPNのリアル試験問題集
問題 #: 527
トピック #: 1
問題 #: 527
トピック #: 1
ソリューションアーキテクトがJavaで記述されたAWS Lambda関数を作成しました。ある企業は、このLambda関数を自社アプリケーションの新しいマイクロサービスとして使用します。企業の顧客は、HTTPSエンドポイントを呼び出してマイクロサービスにアクセスできる必要があります。マイクロサービスは、呼び出しの認証にAWS Identity and Access Management(IAM)を使用する必要があります。
これらの要件を満たすソリューションはどれでしょうか？
これらの要件を満たすソリューションはどれでしょうか？
おすすめの解答：B 解答を投票する
Comprehensive and Detailed 250 to 300 words of Explanation (AWS documentation-based, no links):
The requirements are straightforward: expose the Lambda microservice through an HTTPS endpoint and authenticate calls using IAM. Lambda function URLs are a built-in feature that provides a dedicated HTTPS endpoint for a Lambda function without requiring API Gateway, ALB, or CloudFront. When configured with the authentication type AWS_IAM, the endpoint requires requests to be signed with AWS Signature Version
4 and authorized by IAM policies. This directly satisfies the "must use IAM to authenticate calls" requirement with the least architectural complexity.
Option A can also secure an endpoint with IAM, but it proposes using a Lambda authorizer, which is typically used for custom authorizers (JWT/OAuth/Cognito/external identity). For IAM authentication in API Gateway, you generally use IAM authorization on the method, not an authorizer function. Also, API Gateway REST APIs introduce additional service configuration and per-request costs when a simpler managed option exists that meets the requirements.
Options C and D are not appropriate. Lambda@Edge and CloudFront Functions run at CloudFront edge locations with different programming and deployment models; they are designed for CDN request/response manipulation, not as the primary mechanism to expose a regional Lambda microservice endpoint with IAM authentication. CloudFront Functions in particular is for lightweight JavaScript at the edge and does not provide a native "AWS_IAM authentication type" for invoking an origin Lambda as a microservice endpoint.
Therefore, B is the cleanest and most secure fit: a native HTTPS endpoint backed by Lambda, protected with IAM-based SigV4 authentication.
The requirements are straightforward: expose the Lambda microservice through an HTTPS endpoint and authenticate calls using IAM. Lambda function URLs are a built-in feature that provides a dedicated HTTPS endpoint for a Lambda function without requiring API Gateway, ALB, or CloudFront. When configured with the authentication type AWS_IAM, the endpoint requires requests to be signed with AWS Signature Version
4 and authorized by IAM policies. This directly satisfies the "must use IAM to authenticate calls" requirement with the least architectural complexity.
Option A can also secure an endpoint with IAM, but it proposes using a Lambda authorizer, which is typically used for custom authorizers (JWT/OAuth/Cognito/external identity). For IAM authentication in API Gateway, you generally use IAM authorization on the method, not an authorizer function. Also, API Gateway REST APIs introduce additional service configuration and per-request costs when a simpler managed option exists that meets the requirements.
Options C and D are not appropriate. Lambda@Edge and CloudFront Functions run at CloudFront edge locations with different programming and deployment models; they are designed for CDN request/response manipulation, not as the primary mechanism to expose a regional Lambda microservice endpoint with IAM authentication. CloudFront Functions in particular is for lightweight JavaScript at the edge and does not provide a native "AWS_IAM authentication type" for invoking an origin Lambda as a microservice endpoint.
Therefore, B is the cleanest and most secure fit: a native HTTPS endpoint backed by Lambda, protected with IAM-based SigV4 authentication.
木村** 2026-04-23 12:33:24
コメント
他人の解答コメントを賛成するのも、その解答に一票を入れることになります。したがって、すでに同じ意見の投票コメントが存在する場合、新規コメントをする代わりに賛成することもできます。
コメントを通報する
コメント中
今すぐ 新規登録 / ログイン （無料です）。