Correct option:

Amazon CloudWatch Events delivers a near real-time stream of system events that describe changes in Amazon Web Services (AWS) resources. Using simple rules that you can quickly set up, you can match events and route them to one or more target functions or streams.

CloudWatch Events Key Concepts:

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

Set up an Amazon CloudWatch Events rule that uses CodePipeline as an event source with the target as the Lambda function

You can use Amazon CloudWatch Events to detect and react to changes in the state of a pipeline, stage, or action. Then, based on rules you create, CloudWatch Events invokes one or more target actions when a pipeline, stage, or action enters the state you specify in a rule. For the given use-case, you can set up a rule that detects pipeline changes and invokes an AWS Lambda function.

Amazon CloudWatch Events With CodePipeline:

https://docs.aws.amazon.com/codepipeline/latest/userguide/detect-state-changes-cloudwatch-events.html

Incorrect options:

Set up an Amazon CloudWatch alarm that monitors status changes in Code Pipeline and triggers the Lambda function - As mentioned in the explanation above, you need to use a CloudWatch event and not CloudWatch alarm for this use-case.

Use the Lambda console to configure a trigger that invokes the Lambda function with CodePipeline as the event source - You cannot create a trigger with CodePipeline as the event source via the Lambda Console.

Use the CodePipeline console to set up a trigger for the Lambda function - CodePipeline console cannot be used to configure a trigger for a Lambda function.

References:

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

https://docs.aws.amazon.com/codepipeline/latest/userguide/detect-state-changes-cloudwatch-events.html

Correct option:

Amazon ElastiCache allows you to seamlessly set up, run, and scale popular open-Source compatible in-memory data stores in the cloud. Build data-intensive apps or boost the performance of your existing databases by retrieving data from high throughput and low latency in-memory data stores. Amazon ElastiCache is a popular choice for real-time use cases like Caching, Session Stores, Gaming, Geospatial Services, Real-Time Analytics, and Queuing.

Broadly, you can set up two types of caching strategies:

1. Lazy Loading
2. Write-Through

via - https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/Strategies.html

via - https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/Strategies.html

Use a caching strategy to write to the backend first and then invalidate the cache

This option is similar to the write-through strategy wherein the application writes to the backend first and then invalidate the cache. As the cache gets invalidated, the caching engine would then fetch the latest value from the backend, thereby making sure that the product prices and product description stay consistent with the backend.

Incorrect options:

Use a caching strategy to update the cache and the backend at the same time - The cache and the backend cannot be updated at the same time via a single atomic operation as these are two separate systems. Therefore this option is incorrect.

Use a caching strategy to write to the backend first and wait for the cache to expire via TTL - This strategy could work if the TTL is really short. However, for the duration of this TTL, the cache would be out of sync with the backend, hence this option is not correct for the given use-case.

Use a caching strategy to write to the cache directly and sync the backend at a later time - This option is given as a distractor as this strategy is not viable to address the given use-case. The product prices and description on the cache must always stay consistent with the backend. You cannot sync the backend at a later time.

Reference:

https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/Strategies.html

Correct option

Use a Lazy Loading strategy with TTL

Lazy loading is a caching strategy that loads data into the cache only when necessary. Whenever your application requests data, it first requests the ElastiCache cache. If the data exists in the cache and is current, ElastiCache returns the data to your application. If the data doesn't exist in the cache or has expired, your application requests the data from your data store. Your datastore then returns the data to your application.

In this case, data that is actively requested by users will be cached in ElastiCache, and thanks to the TTL, we can expire that data after a minute to limit the data staleness.

via - https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/Strategies.html#Strategies.LazyLoading

Incorrect option:

Use a Lazy Loading strategy without TTL - This fits the read requirements, but won't help expiring stale data, so we need TTL.

Use a Write Through strategy with TTL

Use a Write Through strategy without TTL

The problem with these two options for the write-through strategy is that we would fill up the cache with unnecessary data and as mentioned in the question we don't have enough space in the cache to fit all the dataset. Therefore we can't use a write-through strategy.

Reference:

https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/Strategies.html#Strategies.LazyLoading

Correct option:

S3ReadPolicy

The AWS Serverless Application Model (AWS SAM) is an open-source framework that you can use to build serverless applications on AWS.

A serverless application is a combination of Lambda functions, event sources, and other resources that work together to perform tasks. Note that a serverless application is more than just a Lambda function—it can include additional resources such as APIs, databases, and event source mappings.

AWS SAM allows you to choose from a list of policy templates to scope the permissions of your Lambda functions to the resources that are used by your application.

AWS SAM applications in the AWS Serverless Application Repository that use policy templates don't require any special customer acknowledgments to deploy the application from the AWS Serverless Application Repository.

S3ReadPolicy => Gives read-only permission to objects in an Amazon S3 bucket.

S3CrudPolicy => Gives create, read, update, and delete permission to objects in an Amazon S3 bucket.

SQSPollerPolicy => Permits to poll an Amazon SQS Queue.

LambdaInvokePolicy => Permits to invoke a Lambda function, alias, or version.

Incorrect options:

SQSPollerPolicy

S3CrudPolicy

LambdaInvokePolicy

These three options contradict the explanation provided earlier. So these are incorrect.

Reference:

https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-policy-templates.html

Correct answer

Create a bucket policy

Bucket policy is an access policy option available for you to grant permission to your Amazon S3 resources. It uses JSON-based access policy language.

If you want to configure an existing bucket as a static website that has public access, you must edit block public access settings for that bucket. You may also have to edit your account-level block public access settings.

via - https://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteHosting.html

