Correct option:

Increase the amount of memory available to the Lambda functions

AWS Lambda lets you run code without provisioning or managing servers. You pay only for the compute time you consume.

In the AWS Lambda resource model, you choose the amount of memory you want for your function which allocates proportional CPU power and other resources. This means you will have access to more compute power when you choose one of the new larger settings. You can set your memory in 64MB increments from 128MB to 3008MB. You access these settings when you create a function or update its configuration. The settings are available using the AWS Management Console, AWS CLI, or SDKs.

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

Therefore, by increasing the amount of memory available to the Lambda functions, you can run the compute-heavy workflows.

Incorrect options:

Invoke the Lambda functions asynchronously to process the compute-heavy workflows - When you invoke a function asynchronously, you don't wait for a response from the function code. You hand off the event to Lambda and Lambda handles the rest. You can configure how Lambda handles errors and can send invocation records to a downstream resource to chain together components of your application. The method of invocation has no bearing on the Lambda function's ability to process the compute-heavy workflows.

Use reserved concurrency to account for the compute-heavy workflows

Use provisioned concurrency to account for the compute-heavy workflows

Concurrency is the number of requests that your function is serving at any given time. When your function is invoked, Lambda allocates an instance of it to process the event. When the function code finishes running, it can handle another request. If the function is invoked again while a request is still being processed, another instance is allocated, which increases the function's concurrency. The type of concurrency has no bearing on the Lambda function's ability to process the compute-heavy workflows. So both these options are incorrect.

Reference:

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

Correct option:

Move the Amazon S3 client initialization, out of your function handler - AWS best practices for Lambda suggest taking advantage of execution context reuse to improve the performance of your functions. Initialize SDK clients and database connections outside of the function handler, and cache static assets locally in the /tmp directory. Subsequent invocations processed by the same instance of your function can reuse these resources. This saves execution time and cost. To avoid potential data leaks across invocations, don’t use the execution context to store user data, events, or other information with security implications.

Incorrect options:

Use environment variables to pass operational parameters - This is one of the suggested best practices for Lambda. By using environment variables to pass operational parameters you can avoid hard-coding useful information. But, this is not the right answer for the current use-case, since it talks about reusing context.

Assign more RAM to the function - Increasing RAM will help speed up the process. But, in the current question, the reviewer has specifically mentioned about reusing context. Hence, this is not the right answer.

Enable X-Ray integration - You can use AWS X-Ray to visualize the components of your application, identify performance bottlenecks, and troubleshoot requests that resulted in an error. Your Lambda functions send trace data to X-Ray, and X-Ray processes the data to generate a service map and searchable trace summaries. This is a useful tool for troubleshooting. But, for the current use-case, we already know the bottleneck that needs to be fixed and that is the context reuse.

References:

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

https://docs.aws.amazon.com/lambda/latest/dg/services-xray.h

Correct option:

Enable X-Ray Sampling - By customizing sampling rules, you can control the amount of data that you record, and modify sampling behavior on the fly without modifying or redeploying your code. Sampling rules tell the X-Ray SDK how many requests to record for a set of criteria. By default, the X-Ray SDK records the first request each second, and five percent of any additional requests.

Incorrect options:

Send only the required data from client-side - Theoretically, it is possible to filter out unwanted data and send only what is deemed necessary. But, this requires custom code changes and management overhead of tracking and maintaining the code through its life cycle. So, this option is not an optimal solution for the current scenario.

Custom configuration of the X-Ray agents - Such a custom configuration is not possible and this option is an invalid one, given only as a distractor.

Enable X-Ray Deep linking to send only the most useful data to X-Ray - The AWS X-Ray console enables you to view service maps and traces for requests that your applications serve. The console's service map is a visual representation of the JSON service graph that X-Ray generates from the trace data generated by your applications. Deep linking refers to the use of routes and queries to deep-link into specific traces or filtered views of traces and the service map. This is not a useful feature for the current scenario.

References:

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

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

Correct option:

The Load Balancer does not have stickiness enabled - Sticky sessions are a mechanism to route requests to the same target in a target group. This is useful for servers that maintain state information to provide a continuous experience to clients. To use sticky sessions, the clients must support cookies.

