Page 4

1. QUESTION

A developer uses AWS SAM templates to deploy a serverless application. He needs to embed the application from the AWS Serverless Application Repository or from an S3 bucket as a nested application.

Which of the following resource type is the most SUITABLE one that the developer should use?

• AWS::Serverless::LayerVersion

• AWS::Serverless::Application

• AWS::Serverless::Api

• AWS::Serverless::Function

Incorrect

A serverless application can include one or more nested applications. You can deploy a nested application as a stand-alone artifact or as a component of a larger application.

As serverless architectures grow, common patterns emerge in which the same components are defined in multiple application templates. You can now separate out common patterns as dedicated applications, and then nest them as part of new or existing application templates. With nested applications, you can stay more focused on the business logic that’s unique to your application.

To define a nested application in your serverless application, use the AWS::Serverless::Application resource type.

AWS::Serverless::Function is incorrect because this resource type describes configuration information for creating a Lambda function. You can describe any event source that you want to attach to the Lambda function—such as Amazon S3, Amazon DynamoDB Streams, and Amazon Kinesis Data Streams.

AWS::Serverless::LayerVersion is incorrect because this resource type creates a Lambda layer version (LayerVersion) that contains library or runtime code that’s needed by a Lambda function. When a serverless layer version is transformed, AWS SAM also transforms the logical ID of the resource so that old layer versions aren’t automatically deleted by AWS CloudFormation when the resource is updated.

AWS::Serverless::Api is incorrect because this resource type describes an API Gateway resource. It’s useful for advanced use cases where you want full control and flexibility when you configure your APIs. For most scenarios, it is recommended that you create APIs by specifying this resource type as an event source of your AWS::Serverless::Function resource.

References:

https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-template.html#serverless-sam-template-application

https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-template-nested-applications.html

2. QUESTION

A developer has an application that uses a Lambda function to process data from an Aurora MySQL DB Instance in a Virtual Private Cloud (VPC). The database throws a MySQL: ERROR 1040: Too many connections error whenever there is a surge in incoming traffic.

Which is the most suitable solution for resolving the issue?

• Increase the allocated memory of your function.

• Increase the value of the max_connections parameter of the Aurora MySQL DB Instance.

• Increase the concurrency limit of the Lambda function

• Provision an RDS Proxy between the Lambda function and the RDS database instance

Incorrect

If a “Too Many Connections” error happens to a client connecting to a MySQL database, it means all available connections are in use by other clients. Opening a connection consumes resources on the database server. Since Lambda functions can scale to tens of thousands of concurrent connections, your database needs more resources to open and maintain connections instead of executing queries. The maximum number of connections a database can support is largely determined by the amount of memory allocated to it. Upgrading to a database instance with higher memory is a straightforward way of solving the problem. Another approach would be to maintain a connection pool that clients can reuse. This is where RDS Proxy comes in.

RDS Proxy helps you manage a large number of connections from Lambda to an RDS database by establishing a warm connection pool to the database. Your Lambda functions interact with RDS Proxy instead of your database instance. It handles the connection pooling necessary for scaling many simultaneous connections created by concurrent Lambda functions. This allows your Lambda applications to reuse existing connections, rather than creating new connections for every function invocation.

Thus, the correct answer is: Provision an RDS Proxy between the Lambda function and RDS database instance.

The option that says: Increase the concurrency limit of the Lambda function is incorrect. The concurrency limit refers to the maximum requests AWS Lambda can handle simultaneously. Increasing the limit will allow for more requests to open a database connection, which could potentially worsen the problem.

The option that says: Increase the value of the max_connections parameter of the Aurora MySQL DB Instance is incorrect. Although this may be a valid solution, it is not the most efficient since it simply increases the maximum number of connections that can be made to the database instance. Moreover, increasing the maximum number of connections alone, without considering the database size, may lead to other issues, such as slow response times, timeouts, and even crashes.

The option that says: Increase the allocated memory of your function is incorrect. Increasing the Lambda function’s memory can improve its performance, but it may not necessarily solve the underlying issue of the ‘too many connections’ error. This error is typically caused by a limit on the maximum number of connections the database can handle, so solutions that address the database’s connection management, such as creating a connection pool using RDS Proxy, are more likely to be effective.

References:

https://aws.amazon.com/rds/proxy/

https://aws.amazon.com/blogs/compute/using-amazon-rds-proxy-with-aws-lambda/

Check out this Amazon RDS Cheat Sheet:

https://tutorialsdojo.com/amazon-relational-database-service-amazon-rds/

3. QUESTION

An application hosted in an Auto Scaling group of On-Demand EC2 instances is used to process data polled from an SQS queue and the generated output is stored in an S3 bucket. To improve security, you were tasked to ensure that all objects in the S3 bucket are encrypted at rest using server-side encryption with AWS KMS–Managed Keys (SSE-KMS).

Which of the following is required to properly implement this requirement?

• Add a bucket policy which denies any s3:PutObject action unless the request includes the x-amz-server-side-encryption header.

• Add a bucket policy which denies any s3:PostObject action unless the request includes the x-amz-server-side-encryption-aws-kms-key-id header.

• Add a bucket policy which denies any s3:PostObject action unless the request includes the x-amz-server-side-encryption header.

• Add a bucket policy which denies any s3:PutObject action unless the request includes the x-amz-server-side-encryption-aws-kms-key-id header.

Incorrect

Server-side encryption is about protecting data at rest. AWS Key Management Service (AWS KMS) is a service that combines secure, highly available hardware and software to provide a key management system scaled for the cloud. AWS KMS uses customer master keys (CMKs) to encrypt your Amazon S3 objects. You use AWS KMS via the AWS Management Console or AWS KMS APIs to centrally create encryption keys, define the policies that control how keys can be used, and audit key usage to prove they are being used correctly. You can use these keys to protect your data in Amazon S3 buckets.

The first time you add an SSE-KMS–encrypted object to a bucket in a region, a default CMK is created for you automatically. This key is used for SSE-KMS encryption unless you select a CMK that you created separately using AWS Key Management Service. Creating your own CMK gives you more flexibility, including the ability to create, rotate, disable, and define access controls, and to audit the encryption keys used to protect your data.

Amazon S3 supports bucket policies that you can use if you require server-side encryption for all objects that are stored in your bucket. For example, you can set a bucket policy that denies permission to upload an object (s3:PutObject) to everyone if the request does not include the x-amz-server-side-encryption header requesting server-side encryption with SSE-KMS.

When you upload an object, you can specify the KMS key using the x-amz-server-side-encryption-aws-kms-key-id header which you can use to require a specific KMS key for object encryption. If the header is not present in the request, Amazon S3 assumes the default KMS key. Regardless, the KMS key ID that Amazon S3 uses for object encryption must match the KMS key ID in the policy, otherwise Amazon S3 denies the request.

Therefore, the correct answer is: Add a bucket policy which denies any s3:PutObject action unless the request includes the x-amz-server-side-encryption header.

The option that says: Adding a bucket policy which denies any s3:PutObject action unless the request includes the x-amz-server-side-encryption-aws-kms-key-id header is incorrect because you have to use the x-amz-server-side-encryption header instead.

The option that says: Adding a bucket policy which denies any s3:PostObject action unless the request includes the x-amz-server-side-encryption header is incorrect because you have to deny s3:PutObject and not the s3:PostObject action.

The option that says: Adding a bucket policy which denies any s3:PostObject action unless the request includes the x-amz-server-side-encryption-aws-kms-key-id header is incorrect because you have to use the x-amz-server-side-encryption header instead. Moreover, you have to deny s3:PutObject and not the s3:PostObject action.

References:

https://docs.aws.amazon.com/AmazonS3/latest/dev/serv-side-encryption.html

https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingKMSEncryption.html

Check out this Amazon S3 Cheat Sheet:

https://tutorialsdojo.com/amazon-s3/

4. QUESTION

You are developing a Lambda function which processes event notifications from Amazon S3. It is expected that the function will have:

• 50 requests per second

• 100 seconds to complete each request

What should you do to prevent any issues when the function has been deployed and becomes operational?

• Implement exponential backoff in your application.

• No additional action needed since Lambda will automatically scale based on the incoming requests.

• Increase the concurrency limit of the function.

• Request for AWS to increase the limit of your concurrent executions.

Incorrect

Concurrent executions refers to the number of executions of your function code that are happening at any given time. You can estimate the concurrent execution count, but the concurrent execution count will differ depending on whether or not your Lambda function is processing events from a poll-based event source.

If you create a Lambda function to process events from event sources that aren’t poll-based (for example, Lambda can process every event from other sources, like Amazon S3 or API Gateway), each published event is a unit of work, in parallel, up to your account limits. Therefore, the number of invocations these event sources make influences the concurrency.

You can use this formula to estimate the capacity used by your function:

concurrent executions = (invocations per second) x (average execution duration in seconds)

For example, consider a Lambda function that processes Amazon S3 events. Suppose that the Lambda function takes on average three seconds and Amazon S3 publishes 10 events per second. Then, you will have 30 concurrent executions of your Lambda function. See the calculation shown below to visualize the process:

= (10 events per second) x (3 seconds average execution duration) = 30 concurrent executions

In this scenario, it is expected that the Lambda function takes an average of 100 seconds for every execution with 50 requests per second. Using the formula above, the function will have 5,000 concurrent executions.

= (50 events per second) x (100 seconds average execution duration) = 5,000 concurrent executions

AWS Lambda dynamically scales function execution in response to increased traffic, up to your concurrency limit. Under sustained load, your function’s concurrency bursts to an initial level between 500 and 3000 concurrent executions that varies per region. After the initial burst, the function’s capacity increases by an additional 500 concurrent executions each minute until either the load is accommodated, or the total concurrency of all functions in the region hits the limit.

By default, AWS Lambda limits the total concurrent executions across all functions within a given region to 1000. This limit can be raised by requesting for AWS to increase the limit of the concurrent executions of your account.

Since the expected concurrent executions of the Lambda function will exceed the default concurrency limit, the best thing to do here is to request for AWS to increase the limit of your concurrent executions.

Choosing to do no additional action since Lambda will automatically scale based on the incoming requests is incorrect because the dynamic scaling of AWS Lambda has its limits. Because the value of the expected concurrency executions has exceeded the default limit, it is best to contact AWS to increase the concurrent executions of your account to prevent any throttling issues when the function has been deployed and becomes operational.

Implementing an exponential backoff in your application is incorrect because this doesn’t address the concurrency issue of your Lambda function. This will just configure your application to have progressively longer waits between API call retries for consecutive error responses.

Increasing the concurrency limit of the function is incorrect because, by default, you can only set the limit as high as 900 per function, which is quite insufficient to handle the expected 5,000 concurrency executions. To properly provide the required capacity needed by the function, you have to request for AWS to increase the concurrency limit of your account.

References:

https://docs.aws.amazon.com/lambda/latest/dg/running-lambda-code.html

https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html#function-configuration

Check out this AWS Lambda Cheat Sheet:

https://tutorialsdojo.com/aws-lambda/

7. QUESTION