Incorrect:

Create an IAM role - This will not help because IAM roles are attached to services and in this case, we have public users.

Enable CORS - CORS defines a way for client web applications that are loaded in one domain to interact with resources in a different domain. Here we are not dealing with cross domains.

Enable Encryption - For the most part, encryption does not have an effect on access denied/forbidden errors. On the website endpoint, if a user requests an object that doesn't exist, Amazon S3 returns HTTP response code 404 (Not Found). If the object exists but you haven't granted read permission on it, the website endpoint returns HTTP response code 403 (Access Denied).

References:

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

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

Correct option:

aws ecs create-service --service-name ecs-simple-service --task-definition ecs-demo --desired-count 10

To create a new service you would use this command which creates a service in your default region called ecs-simple-service. The service uses the ecs-demo task definition and it maintains 10 instantiations of that task.

Incorrect options:

aws ecr create-service --service-name ecs-simple-service --task-definition ecs-demo --desired-count 10 - This command is referencing a different service called Amazon Elastic Container Registry (ECR) which's is a fully-managed Docker container registry

docker-compose create ecs-simple-service - This is a docker command to create containers for a service.

aws ecs run-task --cluster default --task-definition ecs-demo - This is a valid command but used for starting a new task using a specified task definition.

Reference:

https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html

Correct option:

Route 53 is a DNS managed by AWS, but nothing prevents you from running your own DNS (it's just a software) on an EC2 instance. The trick of this question is that it's about EC2, running some software that needs a fixed IP, and not about Route 53 at all.

Elastic IP

DNS services are identified by a public IP, so you need to use Elastic IP.

Incorrect options:

Create a Load Balancer and an auto-scaling group - Load balancers do not provide an IP, instead they provide a DNS name, so this option is ruled out.

Provide a static private IP - If you provide a private IP it will not be accessible from the internet, so this option is incorrect.

Use Route 53 - Route 53 is a DNS service from AWS but the use-case talks about offering a DNS service using an EC2 instance, so this option is incorrect.

Reference:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html#using-instance-addressing-eips-associating-different

Correct option:

AWS X-Ray helps developers analyze and debug production, distributed applications, such as those built using a microservices architecture. With X-Ray, you can understand how your application and its underlying services are performing to identify and troubleshoot the root cause of performance issues and errors. X-Ray provides an end-to-end view of requests as they travel through your application, and shows a map of your application’s underlying components.

How X-Ray Works:

via - https://aws.amazon.com/xray/

Create a role in the target unified account and allow roles in each sub-account to assume the role

Configure the X-Ray daemon to use an IAM instance role

The X-Ray agent can assume a role to publish data into an account different from the one in which it is running. This enables you to publish data from various components of your application into a central account.

X-Ray can also track requests flowing through applications or services across multiple AWS Regions.

via - https://aws.amazon.com/xray/faqs/

You can create the necessary configurations for cross-account access via this reference documentation - https://docs.aws.amazon.com/xray/latest/devguide/xray-daemon-configuration.html

Incorrect options:

Create a user in the target unified account and generate access and secret keys

Configure the X-Ray daemon to use access and secret keys

These two options combined together would work but wouldn't be a best-practice security-wise. Therefore these are not correct.

Enable Cross Account collection in the X-Ray console - This is a made-up option and has been added as a distractor.

References:

https://aws.amazon.com/xray/faqs/

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

Correct option:

Specify a KMS key to use

AWS Key Management Service (KMS) makes it easy for you to create and manage cryptographic keys and control their use across a wide range of AWS services and in your applications.

For AWS CodeBuild to encrypt its build output artifacts, it needs access to an AWS KMS customer master key (CMK). By default, AWS CodeBuild uses the AWS-managed CMK for Amazon S3 in your AWS account. The following environment variable provides these details:

CODEBUILD_KMS_KEY_ID: The identifier of the AWS KMS key that CodeBuild is using to encrypt the build output artifact (for example, arn:aws:kms:region-ID:account-ID:key/key-ID or alias/key-alias).

Incorrect options:

Use an AWS Lambda Hook - Code hook is used for integration with Lambda and is not relevant for the given use-case.

Use the AWS Encryption SDK - The SDK just makes it easier for you to implement encryption best practices in your application and is not relevant for the given use-case.

Use In-Flight encryption (SSL) - SSL is usually for internet traffic which in this case will be using internal traffic through AWS and is not relevant for the given use-case.

References:

https://docs.aws.amazon.com/codebuild/latest/userguide/build-env-ref-env-vars.html

https://docs.aws.amazon.com/codebuild/latest/userguide/setting-up.html

Correct option:

Develop the SAM template locally => upload the template to S3 => deploy your application to the cloud

The AWS Serverless Application Model (SAM) is an open-source framework for building serverless applications. It provides shorthand syntax to express functions, APIs, databases, and event source mappings. With just a few lines per resource, you can define the application you want and model it using YAML.

You can develop and test your serverless application locally, and then you can deploy your application by using the sam deploy command. The sam deploy command zips your application artifacts, uploads them to Amazon Simple Storage Service (Amazon S3), and deploys your application to the AWS Cloud. AWS SAM uses AWS CloudFormation as the underlying deployment mechanism.

via - https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-deploying.html

Incorrect options:

Develop the SAM template locally => upload the template to Lambda => deploy your application to the cloud

Develop the SAM template locally => upload the template to CodeCommit => deploy your application to CodeDeploy

Develop the SAM template locally => deploy the template to S3 => use your application in the cloud

These three options contradict the details provided in the explanation above, so these are incorrect.

Reference:

https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-deploying.html