When a load balancer first receives a request from a client, it routes the request to a target, generates a cookie named AWSALB that encodes information about the selected target, encrypts the cookie, and includes the cookie in the response to the client. The client should include the cookie that it receives in subsequent requests to the load balancer. When the load balancer receives a request from a client that contains the cookie, if sticky sessions are enabled for the target group and the request goes to the same target group, the load balancer detects the cookie and routes the request to the same target.

More info here: 

via - https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#sticky-sessions

Incorrect options:

Application Load Balancer is in slow-start mode, which gives ALB a little more time to read and write session data - This is an invalid statement. The load balancer serves as a single point of contact for clients and distributes incoming traffic across its healthy registered targets. By default, a target starts to receive its full share of requests as soon as it is registered with a target group and passes an initial health check. Using slow start mode gives targets time to warm up before the load balancer sends them a full share of requests. This does not help in session management.

The EC2 instances are logging out the users because the instances never have access to the client IPs because of the Load Balancer - This is an incorrect statement. Elastic Load Balancing stores the IP address of the client in the X-Forwarded-For request header and passes the header to the server. If needed, the server can read IP addresses from this data.

The Load Balancer does not have TLS enabled - To use an HTTPS listener, you must deploy at least one SSL/TLS server certificate on your load balancer. The load balancer uses a server certificate to terminate the front-end connection and then decrypt requests from clients before sending them to the targets. This does not help in session management.

References:

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#sticky-sessions

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#slow-start-mode

Correct option:

Opt for Blue/Green deployment - A Blue/Green deployment is used to update your applications while minimizing interruptions caused by the changes of a new application version. CodeDeploy provisions your new application version alongside the old version before rerouting your production traffic. The behavior of your deployment depends on which compute platform you use:

1. AWS Lambda: Traffic is shifted from one version of a Lambda function to a new version of the same Lambda function.
2. Amazon ECS: Traffic is shifted from a task set in your Amazon ECS service to an updated, replacement task set in the same Amazon ECS service.
3. EC2/On-Premises: Traffic is shifted from one set of instances in the original environment to a replacement set of instances.

Incorrect options:

Opt for Rolling deployment - This deployment type is present for AWS Elastic Beanstalk and not for EC2 instances directly.

Opt for Immutable deployment - This deployment type is present for AWS Elastic Beanstalk and not for EC2 instances directly.

Opt for In-place deployment - Under this deployment type, the application on each instance in the deployment group is stopped, the latest application revision is installed, and the new version of the application is started and validated. You can use a load balancer so that each instance is deregistered during its deployment and then restored to service after the deployment is complete.

References:

https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green

https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments.html

Correct option:

"Cognito Identity Pools"

Amazon Cognito identity pools provide temporary AWS credentials for users who are guests (unauthenticated) and for users who have been authenticated and received a token. Identity pools provide AWS credentials to grant your users access to other AWS services.

Cognito Overview:

via - https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html

Incorrect options:

"Cognito User Pools" - AWS Cognito User Pools is there to authenticate users for your applications which looks similar to Cognito Identity Pools. The difference is that Identity Pools allows a way to authorize your users to use the various AWS services and User Pools is not about authorizing to AWS services but to provide add sign-up and sign-in functionality to web and mobile applications.

"Cognito Sync" - You can use it to synchronize user profile data across mobile devices and the web without requiring your own backend. The client libraries cache data locally so your app can read and write data regardless of device connectivity status.

"IAM" - This is not a good solution because it would require you to have an IAM user for each mobile device which is not a good practice or manageable way of handling deployment.

Exam Alert:

Please review the following note to understand the differences between Cognito User Pools and Cognito Identity Pools:

via - https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html

Reference:

https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html

Correct option:

Use client-side encryption with an AWS KMS managed customer master key (CMK)

You have the following options for protecting data at rest in Amazon S3:

Server-Side Encryption – Request Amazon S3 to encrypt your object before saving it on disks in its data centers and then decrypt it when you download the objects.

Client-Side Encryption – Encrypt data client-side and upload the encrypted data to Amazon S3. In this case, you manage the encryption process, the encryption keys, and related tools.