A company operates an e-commerce website on Amazon Elastic Container Service (ECS) behind an Application Load Balancer (ALB). They’ve set their ALB as an origin for an Amazon CloudFront distribution. Users interact with the website via a custom domain linked to the CloudFront distribution, all maintained within a public hosted zone in Amazon Route 53.

The company wants to display region-specific pricing tables to its users. For example, when a user from the UK visits the site, they should be redirected to https://tutorialsdojo.com/uk/, while users from the Philippines should view prices on https://tutorialsdojo.com/ph/

How can a developer incorporate this feature in the least amount of development overhead?

• Implement a CloudFront function that returns the appropriate URL based on the CloudFront-Viewer-Country. Configure the distribution to trigger the function on Viewer request events.

• Forward the CloudFront-Viewer-Address header to the web server running on the ECS cluster. Implement a custom logic that matches the header’s value against a GeoIP database to determine user location. Based on the resolved location, redirect users to the appropriate region-specific URL.

• Use AWS Web Application Firewall (WAF's) geo-matching rule to identify the user country and attach it to the ALB. Configure ALB listener rules with path conditions to route traffic based on the identified country.

• Configure the Route 53 record to use the geolocation routing policy.

Incorrect

You can configure CloudFront to add specific HTTP headers to the requests that CloudFront receives from viewers and forwards to your origin or edge function. The values of these HTTP headers are based on the characteristics of the viewer or the viewer request. The headers provide information about the viewer’s device type, IP address, geographic location, request protocol (HTTP or HTTPS), HTTP version, TLS connection details, and JA3 fingerprint.

With these headers, your origin or your edge function can receive information about the viewer without the need for you to write your own code to determine this information. If your origin returns different responses based on the information in these headers, you can include them in the cache key so that CloudFront caches the responses separately. For example, your origin might respond with content in a specific language based on the country that the viewer is in or with content tailored to a specific device type. Your origin might also write these headers to log files, which you can use to determine information about where your viewers are, which device types they’re on, and more.

In the given scenario, when a user initiates a request to the website, a CloudFront function can be triggered to inspect the CloudFront-Viewer-Country header, which pinpoints the originating country of a user. CloudFront functions are lightweight Javascript code that you can use to manipulate web requests at the CloudFront edge locations. By using a CloudFront function triggered on “Viewer request” events, you can assess and act upon incoming requests even before they reach the origin or CloudFront retrieves a cached response.

Here’s a representation using a CloudFront function code snippet:

Hence, the correct answer is: Implement a CloudFront function that returns the appropriate URL based on the CloudFront-Viewer-Country. Configure the distribution to trigger the function on Viewer request events.

The option that says: Forward the CloudFront-Viewer-Address header to the web server running on the ECS cluster. Implement a custom logic that matches the header’s value against a GeoIP database to determine user location. Based on the resolved location, redirect users to the appropriate region-specific URL is incorrect. While this approach is technically valid, it’s more complex since you have to handle the IP-to-location translation on the backend and maintain an up-to-date GeoIP database.

The option that says: Configure the Route 53 record to use the geolocation routing policy is incorrect. Route 53 geolocation routing is primarily used for directing traffic to specific resources based on user location for performance or regulatory reasons, not for content personalization based on geolocation.

The option that says: Use AWS Web Application Firewall (WAF’s) geo-matching rule to identify the user country and attach it to the ALB. Configure ALB listener rules with path conditions to route traffic based on the identified country is incorrect. AWS WAF’s geo-matching rule identifies a user’s country based on their IP. However, it’s primarily designed to allow or block access, not for redirection. Even if used in conjunction with ALB, the ALB’s listener rules can’t inherently make routing decisions based on a viewer’s geolocation

References:

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/adding-cloudfront-headers.html

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-functions.html

Check out this Amazon CloudFront Cheat Sheet:

https://tutorialsdojo.com/amazon-cloudfront/

8. QUESTION

A developer is working with an AWS Serverless Application Model (AWS SAM) application composed of several AWS Lambda functions. The developer runs the application locally on his laptop using sam local commands. While testing, one of the functions returns Access denied errors. Upon investigation, the developer discovered that the Lambda function is using the AWS SDK to make API calls within a sandbox AWS account.

Which combination of steps must the developer do to resolve the issue? (Select TWO)

• Add the AWS credentials of the sandbox AWS account to the Globals section of the template.yml file and reference them in the AWS::Serverless::Function properties section of the Lambda function.

• Run the function using sam local invoke with the --parameter-overrides parameter.

• Run the function using sam local invoke with the --profile parameter.

• Create an AWS SAM CLI configuration file at the root of the SAM project folder. Add the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables to it.

• Use the aws configure command with the --profile parameter to add a named profile with the sandbox AWS account’s credentials.

Incorrect

AWS Lambda functions have an associated execution role that provides permissions to interact with other AWS services. However, when you run AWS Lambda functions locally using the SAM CLI, you’re simulating the execution environment of the Lambda function but not replicating the AWS execution context, including the IAM execution role. This means that the function won’t automatically assume any IAM execution role and instead will rely on the credentials stored in ~/.aws/credentials file.

When testing locally with AWS SAM, you can specify a named profile from your AWS CLI configuration using the --profile parameter with the sam local invoke command. This will instruct the SAM CLI to use the credentials from the specified profile when invoking the Lambda function. You can run the aws configure with the --profile option to set the credentials for a named profile.

In the scenario, the developer must first set up the sandbox AWS account’s credentials using aws configure --profile sandbox. This creates a named profile ‘sandbox’ (note that you can use any name for the profile). For local testing with the SAM CLI, the developer can then specify this profile using the command sam local invoke --profile sandbox. This ensures that the locally executed Lambda function utilizes the correct credentials to access resources in the sandbox AWS account.

Hence, the correct answers are:

– Use the aws configure command with the --profile parameter to add a named profile with the sandbox AWS account’s credentials.

– Run the function using sam local invoke with the --profile parameter.

The option that says: Create an AWS SAM CLI configuration file at the root of the SAM project folder. Add the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables to it is incorrect. The SAM CLI relies on the AWS credentials stored in the /.aws/credentials file, which can be set through the aws configure command. While it’s technically possible to place application credentials in a configuration file, SAM CLI doesn’t support sourcing AWS credentials from it for authentication.

The option that says: Add the AWS credentials of the sandbox AWS account to the Globals section of the template.yml file and reference them in the AWS::Serverless::Function properties section of the Lambda function is incorrect. The Globals section in a SAM template.yaml is primarily used for setting properties that apply to all AWS resources of a certain type. It’s not a storage location for AWS credentials. Moreover, the AWS::Serverless::Function resource property does not have fields for AWS credentials. Even if you were to add the credentials as environment variables, it still wouldn’t grant the locally running function the permissions associated with those credentials.

The option that says: Run the function using sam local invoke with the --parameter-overrides parameter is incorrect. The --parameter-overrides option is typically used to change template parameters during local testing. For instance, if you had a parameter in your SAM template for setting an environment variable, the --parameter-overrides option would allow you to test with different values for those parameters. Still, it does not interact with nor modify AWS credentials.

References:

https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-local-invoke.html

https://aws.amazon.com/blogs/aws/aws-serverless-application-model-sam-command-line-interface-build-test-and-debug-serverless-apps-locally/

https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html

Check out this AWS SAM Cheat Sheet:

https://tutorialsdojo.com/aws-serverless-application-model-sam/

10. QUESTION

An API gateway with a Lambda proxy integration takes a long time to complete its processing. There were also occurrences where some requests timed out. You want to monitor the responsiveness of your API calls as well as the underlying Lambda function.

Which of the following CloudWatch metrics should you use to troubleshoot this issue? (Select TWO.)

• Latency

• IntegrationLatency

• Count

• CacheHitCount

• CacheMissCount

Incorrect

You can monitor API execution using CloudWatch, which collects and processes raw data from API Gateway into readable, near-real-time metrics. These statistics are recorded for a period of two weeks so that you can access historical information and gain a better perspective on how your web application or service is performing. By default, API Gateway metric data is automatically sent to CloudWatch in one-minute periods.

The metrics reported by API Gateway provide information that you can analyze in different ways. The list below shows some common uses for the metrics. These are suggestions to get you started, not a comprehensive list.

– Monitor the IntegrationLatency metrics to measure the responsiveness of the backend.

– Monitor the Latency metrics to measure the overall responsiveness of your API calls.

– Monitor the CacheHitCount and CacheMissCount metrics to optimize cache capacities to achieve a desired performance.

Hence, the correct metrics that you have to use in this scenario are Latency and IntegrationLatency.

Count is incorrect because this metric simply gets the total number of API requests in a given period.

CacheMissCount is incorrect because this metric just gets the number of requests served from the backend in a given period when API caching is enabled. The Sum statistic represents this metric, namely, the total count of the cache misses in the given period.

CacheHitCount is incorrect because this fetches the number of requests served from the API cache in a given period. The Sum statistic represents this metric, namely, the total count of the cache hits in the given period.

References:

https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-metrics-and-dimensions.html

https://docs.aws.amazon.com/apigateway/latest/developerguide/monitoring-cloudwatch.html

Check out this Amazon API Gateway Cheat Sheet:

https://tutorialsdojo.com/amazon-api-gateway

11. QUESTION

A programmer is developing a Node.js application that will be run on a Linux server in their on-premises data center. The application will access various AWS services such as S3, DynamoDB, and ElastiCache using the AWS SDK.

Which of the following is the MOST suitable way to provide access for the developer to accomplish the specified task?

• Go to the AWS Console and create a new IAM user with programmatic access. In the application server, create the credentials file at ~/.aws/credentials with the access keys of the IAM user.

• Create an IAM role with the appropriate permissions to access the required AWS services and assign the role to the on-premises Linux server. Whenever the application needs to access any AWS services, request for temporary security credentials from STS using the AssumeRole API.

• Create an IAM role with the appropriate permissions to access the required AWS services. Assign the role to the on-premises Linux server.

• Go to the AWS Console and create a new IAM User with the appropriate permissions. In the application server, create the credentials file at ~/.aws/credentials with the username and the hashed password of the IAM User.

Incorrect

If you have resources that are running inside AWS that need programmatic access to various AWS services, then the best practice is always to use IAM roles. However, applications running outside of an AWS environment will need access keys for programmatic access to AWS resources. For example, monitoring tools running on-premises and third-party automation tools will need access keys.

Access keys are long-term credentials for an IAM user or the AWS account root user. You can use access keys to sign programmatic requests to the AWS CLI or AWS API (directly or using the AWS SDK).

In order to use the AWS SDK for your application, you have to create your credentials file first at ~/.aws/credentials for Linux servers or at C:\Users\USER_NAME\.aws\credentials for Windows users and then save your access keys.

Hence, the correct answer is: Go to the AWS Console and create a new IAM user with programmatic access. In the application server, create the credentials file at ~/.aws/credentials with the access keys of the IAM user.

The option that says: Create an IAM role with the appropriate permissions to access the required AWS services and assign the role to the on-premises Linux server. Whenever the application needs to access any AWS services, request for temporary security credentials from STS using the AssumeRole API is incorrect because the scenario says that the application is running in a Linux server on-premises and not on an EC2 instance. You cannot directly assign an IAM Role to a server on your on-premises data center. Although it may be possible to use a combination of STS and IAM Role, the use of access keys for AWS SDK is still preferred, especially if the application server is on-premises.

The option that says: Create an IAM role with the appropriate permissions to access the required AWS services. Assign the role to the on-premises Linux server is also incorrect because, just as mentioned above, the use of an IAM Role is not a suitable solution for this scenario.

The option that says: Go to the AWS Console and create a new IAM User with the appropriate permissions. In the application server, create the credentials file at ~/.aws/credentials with the username and the hashed password of the IAM User is incorrect. An IAM user’s username and password can only be used to interact with AWS via its Management Console. These credentials are intended for human use and are not suitable for use in automated systems, such as applications and scripts that make programmatic calls to AWS services.

References:

https://aws.amazon.com/developers/getting-started/nodejs/

https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys

https://aws.amazon.com/blogs/security/guidelines-for-protecting-your-aws-account-while-using-programmatic-access/

Check out this AWS IAM Cheat Sheet:

https://tutorialsdojo.com/aws-identity-and-access-management-iam/

13. QUESTION

A developer is creating an analytics REST API service that is powered by API Gateway. Analysts from a separate AWS account must interact with the service through an IAM role. The IAM role already has a policy that grants permission to invoke the API.

What else should the developer do to meet the requirement without too much overhead?

• Set AWS_IAM as the method authorization type for the API. Attach a resource policy to the API that grants permission to the specified IAM role to invoke the execute-api:Invoke action.

• Create a Lambda function authorizer for the API. In the Lambda function, write a logic that verifies the requester’s identity by extracting the information from the context object.

• Create an API Key for the API. Attach a resource policy to the API that grants permission to the specified IAM role to invoke the GetAPIKeys action.

• Create a Cognito User Pool authorizer. Add the IAM role to the user pool. Authenticate the requester’s identity using Cognito. Ask the analysts to pass the token returned by Cognito in their request headers.

Incorrect

By using AWS_IAM as the method authorization type, it ensures that the API can only be accessed by IAM identities such as IAM users or IAM roles. Attaching a resource policy to the API that grants permission to the specified IAM role to invoke the execute-api:Invoke action allows the specified IAM role to make authorized requests to the API while denying access to any other unauthorized users or roles.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::account-id:role/Analyst" ] }, "Action": "execute-api:Invoke", "Resource": [ "execute-api:/stage/GET/reports" ] } ] }

This combination of method authorization and resource policy provides an additional layer of security for the API.

Hence, the correct answer in this scenario is to Set AWS_IAM as the method authorization type for the API. Attach a resource policy to the API that grants permission to the specified IAM role to invoke the execute-api:Invoke action.

The option that says: Create an API Key for the API. Attach a resource policy to the API that grants permission to the specified IAM role to invoke the GetAPIKeys action is incorrect API Keys are just a way of identifying the calling parties that you trust, but they are not intended to be used to grant permissions to an IAM role.

The option that says: Create a Lambda function authorizer for the API. In the Lambda function, write a logic that verifies the requester’s identity by extracting the information from the context object is incorrect. While this may be possible, Lambda function authorizer is more suitable for custom authorization scheme that uses a bearer token authentication strategy such as OAuth or SAML. Additionally, this approach requires you to write, test, and maintain custom authentication and authorization code, which can be complex and time-consuming.

The option that says: Create a Cognito User Pool authorizer. Add the IAM role to the user pool. Authenticate the requester’s identity using Cognito. Ask the analysts to pass the token returned by Cognito in their request headers is incorrect. Adding a Cognito User Pool authorizer is unnecessary since the API will be accessed through an IAM role.

References:

https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies-examples.html#apigateway-resource-policies-cross-account-example

https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-authorization-flow.html

Check out this AWS API Gateway Sheet:

https://tutorialsdojo.com/amazon-api-gateway/

14. QUESTION

An application hosted in a multicontainer Docker platform in Elastic Beanstalk uses DynamoDB to handle the session data of its users. These data are only used in a particular timeframe and the stale data can be deleted after the user logged out of the system.

Which of the following is the most suitable way to delete the session data?

• Use conditional writes to add the session data to the DynamoDB table and then automatically delete it based on the condition you specify.

• Enable TTL for the session data in the DynamoDB table.

• Use atomic counters to track the validity of the session data and delete once it becomes stale.

• Delete the stale data by regularly performing a scan on the table.

Incorrect

Time To Live (TTL) for DynamoDB allows you to define when items in a table expire so that they can be automatically deleted from the database.

TTL is provided at no extra cost as a way to reduce storage usage and reduce the cost of storing irrelevant data without using provisioned throughput. With TTL enabled on a table, you can set a timestamp for deletion on a per-item basis, allowing you to limit storage usage to only those records that are relevant.

TTL is useful if you have continuously accumulated data that lose relevance after a specific time period. For example session data, event logs, usage patterns, and other temporary data. If you have sensitive data that must be retained only for a certain amount of time according to contractual or regulatory obligations, TTL helps you ensure that it is removed promptly and as scheduled.

Therefore, the correct answer in this scenario is to: Enable TTL for the session data in the DynamoDB table.

The option that says: Delete the stale data by regularly performing a scan on the table is incorrect because the Scan operation uses eventually consistent reads when accessing the data in a table and therefore, the result set might not include the changes to data in the table immediately before the operation began. This is an inefficient option that can simply be replaced by using TTL.

The option that says: Use atomic counters to track the validity of the session data and deleting it once becomes stale is incorrect because atomic counters are primarily used in updating data and for scenarios where you want the updates to not be idempotent.

The option that says: Use conditional writes to add the session data to the DynamoDB table and then automatically deleting it based on the condition you specify is incorrect because conditional writes are only helpful in cases where multiple users attempt to modify the same item.

References:

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/WorkingWithItems.html

Check out this Amazon DynamoDB Cheat Sheet:

https://tutorialsdojo.com/amazon-dynamodb/

Tutorials Dojo’s AWS Certified Developer Associate Exam Study Guide:

https://tutorialsdojo.com/aws-certified-developer-associate/

16. QUESTION

An application performs various workflows and processes long-running tasks that take a long time to complete. The users are complaining that the application is unresponsive since the workflow substantially increased the time it takes to complete a user request.

Which of the following is the BEST way to improve the performance of the application?

• Spawn a worker process locally in the EC2 instances and process the tasks asynchronously.

• Use a multicontainer docker environment in Elastic Beanstalk to process the long-running tasks asynchronously.

• Use an Elastic Beanstalk worker environment to process the tasks asynchronously.

• Use an Amazon ECS Cluster with a Fargate launch type to process the tasks asynchronously.

Incorrect

If your application performs operations or workflows that take a long time to complete, you can offload those tasks to a dedicated worker environment. Decoupling your web application front end from a process that performs blocking operations is a common way to ensure that your application stays responsive under load.

A long-running task is anything that substantially increases the time it takes to complete a request, such as processing images or videos, sending emails, or generating a ZIP archive. These operations can take only a second or two to complete, but a delay of a few seconds is a lot for a web request that would otherwise complete in less than 500 ms.

One option is to spawn a worker process locally, return success, and process the task asynchronously. This works if your instance can keep up with all of the tasks sent to it. Under high load, however, an instance can become overwhelmed with background tasks and become unresponsive to higher-priority requests. If individual users can generate multiple tasks, the increase in load might not correspond to an increase in users, making it hard to scale out your web server tier effectively.

To avoid running long-running tasks locally, you can use the AWS SDK for your programming language to send them to an Amazon Simple Queue Service (Amazon SQS) queue and run the process that performs them on a separate set of instances. You then design these worker instances to take items from the queue only when they have the capacity to run them, preventing them from becoming overwhelmed.

Elastic Beanstalk worker environments simplify this process by managing the Amazon SQS queue and running a daemon process on each instance that reads from the queue for you. When the daemon pulls an item from the queue, it sends an HTTP POST request locally to http://localhost/ on port 80 with the contents of the queue message in the body. All that your application needs to do is perform the long-running task in response to the POST. You can configure the daemon to post to a different path, use a MIME type other than application/JSON, connect to an existing queue, or customize connections (maximum concurrent requests), timeouts, and retries.

Hence, the best solution to meet the requirements of this scenario is to use an Elastic Beanstalk worker environment to process the tasks asynchronously.

Spawning a worker process locally in the EC2 instances then processing the tasks asynchronously is incorrect. Although this is a valid solution, it is not scalable and hence, it’s not the best one. Under high load, an instance can become overwhelmed with background tasks and become unresponsive to higher priority requests. This makes it hard to scale out your web server tier effectively.

Using a multicontainer docker environment in Elastic Beanstalk to process the long-running tasks asynchronously is incorrect because this is primarily used to support multiple containers per Amazon EC2 instance with multicontainer Docker platform. This is not applicable when processing long-running tasks and it is not scalable since it’s not using an SQS queue.

Using an Amazon ECS Cluster with a Fargate launch type to process the tasks asynchronously is incorrect because Fargate just allows you to run your containerized applications without the need to provision and manage the backend infrastructure.

References:

https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features-managing-env-tiers.html

https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_docker_ecs.html

Check out this AWS Elastic Beanstalk Cheat Sheet:

https://tutorialsdojo.com/aws-elastic-beanstalk/

18. QUESTION

A reporting application is hosted in Elastic Beanstalk and uses DynamoDB as its database. If a user requests data, the application scans the entire table and returns the requested data. In the coming weeks, it is expected that the table will grow due to the surge of new users and requested reports.

Which of the following should be done as a preparation to improve the application’s performance with minimal cost? (Select TWO.)

• Reduce page size

• Use DynamoDB Accelerator (DAX)

• Use Query operations instead

• Increase page size

• Increase the Write Compute Unit (WCU) of the table

Incorrect

In general, Scan operations are less efficient than other operations in DynamoDB. A Scan operation always scans the entire table or secondary index. It then filters out values to provide the result you want, essentially adding the extra step of removing data from the result set.

If possible, you should avoid using a Scan operation on a large table or index with a filter that removes many results. Also, as a table or index grows, the Scan operation slows. The Scan operation examines every item for the requested values and can use up the provisioned throughput for a large table or index in a single operation. For faster response times, design your tables and indexes so that your applications can use Query instead of Scan. For tables, you can also consider using the GetItem and BatchGetItem APIs.

Alternatively, you can refactor your application to use Scan operations in a way that minimizes the impact on your request rate. Instead of using a large Scan operation, you can use the following techniques to minimize the impact of a scan on a table’s provisioned throughput.

Reduce page size – Because a Scan operation reads an entire page (by default, 1 MB), you can reduce the impact of the scan operation by setting a smaller page size. The Scan operation provides a Limit parameter that you can use to set the page size for your request. Each Query or Scan request that has a smaller page size uses fewer read operations and creates a “pause” between each request. For example, suppose that each item is 4 KB and you set the page size to 40 items. A Query request would then consume only 20 eventually consistent read operations or 40 strongly consistent read operations. A larger number of smaller Query or Scan operations would allow your other critical requests to succeed without throttling.

Isolate scan operations – DynamoDB is designed for easy scalability. As a result, an application can create tables for distinct purposes, possibly even duplicating content across several tables. You want to perform scans on a table that is not taking “mission-critical” traffic. Some applications handle this load by rotating traffic hourly between two tables—one for critical traffic, and one for bookkeeping. Other applications can do this by performing every write on two tables: a “mission-critical” table, and a “shadow” table.

Hence, using Query operations instead of Scan and reducing the page size are the correct answers.

Using DynamoDB Accelerator (DAX) is incorrect. Although this will improve the scalability and read performance of the application, it adds a significant cost in maintaining your application. Using Query operations and reducing the page size of your query are the more cost-effective solutions in this scenario.

Increasing page size is incorrect because it should be the other way around. You have to decrease the page size of the Scan operation using the Limit parameter to reduce the impact.

Increasing the Write Compute Unit (WCU) of the table is incorrect because the reporting application is heavily used for reading data and not for writing. In addition, increasing the WCU will increase the cost.

References:

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-query-scan.html#bp-query-scan-spikes

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html

Check out this Amazon DynamoDB Cheat Sheet:

https://tutorialsdojo.com/amazon-dynamodb/

19. QUESTION

A developer is managing a serverless application orchestrated by AWS Step Functions. One of the Lambda functions sends an API call to a third-party payment service, which takes some time to complete. The Step Functions workflow needs to pause while the service validates the payment. It should only resume after the service sends a notification to a webhook endpoint.

Which combination of actions will fulfill the requirements in the most cost-effective manner? (Select Two)

• Use a Wait State to pause the execution of the workflow. Configure the webhook handler to invoke the Lambda function synchronously.

• Configure the Lambda function task state to use the waitForTaskToken option. Retrieve the task token from the context object of the state machine and include it as part of the Lambda function’s payload body.

• Configure the webhook handler to call the SendTaskHeartbeat method after a successful notification.

• Configure the webhook handler to call the SendTaskSuccess method after a successful notification.

• Set the invocation method of the Lambda function task state to asynchronous. Create an AWS SQS queue and configure the webhook handler to send the payment service’s response to the queue. Use a combination of Wait State and Choice State to poll the queue.

Incorrect

In AWS Step Functions, the waitForTaskToken option allows a task to be paused until an external system signals its completion. When a task is configured with this option, Step Functions generates a unique token, which can be retrieved from the context object of the state machine. This token, for instance, can be stored in a data store for reference.

The diagram below depicts how waitForTaskToken is used for an SQS task state.

An external system, such as a webhook handler can then reference the token and call the SendTaskSuccess or SendTaskFailure method to signal Step Functions to resume the workflow. When the workflow is in a paused state, you’re not billed for the time the workflow is paused, making it a cost-effective method for awaiting external processes or events.

Hence, the correct answers are:

• Configure the Lambda function task state to use the waitForTaskToken option. Retrieve the task token from the context object of the state machine and include it as part of the Lambda function’s payload body.

• Configure the webhook handler to call the SendTaskSuccess method after a successful notification.

The option that says: Set the invocation method of the Lambda function task state to asynchronous. Create an AWS SQS queue and configure the webhook handler to send the payment service’s response to the queue. Use a combination of Wait State and Choice State to poll the queue is incorrect. While this solution may work, every iteration involving the Wait State and Choice State incurs a cost as a state transition. If the third-party service takes an unpredictable amount of time, the state machine could go through multiple cycles of waiting and checking the SQS queue, resulting in a higher cost.

The option that says: Use a Wait State to pause the execution of the workflow. Configure the webhook handler to invoke the Lambda function synchronously is incorrect. A fixed Wait State is less cost-effective in scenarios where the waiting duration is unpredictable. If the third-party service finishes earlier than the wait duration, you’re paying for unused time. If it takes longer, the workflow might proceed before the task is complete.

The option that says: Configure the webhook handler to call the SendTaskHeartbeat method after a successful notification is incorrect because this method is simply used for keeping tasks alive and preventing them from timing out. It also does not signal completion.

References:

https://aws.amazon.com/blogs/compute/building-cost-effective-aws-step-functions-workflows/

https://docs.aws.amazon.com/step-functions/latest/dg/callback-task-sample-sqs.html

https://docs.aws.amazon.com/step-functions/latest/dg/connect-to-resource.html

Check out this AWS Step Functions Cheat Sheet:

https://tutorialsdojo.com/aws-step-functions/

21. QUESTION

A developer is working on an application which stores data to an Amazon DynamoDB table with the DynamoDB Streams feature enabled. He set up an event source mapping with DynamoDB Streams and AWS Lambda function to monitor any table changes then store the original data of the overwritten item in S3. When an item is updated, it should only send a copy of the item’s previous value to an S3 bucket and maintain the new value in the DynamoDB table.

Which StreamViewType is the MOST suitable one to use in the DynamoDB configuration to fulfill this scenario?

• NEW_IMAGE

• NEW_AND_OLD_IMAGES

• KEYS_ONLY

• OLD_IMAGE

Incorrect

DynamoDB Streams provides a time-ordered sequence of item level changes in any DynamoDB table. The changes are de-duplicated and stored for 24 hours. Applications can access this log and view the data items as they appeared before and after they were modified, in near real time.

Amazon DynamoDB is also integrated with AWS Lambda so that you can create triggers—pieces of code that automatically respond to events in DynamoDB Streams. With triggers, you can build applications that react to data modifications in DynamoDB tables.

When an item in the table is modified, StreamViewType determines what information are written to the stream for this table. Valid values for StreamViewType are KEYS_ONLY, NEW_IMAGE, OLD_IMAGE, and NEW_AND_OLD_IMAGES.

For the OLD_IMAGE type, the entire item which has the previous value as it appeared before it was modified is written to the stream. Hence, this is the correct answer in this scenario.

KEYS_ONLY is incorrect because it will only write the key attributes of the modified item to the stream. This choice is wrong since the question states that values should be copied as well.

NEW_IMAGE is incorrect because it will configure the stream to write the entire item with its new value as it appears after it was modified. This choice is wrong since the stream should capture the item’s pre-modified values.

NEW_AND_OLD_IMAGES is incorrect because although it writes the new values of the item in the stream, it also includes the old one as well. Since this type will send both the new and the old item images of the item to the stream, this option is wrong. Remember that it should only send a copy of the item’s previous value to the S3 bucket, and not the new value in the DynamoDB table. The most suitable one to use here is the OLD_IMAGE type.

References:

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html

https://docs.amazonaws.cn/en_us/amazondynamodb/latest/developerguide/Streams.Lambda.html

https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_StreamSpecification.html

Check out this Amazon DynamoDB Cheat Sheet:

https://tutorialsdojo.com/amazon-dynamodb/

AWS Lambda Integration with Amazon DynamoDB Streams:

https://tutorialsdojo.com/aws-lambda-integration-with-amazon-dynamodb-streams/

Tutorials Dojo’s AWS Certified Developer Associate Exam Study Guide:

https://tutorialsdojo.com/aws-certified-developer-associate/

23. QUESTION

A recently deployed Lambda function has an intermittent issue in processing customer data. You enabled the active tracing option in order to detect, analyze, and optimize performance issues of your function using the X-Ray service.

Which of the following environment variables are used by AWS Lambda to facilitate communication with X-Ray? (Select TWO.)

• _X_AMZN_TRACE_ID

• AWS_XRAY_DEBUG_MODE

• AUTO_INSTRUMENT

• AWS_XRAY_TRACING_NAME

• AWS_XRAY_CONTEXT_MISSING

Incorrect

AWS X-Ray is an AWS service that allows you to detect, analyze, and optimize performance issues with your AWS Lambda applications. X-Ray collects metadata from the Lambda service and any upstream or downstream services that make up your application. X-Ray uses this metadata to generate a detailed service graph that illustrates performance bottlenecks, latency spikes, and other issues that impact the performance of your Lambda application.

AWS Lambda uses environment variables to facilitate communication with the X-Ray daemon and configure the X-Ray SDK.

_X_AMZN_TRACE_ID: Contains the tracing header, which includes the sampling decision, trace ID, and parent segment ID. If Lambda receives a tracing header when your function is invoked, that header will be used to populate the _X_AMZN_TRACE_ID environment variable. If a tracing header was not received, Lambda will generate one for you.

AWS_XRAY_CONTEXT_MISSING: The X-Ray SDK uses this variable to determine its behavior in the event that your function tries to record X-Ray data, but a tracing header is not available. Lambda sets this value to LOG_ERROR by default.

AWS_XRAY_DAEMON_ADDRESS: This environment variable exposes the X-Ray daemon’s address in the following format: IP_ADDRESS:PORT. You can use the X-Ray daemon’s address to send trace data to the X-Ray daemon directly without using the X-Ray SDK.

Therefore, the correct answers for this scenario are the _X_AMZN_TRACE_ID and AWS_XRAY_CONTEXT_MISSING environment variables.

AWS_XRAY_TRACING_NAME is incorrect because this is primarily used in X-Ray SDK where you can set a service name that the SDK uses for segments.

AWS_XRAY_DEBUG_MODE is incorrect because this is used to configure the SDK to output logs to the console without using a logging library.

AUTO_INSTRUMENT is incorrect because this is primarily used in X-Ray SDK for Django Framework only. This allows the recording of subsegments for built-in database and template rendering operations.

References:

https://docs.aws.amazon.com/lambda/latest/dg/lambda-x-ray.html#viewing-lambda-xray-results

https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-nodejs-configuration.html

https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-python-configuration.html

Check out this AWS X-Ray Cheat Sheet:

https://tutorialsdojo.com/aws-x-ray/

Instrumenting your Application with AWS X-Ray:

https://tutorialsdojo.com/instrumenting-your-application-with-aws-x-ray/

24. QUESTION

A developer has deployed a Lambda function that runs in DEV, UAT, and PROD environments. The function uses different parameters that varies based on the environment it is running in. The parameters are currently hardcoded in the function.

Which action should the developer do to reference the appropriate parameters without modifying the code every time the environment changes?

• Use environment variables to set the parameters per environment.

• Create a stage variable called ENV and invoke the Lambda function by its alias name.

• Publish three versions of the Lambda function. Assign the aliases DEV, UAT, and PROD to each version.

• Create individual Lambda Layers for each environment

Incorrect

Environment variables for Lambda functions enable you to dynamically pass settings to your function code and libraries without making changes to your code. Environment variables are key-value pairs that you create and modify as part of your function configuration using either the AWS Lambda Console, the AWS Lambda CLI, or the AWS Lambda SDK. AWS Lambda then makes these key-value pairs available to your Lambda function code using standard APIs supported by the language, like process.env for Node.js functions.

You can use environment variables to help libraries know what directory to install files in, where to store outputs, store connection and logging settings, and more. By separating these settings from the application logic, you don’t need to update your function code when changing the function behavior based on different settings.

Hence, the correct answer is: Use environment variables to set the parameters per environment.

The option that says: Create a stage variable called ENV and invoke the Lambda function by its alias name is incorrect because the stage variable is a feature of API Gateway, not AWS Lambda.

The option that says: Create individual Lambda Layers for each environment is incorrect because this feature is only used to pull in additional code and content in the form of layers. A layer is a ZIP archive that contains libraries, a custom runtime, or other dependencies.

The option that says: Publish three versions of the Lambda function. Assign the aliases DEV, UAT, and PROD to each version is incorrect because this is just like a pointer to a specific Lambda function version. By using aliases, you can access the Lambda function, which the alias is pointing to, without the caller knowing the specific version the alias is pointing to.

References:

https://docs.aws.amazon.com/lambda/latest/dg/env_variables.html

https://docs.aws.amazon.com/lambda/latest/dg/lambda-configuration.html

Check out this AWS Lambda Cheat Sheet:

https://tutorialsdojo.com/aws-lambda/

25. QUESTION

A mobile game is using a DynamoDB table named GameScore that keeps track of users and scores. Each item in the table is identified by a partition key (UserId) and a sort key (GameTitle). The diagram below shows how the items in the table are organized:

A developer wants to write a leaderboard application to display the top scores for each game.

How can the developer meet the requirement in the MOST efficient manner?

• Create a local secondary index. Assign the GameTitle attribute as the partition key and the TopScore attribute as the sort key.

• Create a global secondary index. Assign the GameTitle attribute as the partition key and the TopScore attribute as the sort key.

• Create a local secondary index. Assign the TopScore attribute as the partition key and the GameTitle attribute as the sort key.

• Use the Scan operation and filter the results based on a GameTitle value.

Incorrect

Amazon DynamoDB provides fast access to items in a table by specifying primary key values. However, many applications might benefit from having one or more secondary (or alternate) keys available, to allow efficient access to data with attributes other than the primary key. To address this, you can create one or more secondary indexes on a table, and issue Query or Scan requests against these indexes.

A secondary index is a data structure that contains a subset of attributes from a table, along with an alternate key to support Query operations. You can retrieve data from the index using a Query, in much the same way as you use Query with a table. A table can have multiple secondary indexes, which gives your applications access to many different query patterns.

DynamoDB supports two types of secondary indexes:

Global secondary index — an index with a partition key and a sort key that can be different from those on the base table. A global secondary index is considered “global” because queries on the index can span all of the data in the base table, across all partitions.

Local secondary index — an index that has the same partition key as the base table, but a different sort key. A local secondary index is “local” in the sense that every partition of a local secondary index is scoped to a base table partition that has the same partition key value.

To speed up queries on non-key attributes, you can create a global secondary index. A global secondary index contains a selection of attributes from the base table, but they are organized by a primary key that is different from that of the table. The index key does not need to have any of the key attributes from the table; it doesn’t even need to have the same key schema as a table.

In this scenario, you could create a global secondary index named GameTitleIndex, with a partition key of GameTitle and a sort key of TopScore. Since the base table’s primary key attributes are always projected into an index, the UserId attribute is also present. The following diagram shows what GameTitleIndex index would look like:

Hence, the correct answer in this scenario is to: Create a global secondary index. Assign the GameTitle attribute as the partition key and the TopScore attribute as the sort key.

Create a local secondary index. Assign the TopScore attribute as the partition key and the GameTitle attribute as the sort key is incorrect. You can’t add a local secondary index to an existing table. Moreover, even if it’s possible, making a query that returns the top scores for each game is impossible with the TopScore attribute as the partition key. When you issue a query, you must also specify a partition key. In this case, if you run a query with a partition key value of 500, the results might return different games with a score of 500 from various users. It does not tell if it’s the highest score in that game.

Create a local secondary index. Assign the GameTitle attribute as the partition key and the TopScore attribute as the sort key is incorrect because you can’t add this index to an already existing table. Additionally, a local secondary index has the same partition key as the base table, but has a different sort key. It is “local” in the sense that every partition of a local secondary index is scoped to a base table partition that has the same partition key value.

Use the Scan operation and filter the results based on a GameTitle value is incorrect. Technically, this also works but it is less efficient and slower compared to querying on secondary indexes. The Scan operation reads every item in a table. As the table grows, the slower the Scan operation would become.

References:

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SecondaryIndexes.html

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GSI.html

Check out this Amazon DynamoDB Cheat Sheet:

https://tutorialsdojo.com/amazon-dynamodb/

DynamoDB Scan vs Query:

https://tutorialsdojo.com/dynamodb-scan-vs-query/

28. QUESTION

You developed a shell script which uses AWS CLI to create a new Lambda function. However, you received an InvalidParameterValueException after running the script.

What is the MOST likely cause of this issue?

• The AWS Lambda service encountered an internal error.

• You provided an IAM role in the CreateFunction API which AWS Lambda is unable to assume.

• The resource already exists.

• You have exceeded your maximum total code size per account.

Incorrect

To create a Lambda function, you need a deployment package and an execution role. The deployment package contains your function code. The execution role grants the function permission to use AWS services, such as Amazon CloudWatch Logs for log streaming and AWS X-Ray for request tracing. You can use the CreateFunction API via the AWS CLI or the AWS SDK of your choice.

A function has an unpublished version, and can have published versions and aliases. The unpublished version changes when you update your function’s code and configuration. A published version is a snapshot of your function code and configuration that can’t be changed. An alias is a named resource that maps to a version, and can be changed to map to a different version.

The InvalidParameterValueException will be returned if one of the parameters in the request is invalid. For example, if you provided an IAM role in the CreateFunction API which AWS Lambda is unable to assume. Hence, this option is the most likely cause of the issue in this scenario.

If you have exceeded your maximum total code size per account, the CodeStorageExceededException will be returned, which is why this option is incorrect.

If the resource already exists, the ResourceConflictException will be returned and not InvalidParameterValueException. Therefore, this option is also incorrect.

If the AWS Lambda service encountered an internal error, the ServiceException will be returned hence, this option is incorrect.

References:

https://docs.aws.amazon.com/lambda/latest/dg/API_CreateFunction.html

https://docs.aws.amazon.com/cli/latest/reference/lambda/create-function.html

Check out this AWS Lambda Cheat Sheet:

https://tutorialsdojo.com/aws-lambda/

29. QUESTION

A website hosted in AWS has a custom CloudWatch metric to track all HTTP server errors in the site every minute, which occurs intermittently. An existing CloudWatch Alarm has already been configured for this metric but you would like to re-configure this to properly monitor the application. The alarm should only be triggered when all three data points in the most recent three consecutive periods are above the threshold.

Which of the following options is the MOST appropriate way to monitor the website based on the given threshold?

• Set both the Period and Datapoints to Alarm to 3.

• Use high-resolution metrics.

• Use metric math in CloudWatch to properly compute the threshold.

• Set both the Evaluation Period and Datapoints to Alarm to 3.

Incorrect

When you create an alarm, you specify three settings to enable CloudWatch to evaluate when to change the alarm state:

– Period is the length of time to evaluate the metric or expression to create each individual data point for an alarm. It is expressed in seconds. If you choose one minute as the period, there is one datapoint every minute.

– Evaluation Period is the number of the most recent periods, or data points, to evaluate when determining alarm state.

– Datapoints to Alarm is the number of data points within the evaluation period that must be breaching to cause the alarm to go to the ALARM state. The breaching data points do not have to be consecutive, they just must all be within the last number of data points equal to Evaluation Period.

In the following figure, the alarm threshold is set to three units. The alarm is configured to go to the ALARM state and both Evaluation Period and Datapoints to Alarm are 3. That is, when all three datapoints in the most recent three consecutive periods are above the threshold, the alarm goes to the ALARM state. In the figure, this happens in the third through fifth time periods. At period six, the value dips below the threshold, so one of the periods being evaluated is not breaching, and the alarm state changes to OK. During the ninth time period, the threshold is breached again, but for only one period. Consequently, the alarm state remains OK.

Hence, the option that says: Set both the Evaluation Period and Datapoints to Alarm to 3 is the correct answer.

The option that says: Use high-resolution metrics is incorrect because the scenario says that it only needs to monitor the HTTP server errors every minute, and not its sub-minute activity. If you set an alarm on a high-resolution metric, you can specify a high-resolution alarm with a period of 10 seconds or 30 seconds. Hence, this option is irrelevant in this scenario.

The option that says: Set both the Period and Datapoints to Alarm to 3 is incorrect because you should set the Evaluation Period and not the Period setting.

The option that says: Use metric math in CloudWatch to properly compute the threshold is incorrect because the Metric Math feature is only applicable for scenarios where you need to query multiple CloudWatch metrics or if you want to use math expressions to create new time series based on selected metrics.

References:

https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html

https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html

Check out this Amazon CloudWatch Cheat Sheet:

https://tutorialsdojo.com/amazon-cloudwatch/

33. QUESTION

A developer is refactoring a Lambda function that currently processes data using a public GraphQL API. There’s a new requirement to store query results in a database hosted in a VPC. The function has been configured with additional VPC-specific information, and the database connection has been successfully established. However, the engineer has discovered that the function can no longer connect to the internet after testing.

Which of the following should the developer do to fix this issue? (Select TWO.)

• Ensure that the associated security group of the Lambda function allows outbound connections.

• Submit a limit increase request to AWS to raise the concurrent executions limit of your Lambda function.

• Configure your function to forward payloads that were not processed to a dead-letter queue (DLQ) using Amazon SQS.

• Add a NAT gateway to your VPC.

• Set up elastic network interfaces (ENIs) to enable your Lambda function to connect securely to other resources within your private VPC.

Incorrect

AWS Lambda uses the VPC information you provide to set up ENIs that allow your Lambda function to access VPC resources. Each ENI is assigned a private IP address from the IP address range within the subnets you specify but is not assigned any public IP addresses.

Therefore, if your Lambda function requires Internet access (for example, to access AWS services that don’t have VPC endpoints ), you can configure a NAT instance inside your VPC, or you can use the Amazon VPC NAT gateway. You cannot use an Internet gateway attached to your VPC since that requires the ENI to have public IP addresses.

If your Lambda function needs Internet access, just as described in this scenario, do not attach it to a public subnet or to a private subnet without Internet access. Instead, attach it only to private subnets with Internet access through a NAT instance or add a NAT gateway to your VPC. You should also ensure that the associated security group of the Lambda function allows outbound connections.

The option that says: Submit a limit increase request to AWS to raise the concurrent executions limit of your Lambda function is incorrect because the root cause of the problem is that the function cannot connect to public GraphQL APIs over the Internet. The scenario doesn’t mention anything about a concurrency problem.

The option that says: Configuring your function to forward payloads that were not processed to a dead-letter queue (DLQ) using Amazon SQS is incorrect because it will only improve the error handling of your Lambda function. The issue here is the Internet connectivity of your function and not its error handling hence, this option will not solve the problem.

The option that says: Setting up elastic network interfaces (ENIs) to enable your Lambda function to connect securely to other resources within your private VPC is incorrect because this is already done automatically by AWS Lambda. It uses the VPC information you provide to automatically set up ENIs that allow your Lambda function to access VPC resources. You don’t need to do this step in order for your Lambda function to be integrated with your VPC.

References:

https://docs.aws.amazon.com/lambda/latest/dg/vpc.html

https://aws.amazon.com/premiumsupport/knowledge-center/internet-access-lambda-function/

Check out this AWS Lambda Cheat Sheet:

https://tutorialsdojo.com/aws-lambda/

34. QUESTION

A developer is managing a distributed system that consists of an Application Load Balancer, an SQS queue, and an Auto Scaling group of EC2 instances. The system has been integrated with CloudFront to better serve clients worldwide. To enhance the security of the in-flight data, the developer was instructed to establish an end-to-end SSL connection between the origin and the end-users.

Which TWO options will allow the developer to meet this requirement using CloudFront? (Select TWO.)

• Configure your ALB to only allow traffic on port 443 using an SSL certificate from AWS Config.

• Configure the Origin Protocol Policy to use HTTPS only

• Configure the Viewer Protocol Policy to use HTTPS only

• Set up an Origin Access Control (OAC) setting

• Associate a Web ACL using AWS Web Application Firewall (WAF) with your CloudFront Distribution.

Incorrect

For web distributions, you can configure CloudFront to require that viewers use HTTPS to request your objects, so connections are encrypted when CloudFront communicates with viewers. You can also configure CloudFront to use HTTPS to get objects from your origin, so connections are encrypted when CloudFront communicates with your origin.

If you configure CloudFront to require HTTPS both to communicate with viewers and to communicate with your origin, here’s what happens when CloudFront receives a request for an object. The process works basically the same way whether your origin is an Amazon S3 bucket or a custom origin such as an HTTP/S server:

1. A viewer submits an HTTPS request to CloudFront. There’s some SSL/TLS negotiation here between the viewer and CloudFront. In the end, the viewer submits the request in an encrypted format.

2. If the object is in the CloudFront edge cache, CloudFront encrypts the response and returns it to the viewer, and the viewer decrypts it.

3. If the object is not in the CloudFront cache, CloudFront performs SSL/TLS negotiation with your origin and, when the negotiation is complete, forwards the request to your origin in an encrypted format.

4. Your origin decrypts the request, encrypts the requested object, and returns the object to CloudFront.

5. CloudFront decrypts the response, re-encrypts it, and forwards the object to the viewer. CloudFront also saves the object in the edge cache so that the object is available the next time it’s requested.

6. The viewer decrypts the response.

You can configure one or more cache behaviors in your CloudFront distribution to require HTTPS for communication between viewers and CloudFront. You also can configure one or more cache behaviors to allow both HTTP and HTTPS, so that CloudFront requires HTTPS for some objects but not for others.

To implement this setup, you have to change the Origin Protocol Policy setting for the applicable origins in your distribution. If you’re using the domain name that CloudFront assigned to your distribution, such as dtut0rial5d0j0.cloudfront.net, you change the Viewer Protocol Policy setting for one or more cache behaviors to require HTTPS communication. With this configuration, CloudFront provides the SSL/TLS certificate.

Hence, the correct answers are: Configure the Origin Protocol Policy to use HTTPS only and Configure the Viewer Protocol Policy to use HTTPS only are correct answers in this scenario.

The option that says: Configure your ALB to only allow traffic on port 443 using an SSL certificate from AWS Config is incorrect because you can’t store a certificate in AWS Config.

The option that says: Set up an Origin Access Control (OAC) setting is incorrect because this CloudFront feature only allows you to secure S3 origins by granting access to S3 buckets for designated CloudFront distributions. This method is applicable only to S3 origins and cannot be used to establish end-to-end SSL connections for other origins.

The option that says: Associate a Web ACL using AWS Web Application Firewall (WAF) with your CloudFront Distribution is incorrect because AWS WAF is primarily used to protect your web applications from common web exploits that could affect application availability, compromise security, or consume excessive resources. This will not allow you to establish an SSL connection between your origin and your clients.

References:

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https.html

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-cloudfront-to-custom-origin.html#using-https-cloudfront-to-origin-certificate

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html

Check out this Amazon CloudFront Cheat Sheet:

https://tutorialsdojo.com/amazon-cloudfront/

36. QUESTION

A developer configured an Amazon API Gateway proxy integration named MyAPI to work with a Lambda function. However, when the API is being called, the developer receives a 502 Bad Gateway error. She tried invoking the underlying function, but it properly returned the result in XML format.

What is the MOST likely root cause of this issue?

• There is an incompatible output returned from a Lambda proxy integration backend.

• The endpoint request timed-out.

• There has been an occasional out-of-order invocation due to heavy loads.

• The API name of the Amazon API Gateway proxy is invalid.

Incorrect

Amazon API Gateway Lambda proxy integration is a simple, powerful, and nimble mechanism to build an API with a setup of a single API method. The Lambda proxy integration allows the client to call a single Lambda function in the backend. The function accesses many resources or features of other AWS services, including calling other Lambda functions

In Lambda proxy integration, when a client submits an API request, API Gateway passes the raw request as-is to the integrated Lambda function, except that the order of the request parameters is not preserved. This request data includes the request headers, query string parameters, URL path variables, payload, and API configuration data. The configuration data can include current deployment stage name, stage variables, user identity, or authorization context (if any). The backend Lambda function parses the incoming request data to determine the response that it returns.

For API Gateway to pass the Lambda output as the API response to the client, the Lambda function must return the result in the following JSON format:

{
    "isBase64Encoded": true|false,
    "statusCode": httpStatusCode,
    "headers": { "headerName": "headerValue", ... },
    "body": "..."
}

Since the Lambda function returns the result in XML format, it will cause the 502 errors in the API Gateway. Hence, the correct answer is that there is an incompatible output returned from a Lambda proxy integration backend.

The option that says: The API name of the Amazon API Gateway proxy is invalid is incorrect because there is nothing wrong with its MyAPI name.

The option that says: There has been an occasional out-of-order invocation due to heavy loads is incorrect. Although this is a valid cause of a 502 error, the issue is most likely caused by the Lambda function’s XML response instead of JSON.

The option that says: The endpoint request timed-out is incorrect because this will likely result in 504 errors and not 502’s.

References:

https://aws.amazon.com/premiumsupport/knowledge-center/malformed-502-api-gateway/

https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html#api-gateway-simple-proxy-for-lambda-output-format

https://docs.aws.amazon.com/apigateway/api-reference/handling-errors/

Check out this Amazon API Gateway Cheat Sheet:

https://tutorialsdojo.com/amazon-api-gateway/

38. QUESTION

You are building a distributed system using KMS where you need to encrypt data at a later time. An API must be called that returns only the encrypted copy of the data key which you will use for encryption. After an hour, you will decrypt the data key by calling the Decrypt API then using the returned plaintext data key to finally encrypt the data.

Which is the MOST suitable KMS API that the system should use to securely implement the requirements described above?

• GenerateRandom

• Encrypt

• GenerateDataKeyWithoutPlaintext

• GenerateDataKey

Incorrect

The GenerateDataKeyWithoutPlaintext API generates a unique data key. This operation returns a data key that is encrypted under a customer master key (CMK) that you specify. GenerateDataKeyWithoutPlaintext is identical to GenerateDataKey except that it returns only the encrypted copy of the data key.

Like GenerateDataKey, GenerateDataKeyWithoutPlaintext returns a unique data key for each request. The bytes in the key are not related to the caller or CMK that is used to encrypt the data key.

This operation is useful for systems that need to encrypt data at some point, but not immediately. When you need to encrypt the data, you call the Decrypt operation on the encrypted copy of the key.

It’s also useful in distributed systems with different levels of trust. For example, you might store encrypted data in containers. One component of your system creates new containers and stores an encrypted data key with each container. Then, a different component puts the data into the containers. That component first decrypts the data key, uses the plaintext data key to encrypt data, puts the encrypted data into the container, and then destroys the plaintext data key. In this system, the component that creates the containers never sees the plaintext data key.

Hence, the correct answer in this scenario is to use the GenerateDataKeyWithoutPlaintext API.

GenerateDataKey is incorrect because this operation also returns a plaintext copy of the data key along with the copy of the encrypted data key under a customer master key (CMK) that you specified. Take note that the scenario explicitly mentioned that the API must return only the encrypted copy of the data key which will be used later for encryption. Although this API can be used in this scenario, it is not recommended since the actual encryption process of the data happens at a later time and not in real-time.

Encrypt is incorrect because this just encrypts plaintext into ciphertext by using a customer master key (CMK). This is primarily used to move encrypted data from one AWS region to another.

GenerateRandom is incorrect because this just returns a random byte string that is cryptographically secure. This is not relevant in this scenario, as you have to use the GenerateDataKeyWithoutPlaintext API to properly implement the requirement.

References:

https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKeyWithoutPlaintext.html

https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#data-keys

Check out this AWS KMS Cheat Sheet:

https://tutorialsdojo.com/aws-key-management-service-aws-kms/

39. QUESTION

A developer is building a photo-sharing application that automatically enhances images uploaded by users to Amazon S3. When a user uploads an image, its S3 path is sent to an image-processing application hosted on AWS Lambda. The Lambda function applies the selected filter to the image and stores it back to S3.

If the upload is successful, the application will return a prompt telling the user that the request has been accepted. The entire processing typically takes an average of 5 minutes to complete, which causes the application to become unresponsive.

Which of the following is the MOST suitable and cost-effective option which will prevent the application from being unresponsive?

• Use AWS Serverless Application Model (AWS SAM) to allow asynchronous requests to your Lambda function.

• Configure the application to asynchronously process the requests and use the default invocation type of the Lambda function.

• Configure the application to asynchronously process the requests and change the invocation type of the Lambda function to Event.

• Use a combination of Lambda and Step Functions to orchestrate service components and asynchronously process the requests.

Incorrect

AWS Lambda supports synchronous and asynchronous invocation of a Lambda function. You can control the invocation type only when you invoke a Lambda function (referred to as on-demand invocation). The following examples illustrate on-demand invocations:

– Your custom application invokes a Lambda function.

– You manually invoke a Lambda function (for example, using the AWS CLI) for testing purposes.

In both cases, you invoke your Lambda function using the Invoke operation, and you can specify the invocation type as synchronous or asynchronous.

When you use AWS services as a trigger, the invocation type is predetermined for each service. You have no control over the invocation type that these event sources use when they invoke your Lambda function.

In the Invoke API, you have 3 options to choose from for the InvocationType:

RequestResponse (default) – Invoke the function synchronously. Keep the connection open until the function returns a response or times out. The API response includes the function response and additional data.

Event – Invoke the function asynchronously. Send events that fail multiple times to the function’s dead-letter queue (if it’s configured). The API response only includes a status code.

DryRun – Validate parameter values and verify that the user or role has permission to invoke the function.

By configuring the application to asynchronously process requests by changing the invocation type of the Lambda function to “Event,” the function can run in the background without blocking the main application. When the processing is complete, Lambda can store it back to S3 and trigger another event, such as a notification to the user that the image is ready.

Hence, the correct answer is to configure the application to asynchronously process the requests and change the invocation type of the Lambda function to Event.

Configuring the application to asynchronously process the requests and use the default invocation type of the Lambda function is incorrect because this will invoke your Lambda function synchronously. The default invocation type is RequestResponse which invokes the function synchronously and keeps the connection open until the function returns a response or times out.

Using AWS Serverless Application Model (AWS SAM) to allow asynchronous requests to your Lambda function is incorrect because AWS SAM just is an open-source framework that you can use to build serverless applications on AWS.

Using a combination of Lambda and Step Functions to orchestrate service components and asynchronously process the requests is incorrect because the AWS Step Functions service just lets you coordinate multiple AWS services into serverless workflows so you can build and update apps quickly. Although this can be a valid solution, it is not cost-effective since the application does not have a lot of components to orchestrate. Lambda functions can effectively meet the requirements in this scenario without using Step Functions by processing the requests asynchronously.

References:

https://docs.aws.amazon.com/lambda/latest/dg/invocation-options.html

https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html

Check out this AWS Lambda Cheat Sheet:

https://tutorialsdojo.com/aws-lambda/

41. QUESTION

A developer is building an e-commerce application which will be hosted in an ECS Cluster. To minimize the number of instances in use, she must select a strategy which will place tasks based on the least available amount of CPU or memory.

Which of the following task placement strategy should the developer implement?

• random

• binpack

• spread

• distinctInstance

Incorrect

A task placement strategy is an algorithm for selecting instances for task placement or tasks for termination. Task placement strategies can be specified when either running a task or creating a new service.

Amazon ECS supports the following task placement strategies:

binpack – Place tasks based on the least available amount of CPU or memory. This minimizes the number of instances in use.

random – Place tasks randomly.

spread – Place tasks evenly based on the specified value. Accepted values are attribute key-value pairs, instanceId, or host.

The scenario states that the developer must select a task placement strategy which will place tasks based on the least available amount of CPU or memory. By using bin pack strategy with CPU as the field parameter, ECS is able to place tasks onto an instance with the least available amount of CPU first, before moving on to the other instances. Hence, the correct answer is to use the binpack task placement strategy.

random is incorrect because this will place the tasks randomly, rather than placing the tasks to the instances based on the least available amount of CPU or memory.

spread is incorrect because this will place tasks evenly to the instances based on a specified value.

distinctInstance is incorrect because this is not a valid task placement strategy, but a task placement constraint. This is primarily used as a constraint to place each task on a different container instance. It can be specified when either running a task or creating a new service.

References:

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement.html

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html

https://aws.amazon.com/blogs/compute/amazon-ecs-task-placement/

Check out this Amazon ECS Cheat Sheet:

https://tutorialsdojo.com/amazon-elastic-container-service-amazon-ecs/

45. QUESTION

You want to update a Lambda function on your production environment and ensure that when you publish the updated version, you still have a quick way to roll back to the older version in case you encountered a problem. To prevent any sudden user interruptions, you want to gradually increase the traffic going to the new version.

Which of the following implementation is the BEST option to use?

• Use ELB to route traffic to both Lambda functions.

• Use stage variables in your Lambda function.

• Use Route 53 weighted routing to two Lambda functions.

• Use Traffic Shifting with Lambda Aliases.

Incorrect

By default, an alias points to a single Lambda function version. When the alias is updated to point to a different function version, incoming request traffic in turn instantly points to the updated version. This exposes that alias to any potential instabilities introduced by the new version. To minimize this impact, you can implement the routing-config parameter of the Lambda alias that allows you to point to two different versions of the Lambda function and dictate what percentage of incoming traffic is sent to each version.

For example, you can specify that only 2 percent of incoming traffic is routed to the new version while you analyze its readiness for a production environment, while the remaining 98 percent is routed to the original version. As the new version matures, you can gradually update the ratio as necessary until you have determined that the new version is stable. You can then update the alias to route all traffic to the new version.

You can point an alias to a maximum of two Lambda function versions. In addition:

– Both versions must have the same IAM execution role.

– Both versions must have the same AWS Lambda Function Dead Letter Queues configuration, or no DLQ configuration.

– When pointing an alias to more than one version, the alias cannot point to $LATEST.

Hence, using Traffic Shifting for Lambda Aliases is the correct answer.

Using Route 53 weighted routing to two Lambda functions is incorrect. Although you may configure 2 different endpoints for your Lambda versions and use Route 53 Weighted Routing, this is still not a manageable and convenient way of handling the failover of your serverless function. The best way is to use Lambda Aliases for the different versions of your function and do traffic shifting on these two versions.

Using ELB to route traffic to both Lambda functions is incorrect because this is not the recommended way to gradually deploy the new version of your Lambda function. It is still best to use Lambda Aliases instead of an Application Load Balancer.

Using stage variables in your Lambda function is incorrect because stage variables are primarily used in API Gateway and not in Lambda. Although this solution may work, you are still required to create an API Gateway and create a stage variable that will point to the new and old versions of the Lambda function. This entails extra configuration, compared with just doing traffic shifting in Lambda.

References:

https://docs.aws.amazon.com/lambda/latest/dg/aliases-intro.html

https://docs.aws.amazon.com/lambda/latest/dg/lambda-traffic-shifting-using-aliases.html

Check out this AWS Lambda Cheat Sheet:

https://tutorialsdojo.com/aws-lambda/

46. QUESTION

A company has a microservices application that must be integrated with API Gateway. The developer must configure custom data mapping between the API Gateway and the microservices.

In addition, the developer must specify how the incoming request data is mapped to the integration request and how the resulting integration response data is mapped to the method response.

Which of the following integration types is the MOST suitable one to use in API Gateway to meet this requirement?

• HTTP_PROXY

• HTTP

• AWS_PROXY

• AWS

Incorrect

You can integrate an API method in your API Gateway with a custom HTTP endpoint of your application in two ways:

– HTTP proxy integration

– HTTP custom integration

In your API Gateway console, you can define the type of HTTP integration of your resource by toggling the “Configure as proxy resource” checkbox.

With proxy integration, the setup is simple. You only need to set the HTTP method and the HTTP endpoint URI, according to the backend requirements, if you are not concerned with content encoding or caching.

With custom integration, setup is more involved. In addition to the proxy integration setup steps, you need to specify how the incoming request data is mapped to the integration request and how the resulting integration response data is mapped to the method response. API Gateway supports the following endpoint ports: 80, 443 and 1024-65535.

Programmatically, you choose an integration type by setting the type property on the Integration resource. For the Lambda proxy integration, the value is AWS_PROXY. For the Lambda custom integration and all other AWS integrations, it is AWS. For the HTTP proxy integration and HTTP integration, the value is HTTP_PROXY and HTTP, respectively. For the mock integration, the type value is MOCK.

Since the integration type that is being described in the scenario fits the definition of an HTTP custom integration, the correct answer in this scenario is to use the HTTP integration type.

Hence, the correct answer is: HTTP.

AWS is incorrect because this type is primarily used for Lambda custom integration. Since the scenario does not specify that the microservices are Lambda functions, the HTTP integration type is the most flexible and suitable for such a scenario.

AWS_PROXY is incorrect because this type is primarily used for Lambda proxy integration. The scenario didn’t mention that it uses a serverless application or Lambda.

HTTP_PROXY is incorrect because this type is only used for HTTP proxy integration where you don’t need to do data mapping for your request and response data.

References:

https://docs.aws.amazon.com/apigateway/latest/developerguide/setup-http-integrations.html

https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-integration-types.html

Check out this Amazon API Gateway Cheat Sheet:

https://tutorialsdojo.com/amazon-api-gateway/

49. QUESTION

A web application is running in an ECS Cluster and updates data in DynamoDB several times a day. The clients retrieve data directly from the DynamoDB through APIs exposed by Amazon API Gateway. Although API caching is enabled, there are specific clients that want to retrieve the latest data from DynamoDB for every API request sent.

What should be done to only allow authorized clients to invalidate an API Gateway cache entry when submitting API requests? (Select TWO.)

• The client must send a request which contains the Cache-Control: max-age=0 header.

• The client must send a request which contains the Cache-Control: max-age=1 header.

• Tick the Require Authorization checkbox in the Cache Settings of your API via the console.

• Modify the cache settings to retrieve the latest data from DynamoDB if the request header's authorization signature matches your API's trusted clients list.

• Provide your clients an authorization token from STS to query data directly from DynamoDB.

Incorrect

A client of your API can invalidate an existing cache entry and reload it from the integration endpoint for individual requests. The client must send a request that contains the Cache-Control: max-age=0 header. The client receives the response directly from the integration endpoint instead of the cache, provided that the client is authorized to do so. This replaces the existing cache entry with the new response, which is fetched from the integration endpoint.

Ticking the Require authorization checkbox ensures that not every client can invalidate the API cache. If most or all of the clients invalidate the API cache, this could significantly increase the latency of your API.

Hence, to only allow authorized clients to invalidate an API Gateway cache entry when submitting API requests, you can just tick the Require Authorization checkbox in the Cache Settings of your API via the console and instruct the client to send a request which contains the Cache-Control: max-age=0 header.

Instructing the client to send a request which contains the Cache-Control: max-age=1 header is incorrect because the value of the max-age should be 0 and not 1.

Providing your clients an authorization token from STS to query data directly from DynamoDB is incorrect because this will not enable your clients to invalidate the cache in API Gateway. Considering that your clients are using APIs to interact with DynamoDB, you should not provide them access to directly submit queries to your table but only through API Gateway.

Modifying the cache settings to retrieve the latest data from DynamoDB if the request header’s authorization signature matches your API’s trusted clients list is incorrect because this configuration can’t be done. There is no feature in API Gateway Cache Settings which would allow you to make a list of authorized signatures that are allowed to invalidate cache entries.

References:

https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-caching.html#invalidate-method-caching

https://aws.amazon.com/api-gateway/faqs/#Throttling_and_Caching

Check out this Amazon API Gateway Cheat Sheet:

https://tutorialsdojo.com/amazon-api-gateway/

52. QUESTION

A DynamoDB table has several top-level attributes such as id, course_id, course_title, price, rating and many others. The database queries of your application returns all of the item attributes by default but you only want to fetch specific attributes such as the course_id and price per request.

As the developer, how can you refactor your application to accomplish this requirement?

• Use condition expressions

• Use expression attribute names

• Use projection expression

• Use filter expressions

Incorrect

To read data from a table, you use operations such as GetItem, Query, or Scan. DynamoDB returns all of the item attributes by default. To get just some, rather than all of the attributes, use a projection expression.

A projection expression is a string that identifies the attributes you want. To retrieve a single attribute, specify its name. For multiple attributes, the names must be comma-separated.

The following AWS CLI example shows how to use a projection expression with a GetItemoperation. This projection expression retrieves a top-level scalar attribute (Description), the first element in a list (RelatedItems[0]), and a list nested within a map (ProductReviews.FiveStar).

aws dynamodb get-item \
    --table-name ProductCatalog \
    --key '{"Id":{"N":"1"}}' \
    --projection-expression "Description, RelatedItems[0], ProductReviews.FiveStar"

You can use any attribute name in a projection expression, provided that the first character is a-z or A-Z and the second character (if present) is a-z, A-Z, or 0-9. If an attribute name does not meet this requirement, you will need to define an expression attribute name as a placeholder.

Therefore, using projection expression is the correct answer in this scenario.

Using condition expressions is incorrect because this is primarily used to determine which items should be modified for data manipulation operations such as PutItem, UpdateItem, and DeleteItem calls.

Using expression attribute names is incorrect because this is a placeholder that you use in a projection expression as an alternative to an actual attribute name. An expression attribute name must begin with a #, and be followed by one or more alphanumeric characters.

Using filter expressions is incorrect because it simply determines which items (and not the attributes) within the Query results should be returned to you. All of the other results are discarded. Take note that the scenario says that you have to fetch specific attributes and not specific items.

References:

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Expressions.ProjectionExpressions.html

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Expressions.html

54. QUESTION

A website is hosted in an Auto Scaling group of EC2 instances behind an Application Load Balancer. It also uses CloudFront with a default domain name to distribute its static assets and dynamic contents. However, the website has a poor search ranking as it doesn’t use a secure HTTPS/SSL on its site.

Which are the possible solutions that the developer can implement in order to set up HTTPS communication between the viewers and CloudFront? (Select TWO.)

• Set the Viewer Protocol Policy to use HTTPS Only.

• Set the Viewer Protocol Policy to use Redirect HTTP to HTTPS.

• Configure the ALB to use its default SSL/TLS certificate.

• Use a self-signed certificate in the ALB.

• Use a self-signed SSL/TLS certificate in the ALB which is stored in a private S3 bucket.

Incorrect

You can configure one or more cache behaviors in your CloudFront distribution to require HTTPS for communication between viewers and CloudFront. You also can configure one or more cache behaviors to allow both HTTP and HTTPS so that CloudFront requires HTTPS for some objects but not for others.

If you’re using the domain name that CloudFront assigned to your distribution, such as dtut0ria1sd0jo.cloudfront.net, you can change the Viewer Protocol Policy setting for one or more cache behaviors to require HTTPS communication by setting it as either Redirect HTTP to HTTPS, or HTTPS Only.

If your origin is an Elastic Load Balancing load balancer, you can use a certificate provided by AWS Certificate Manager (ACM). You can also use a certificate that is signed by a trusted third-party certificate authority and imported into ACM. Note that you can’t use a self-signed certificate for HTTPS communication between CloudFront and your origin.

Hence, setting the Viewer Protocol Policy to use Redirect HTTP to HTTPS and setting the Viewer Protocol Policy to use HTTPS Only are the correct answers in this scenario.

Using a self-signed SSL/TLS certificate in the ALB which is stored in a private S3 bucket is incorrect because you don’t need to add an SSL certificate if you only require HTTPS for communication between the viewers and CloudFront. You should only do this if you require HTTPS between your origin and CloudFront. In addition, you can’t use a self-signed certificate in this scenario even though it is stored in a private S3 bucket. You need to use either a certificate from ACM or a third-party certificate.

Configuring the ALB to use its default SSL/TLS certificate is incorrect because there is no default SSL certificate in ELB, unlike what we have in CloudFront.

Using a self-signed certificate in the ALB is incorrect because adding an SSL certificate in the ELB is not required. Moreover, you can’t use a self-signed certificate in this scenario.

References:

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-cloudfront-to-custom-origin.html#using-https-cloudfront-to-origin-certificate

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html

Check out this Amazon CloudFront Cheat Sheet:

https://tutorialsdojo.com/amazon-cloudfront/

58. QUESTION

A serverless application consisting of Lambda functions integrated with API Gateway, and DynamoDB processes ad hoc requests that its users send. Due to the recent spike in incoming traffic, some of your customers are complaining that they are getting HTTP 504 errors from time to time.

Which of the following is the MOST likely cause of this issue?

• The usage plan quota has been exceeded for the Lambda function.

• An authorization failure occurred between API Gateway and the Lambda function.

• Since the incoming requests are increasing, the API Gateway automatically enabled throttling which caused the HTTP 504 errors.

• API Gateway request has timed out because the underlying Lambda function has been running for more than 29 seconds.

Incorrect

A gateway response is identified by a response type defined by API Gateway. The response consists of an HTTP status code, a set of additional headers that are specified by parameter mappings, and a payload that is generated by a non-VTL (Apache Velocity Template Language) mapping template.

You can set up a gateway response for a supported response type at the API level. Whenever API Gateway returns a response of the type, the header mappings and payload mapping templates defined in the gateway response are applied to return the mapped results to the API caller.

The following are the Gateway response types which are associated with the HTTP 504 error in API Gateway:

INTEGRATION_FAILURE – The gateway response for an integration failed error. If the response type is unspecified, this response defaults to the DEFAULT_5XX type.

INTEGRATION_TIMEOUT – The gateway response for an integration timed out error. If the response type is unspecified, this response defaults to the DEFAULT_5XX type.

For the integration timeout, the range is from 50 milliseconds to 29 seconds for all integration types, including Lambda, Lambda proxy, HTTP, HTTP proxy, and AWS integrations.

In this scenario, there is an issue where the users are getting HTTP 504 errors in the serverless application. This means the Lambda function is working fine at times but there are instances when it throws an error. Based on this analysis, the most likely cause of the issue is the INTEGRATION_TIMEOUT error since you will only get an INTEGRATION_FAILURE error if your AWS Lambda integration does not work at all in the first place.

Hence, the root cause of this issue is that the API Gateway request has timed out because the underlying Lambda function has been running for more than 29 seconds.

The option that says: Since the incoming requests are increasing, the API Gateway automatically enabled throttling which caused the HTTP 504 errors is incorrect because a large number of incoming requests will most likely produce an HTTP 502 or 429 error but not a 504 error. If executing the function would cause you to exceed a concurrency limit at either the account level (ConcurrentInvocationLimitExceeded) or function level (ReservedFunctionConcurrentInvocationLimitExceeded), Lambda may return a TooManyRequestsException as a response. For functions with a long timeout, your client might be disconnected during synchronous invocation while it waits for a response and returns an HTTP 504 error.

The option that says: An authorization failure occurred between API Gateway and the Lambda function is incorrect because an authentication issue usually produces HTTP 403 errors and not 504s. The gateway response for authorization failures for missing authentication token error, invalid AWS signature error, or Amazon Cognito authentication problems is HTTP 403, which is why this option is unlikely to be the cause of this issue.

The option that says: The usage plan quota has been exceeded for the Lambda function is incorrect. Although this is a possible root cause for this scenario, this option has the least chance to produce HTTP 504 errors. The scenario says that the issue happens from time to time and not all the time which suggests that this happens intermittently. If the usage plan indeed exceeded the quota, then the 504 error should always show up and not just from time to time.

References:

https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html

https://aws.amazon.com/about-aws/whats-new/2017/11/customize-integration-timeouts-in-amazon-api-gateway/

https://docs.aws.amazon.com/apigateway/latest/developerguide/supported-gateway-response-types.html

Check out this API Gateway Cheat Sheet:

https://tutorialsdojo.com/amazon-api-gateway/

62. QUESTION

An application, which already uses X-Ray, generates thousands of trace data every hour. The developer wants to use a filter expression that will limit the results based on custom attributes or keys that he specifies.

How should the developer refactor the application in order to filter the results in the X-Ray console?

• Include the custom attributes as new segment fields in the segment document.

• Add the custom attributes as metadata in your segment document.

• Add the custom attributes as annotations in your segment document.

• Create a new sampling rule based on the custom attributes.

Incorrect

Even with sampling, a complex application generates a lot of data. The AWS X-Ray console provides an easy-to-navigate view of the service graph. It shows health and performance information that helps you identify issues and opportunities for optimization in your application. For advanced tracing, you can drill down to traces for individual requests or use filter expressions to find traces related to specific paths or users.

When you instrument your application, the X-Ray SDK records information about incoming and outgoing requests, the AWS resources used, and the application itself. You can add other information to the segment document as annotations and metadata.

Annotations are simple key-value pairs that are indexed for use with filter expressions. Use annotations to record data that you want to use to group traces in the console, or when calling the GetTraceSummaries API. X-Ray indexes up to 50 annotations per trace.

Metadata are key-value pairs with values of any type, including objects and lists, but that are not indexed. Use metadata to record data you want to store in the trace but don’t need to use for searching traces. You can view annotations and metadata in the segment or subsegment details in the X-Ray console.

Hence, adding the custom attributes as annotations in your segment document is the correct answer.

Including the custom attributes as new segment fields in the segment document is incorrect because a segment field can’t be used as a filter expression. You have to add the custom attributes as annotations to the segment document that you’ll send to X-Ray, just as mentioned above.

Creating a new sampling rule based on the custom attributes is incorrect because sampling is primarily used to ensure efficient tracing and to provide a representative sample of the requests that your application serves.

Adding the custom attributes as metadata in your segment document is incorrect because metadata is primarily used to record custom data that you want to store in the trace but not for searching traces.

References:

https://docs.aws.amazon.com/xray/latest/devguide/xray-concepts.html#xray-concepts-annotations

https://docs.aws.amazon.com/xray/latest/devguide/xray-console-filters.html

Check out this AWS X-Ray Cheat Sheet:

https://tutorialsdojo.com/aws-x-ray/

65. QUESTION

A serverless application is composed of several Lambda functions which reads data from RDS. These functions must share the same connection string that should be encrypted to improve data security.

Which of the following is the MOST secure way to meet the above requirement?

• Create an IAM Execution Role that has access to RDS and attach it to the Lambda functions.

• Use AWS Lambda environment variables encrypted with KMS which will be shared by the Lambda functions.

• Use AWS Lambda environment variables encrypted with CloudHSM.

• Create a Secure String Parameter using the AWS Systems Manager Parameter Store.

Incorrect

AWS Systems Manager Parameter Store provides secure, hierarchical storage for configuration data management and secrets management. You can store data such as passwords, database strings, and license codes as parameter values. You can store values as plain text or encrypted data. You can then reference values by using the unique name that you specified when you created the parameter.

Parameter Store offers the following benefits and features:

– Use a secure, scalable, hosted secrets management service (No servers to manage).

– Improve your security posture by separating your data from your code.

– Store configuration data and secure strings in hierarchies and track versions.

– Control and audit access at granular levels.

– Configure change notifications and trigger automated actions.

– Tag parameters individually, and then secure access from different levels, including operational, parameter, Amazon EC2 tag, or path levels.

– Reference AWS Secrets Manager secrets by using Parameter Store parameters.

Hence, creating a Secure String Parameter using the AWS Systems Manager Parameter Store is the correct solution for this scenario.

The option that says: Use AWS Lambda environment variables encrypted with KMS which will be shared by the Lambda functions is incorrect. Even though the credentials will be encrypted, these environment variables will only be used by an individual Lambda function, and cannot be shared.

The option that says: Create an IAM Execution Role that has access to RDS and attach it to the Lambda functions is incorrect because this solution will not encrypt the database credentials for RDS.

The option that says: Use AWS Lambda environment variables encrypted with CloudHSM is incorrect because Lambda primarily uses KMS for encryption and not CloudHSM.

References:

https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-paramstore.html

https://aws.amazon.com/blogs/compute/sharing-secrets-with-aws-lambda-using-aws-systems-manager-parameter-store/

Check out this AWS Systems Manager Cheat Sheet:

https://tutorialsdojo.com/aws-systems-manager/