Exam AWS Certified Solutions Architect - Professional SAP-C02 topic 1 question 27 discussion

A and C. API Gateway REST API can invoke DynamoDB directly. https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-overview-developer-experience.html

Option A - This option might work: REST APIs can run over HTTPS and the integration type DynamoDB is possible Option B - This option will not work: HTTP APIs do not support integration types for DynamoDB Option C - This option will work: HTTP APIs support integration with Lambda functions Option D - This option will not work: Lambda@Edge is a function of CloudFront Option E - This option will not work: NLB Target groups can target Lambda functions however NLBs are not a Serverless solution (They are deployed on VPCs).

A. Amazon API Gateway can be configured as a REST API with direct integration to DynamoDB. This is done using API Gateway’s AWS integration type, allowing direct interaction with DynamoDB without needing a Lambda function in between. C. API Gateway HTTP API can be used to route requests to AWS Lambda functions. The Lambda functions can then interact with DynamoDB to retrieve or modify data and return it to the client through the API.

A. Create an Amazon API Gateway REST API. Configure this API with direct integrations to DynamoDB by using API Gateway’s AWS integration type. C. Create an Amazon API Gateway HTTP API. Configure this API with integrations to AWS Lambda functions that return data from the DynamoDB tables.

On the fact of simplicity it looks like BC, but with C there is an issue of Lambda fetching data, question does not indicate fetching, only put. So it looks like AB

A and C

The solutions that meet the requirements of using a serverless architecture to make the data accessible publicly through a simple API over HTTPS and scaling automatically in response to demand are: C AND D

a, c https://medium.com/brlink/rest-api-just-with-apigateway-and-dynamodb-8a9b0cd76b7a

API Gateway REST API can invoke DynamoDB directly.

Sometimes when multiple answers are required, they're supposed to complement each other, but sometimes these have to be just 2 valid but independent solutions... Well API GW with Rest endpoint is a valid solution, since it's had DynamoDB proxy integration lately. We use it in production, and it's a good fit, if you want to have a lot of control and features in your API GW and no lambda functions in between, reason being VTL supports a big set of mutations which is enough to us. On the flip side, since we're forced to use a combination, then CD is the right answer. In terms of simplicity, it is the question, what you consider simple. API GW REST endpoint is considered simple, because it provides caching, api keys, usage plans, rate limiting, authorization, deployment stages etc. out of the box. So the plethora of out-of-the-box features is rather simple than implementing them oneself.

Not E as I think NLB listener rules don't provide the required capability to to forward requests to the appropriate Lambda (you need to have and ALB) Not D as Lambda@Edge is a CloudFront feature A, B and C they all works here however the question requires "a simple API over HTTPS". Both REST APIs and HTTP APIs are RESTful API products. REST APIs support more features than HTTP APIs, while HTTP APIs are designed with minimal features so that they can be offered at a lower price. Thus I would go for B and C

C and D is the correct option 1) C- Need server less architecture so need to use lamda function instead of REST API 2) D - Global accelerator work with lamda edge would be best the option compare to NLB for auto scale up and down. It has static address and fixed entry point if we deply multiple region.

REST API - is not simple and limitaiton around scability. NLB with listener rules can be used to forward request based on specified conditions to appropriate AWS lambda function

lambda can have https endpoints available

I've read similar questions previously, keyword is "simple API". REST API adds more features than HTTP API and is consider "more" complex. So it has to be HTTP just for that reason. You can use API Gateway (HTTP)->dynamodb: https://aws.amazon.com/fr/blogs/compute/using-amazon-api-gateway-as-a-proxy-for-dynamodb/ so B and C

B. Create an Amazon API Gateway HTTP API. Configure this API with direct integrations to DynamoDB by using API Gateway’s AWS integration type. C. Create an Amazon API Gateway HTTP API. Configure this API with integrations to AWS Lambda functions that return data from the DynamoDB tables. Options A, D, and E do not align with the requirements as well: A. Amazon API Gateway REST API with Direct DynamoDB Integration: While REST APIs could work, HTTP APIs are generally more lightweight and cost-effective. Also, direct integration with DynamoDB using REST APIs could be more complex to set up compared to HTTP APIs.

Option C suggests configuring an Amazon API Gateway HTTP API with integrations to AWS Lambda functions that return data from the DynamoDB tables. However, this approach would introduce unnecessary complexity and additional steps since it involves using AWS Lambda as a middle layer to fetch data from DynamoDB