Exam AWS Certified Solutions Architect - Associate SAA-C03 topic 1 question 184 discussion

To configure a VPC for an existing function: 1. Open the Functions page of the Lambda console. 2. Choose a function. 3. Choose Configuration and then choose VPC. 4. Under VPC, choose Edit. 5. Choose a VPC, subnets, and security groups. <-- **That's why I believe the answer is A**. Note: If your function needs internet access, use network address translation (NAT). Connecting a function to a public subnet doesn't give it internet access or a public IP address.

it is A. C is not correct at all as in the question it metions that the VPC already has connectivity with on-premises

either A or C

C is correect as lambda already in VPC and AWS account already has connection setup with on-premise database in private subnet

B,C,D dont have any logic behind them. A is the most logical answer as you need to connect a function to a VPC. The VPC will be connected to the on-prem database.

Answer A: During Lambda function creation select "Advanced Settings" select "Enable VPC", this will allow you to select VPC, Subnets and SecurityGroup for your Lambda function. This is the way Lambda can get controlled access to resouces in your VPC. Default Lambda Settings: When you create a Lambda function without specifying a VPC, the Lambda function does not get associated with any particular VPC. By default, Lambda functions are not deployed within a VPC and do not have access to resources within a VPC, such as EC2 instances, RDS databases, or Elasticache clusters, unless you explicitly configure the Lambda function to connect to a VPC.

Update the route tables in the VPC to allow the Lambda function to access the on-premises data center through Direct Connect. By updating the route tables in the VPC to allow the Lambda function to access the on-premises data center through Direct Connect, is the most appropriate solution. By updating the route tables, you can specify the route for traffic from the Lambda function to the IP address range of the on-premises data center via the Direct Connect connection. This ensures that the Lambda function can securely communicate with the database in the private subnet of the data center.

Every time I read this question the badly phrased options make no sense at all. I now want to vote for A but it makes no sense. Question says: All non-VPC traffic routes to the virtual private gateway So Lambda is technically a non VPC traffic too. This means it already goes through the VPGW but we don't know what it connects. Assuming it connect the data-centre to AWS then A makes sense. BUT all this is based on different interpretation now for me.

The wording is strange because technically, the Lambda function does not "run in the VPC", rather it is connected to the VPC, but otherwise A is what relevant documentation says - connect the Lambda function to the VPN and allow traffic in the security group. Not B, we have Direct Connect, no need for VPN. Not C, route is already in place. And route alone does not help - the "route tables in the VPC" are completely irrelevant as long as we don't connect the Lambda function to the VPC. Not D, an "Elastic IP address" is always connected to an "elastic network interface", such is created automatically with A.

The question and options are very badly worded so it makes C a possible candidate (unconvincingly though!). B: VPN is not needed as Direct Connect is already there D: Irrelevant A is too generic (appropriate security group for what?) Lambda has fixed VPC or ENI C is logically relevant

A says "configure the Lambda function to RUN IN the VPC", but "a Lambda function ALWAYS runs inside a VPC owned by the Lambda service" (https://docs.aws.amazon.com/lambda/latest/dg/foundation-networking.html). "You can configure a Lambda function to CONNECT TO private subnets in a virtual private cloud (VPC) in your AWS account", but "connect to" is not the same as "run in" (https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html). Otherwise A would make sense (you CAN assign a security group to the Elastic Network Interface that Lambda uses to connect to your VPC).

it's not A: A Lambda function always runs inside a VPC owned by the Lambda service. https://docs.aws.amazon.com/lambda/latest/dg/foundation-networking.html

The answer is C. The question is to allow lambda to access the database running in private subnet in the corporate data center. The only connectivity with the data center is Direct connect.

Answer C is correct: https://repost.aws/questions/QUSaj1a6jBQ92Kp56klbZFNw/aws-lambda-to-on-premise-via-direct-connect-and-aws-privatelink

Go to the Lambda console. Click the Functions tab. Select the Lambda function that you want to configure. Click the Configuration tab. In the Network section, select the VPC that you want the function to run in. In the Security groups section, select the security group that you want to allow the function to access the database subnet. Click the Save button.

Correct answer is A Lambda is available in the Region by default.. if you want to connect it to your private subnet or to on prem data center you must configure your Lambda with vpc.. C is wrong because there is no help adding routes to VPC without configuring your lambda to vpc.

Option A: Configure the Lambda function to run in the VPC with the appropriate security group. This allows the Lambda function to access the database in the private subnet of the company's data center. By running the Lambda function in the VPC, it can communicate with resources in the private subnet securely. Option B is incorrect because setting up a VPN connection and routing the traffic from the Lambda function through the VPN would add unnecessary complexity and overhead. Option C is incorrect because updating the route tables in the VPC to allow access to the on-premises data center through Direct Connect would affect the entire VPC's routing, potentially exposing other resources to the on-premises network. Option D is incorrect because creating an Elastic IP address and sending traffic through it without an elastic network interface is not a valid configuration for accessing resources in a private subnet.