As the company wants to make sure that the files are encrypted before they are sent to Amazon S3, therefore you should use client-side encryption.

To enable client-side encryption, you have the following options:

Use a customer master key (CMK) stored in AWS Key Management Service (AWS KMS).

Use a master key you store within your application.

As the use-case mentions that the encryption keys need to be managed by an in-house security team but the key itself should be stored on AWS, therefore you must use the customer master key (CMK) stored in AWS Key Management Service (AWS KMS).

Incorrect options:

Use client-side encryption with Amazon S3 managed key - As mentioned earlier in the explanation, to meet the requirements of the given use-case, the company must use a customer master key (CMK) stored in AWS Key Management Service (AWS KMS).

Also, there is no such thing as "client-side encryption with Amazon S3 managed key" as explained above.

Use server-side encryption with a customer-provided encryption key (SSE-C)

Use server-side encryption with a client-side master key

Both these options are incorrect as the use-case mandates client-side encryption.

Reference:

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

Correct options:

All the nodes in a Redis cluster must reside in the same region

All the nodes in a Redis cluster (cluster mode enabled or cluster mode disabled) must reside in the same region.

While using Redis with cluster mode enabled, you cannot manually promote any of the replica nodes to primary

While using Redis with cluster mode enabled, there are some limitations:

1. You cannot manually promote any of the replica nodes to primary.
2. Multi-AZ is required.
3. You can only change the structure of a cluster, the node type, and the number of nodes by restoring from a backup.

Incorrect options:

While using Redis with cluster mode enabled, asynchronous replication mechanisms are used to keep the read replicas synchronized with the primary. If cluster mode is disabled, the replication mechanism is done synchronously - When you add a read replica to a cluster, all of the data from the primary is copied to the new node. From that point on, whenever data is written to the primary, the changes are asynchronously propagated to all the read replicas, for both the Redis offerings (cluster mode enabled or cluster mode disabled).

If you have no replicas and a node fails, you experience no loss of data when using Redis with cluster mode enabled - If you have no replicas and a node fails, you experience loss of all data in that node's shard, when using Redis with cluster mode enabled. If you have no replicas and the node fails, you experience total data loss in Redis with cluster mode disabled.

You can scale write capacity for Redis by adding replica nodes - This increases only the read capacity of the Redis cluster, write capacity is not enhanced by read replicas.

Reference:

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html

Correct option:

CloudWatch Events Rules with AWS Lambda

You can create a Lambda function and direct CloudWatch Events to execute it on a regular schedule. You can specify a fixed rate (for example, execute a Lambda function every hour or 15 minutes), or you can specify a Cron expression.

CloudWatch Events Key Concepts:

via - https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html

Schedule Expressions for CloudWatch Events Rules:

via - https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/ScheduledEvents.html

Incorrect options:

AWS Lambda Custom Sources - This is a made-up option and has been added as a distractor.

Open a support ticket with AWS - You can, although the AWS support team will not add a custom configuration for you, they will step you through creating event rule with Lambda.

Cron jobs to trigger AWS Lambda to check the state of your service - You would need an additional server for your cron job instead you should consider using a cron expression with CloudWatch.

References:

https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html

https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/ScheduledEvents.html

Correct option:

The bucket owner also needs to be object owner to get the object access logs

If the bucket owner is also the object owner, the bucket owner gets the object access logs. Otherwise, the bucket owner must get permissions, through the object ACL, for the same object API to get the same object-access API logs.

Incorrect options:

CloudTrail always delivers object-level API access logs to the requester and not to object owner - CloudTrail always delivers object-level API access logs to the requester. In addition, CloudTrail also delivers the same logs to the bucket owner only if the bucket owner has permissions for the same API actions on that object.

CloudTrail needs to be configured on both the AWS accounts for receiving the access logs in cross-account access

The meta-data of the bucket is in an invalid state and needs to be corrected by the bucket owner from AWS console to fix the issue

These two options are incorrect and are given only as distractors.

Reference:

https://docs.aws.amazon.com/AmazonS3/latest/userguide/cloudtrail-logging-s3-info.html#cloudtrail-object-level-crossaccount