Correct option:

Create a dedicated or hosted connection. Establish a cross-network connection and then create a public virtual interface for your connection. Configure an end router for use with the public virtual interface

It's not possible to directly access an S3 bucket through a private virtual interface (VIF) using Direct Connect. This is true even if you have an Amazon Virtual Private Cloud (Amazon VPC) endpoint for Amazon S3 in your VPC because VPC endpoint connections can't extend outside of a VPC. Additionally, Amazon S3 resolves to public IP addresses, even if you enable a VPC endpoint for Amazon S3.

However, you can establish access to Amazon S3 using Direct Connect by following these steps (This configuration doesn't require a VPC endpoint for Amazon S3, because traffic doesn't traverse the VPC):

1.Create a connection. You can request a dedicated connection or a hosted connection.

2.Establish a cross-network connection with the help of your network provider, and then create a public virtual interface for your connection.

3.Configure an end router for use with the public virtual interface.

After the BGP is up and established, the Direct Connect router advertises all global public IP prefixes, including Amazon S3 prefixes. Traffic heading to Amazon S3 is routed through the Direct Connect public virtual interface through a private network connection between AWS and your data center or corporate network.

Incorrect options:

Directly access the S3 bucket through a private virtual interface (VIF) using Direct Connect - Private virtual interface allows access to an Amazon VPC using private IP addresses. It's not possible to directly access an S3 bucket through a private virtual interface (VIF) using Direct Connect.

Create a VPC gateway endpoint for the S3 bucket you need to access. Then use private virtual interface (VIF) using Direct Connect to access the bucket - VPC endpoint connections can't extend outside of a VPC. Additionally, Amazon S3 resolves to public IP addresses, even if you enable a VPC endpoint for Amazon S3.

Create a VPC interface endpoint for the S3 bucket you need to access. Then use private virtual interface (VIF) using Direct Connect to access the bucket - VPC interface endpoint is not used for accessing Amazon S3 buckets, we need to use VPC gateway endpoint. As discussed above, VPC endpoint connections can't extend outside of a VPC. Additionally, Amazon S3 resolves to public IP addresses, even if you enable a VPC endpoint for Amazon S3.

Reference:

https://aws.amazon.com/premiumsupport/knowledge-center/s3-bucket-access-direct-connect/

Correct option:

Use AWS Command Line Interface (AWS CLI) to permanently delete a secret without any recovery window, run the DeleteSecret API call with the ForceDeleteWithoutRecovery parameter

When you delete a secret, the Secrets Manager deprecates it with a seven-day recovery window. This means that you can't recreate a secret using the same name using the AWS Management Console until seven days have passed. You can permanently delete a secret without any recovery window using the AWS Command Line Interface (AWS CLI).

Run the DeleteSecret API call with the ForceDeleteWithoutRecovery parameter to delete the secret permanently. If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI. Secrets deleted using the ForceDeleteWithoutRecovery parameter can't be recovered or restored.

Incorrect options:

Use AWS Management Console to delete the key permanently. You will be allowed to create a new key with the same name after the older one is successfully deleted - When you delete a secret, Secrets Manager deprecates it with a seven-day recovery window. This means that you can't recreate a secret using the same name using the AWS Management Console until seven days have passed.

When you delete a secret, the Secrets Manager deprecates it with a seven-day recovery window. It is not possible to create a new secret with the same name for this duration - This statement is true, but the secret can be deleted from CLI, and hence this option is incorrect.

The secret key deletion is an asynchronous process. There might be a short delay before updates are received. Try after few minutes for successful completion - This is a made-up option, given only as a distractor.

Reference:

https://aws.amazon.com/premiumsupport/knowledge-center/delete-secrets-manager-secret/

Correct options:

When you apply a retention period to an object version explicitly, you specify a Retain Until Date for the object version - You can place a retention period on an object version either explicitly or through a bucket default setting. When you apply a retention period to an object version explicitly, you specify a Retain Until Date for the object version. Amazon S3 stores the Retain Until Date setting in the object version's metadata and protects the object version until the retention period expires.

Different versions of a single object can have different retention modes and periods - Like all other Object Lock settings, retention periods apply to individual object versions. Different versions of a single object can have different retention modes and periods.

For example, suppose that you have an object that is 15 days into a 30-day retention period, and you PUT an object into Amazon S3 with the same name and a 60-day retention period. In this case, your PUT succeeds, and Amazon S3 creates a new version of the object with a 60-day retention period. The older version maintains its original retention period and becomes deletable in 15 days.

Incorrect options:

You cannot place a retention period on an object version through a bucket default setting - You can place a retention period on an object version either explicitly or through a bucket default setting.

When you use bucket default settings, you specify a Retain Until Date for the object version - When you use bucket default settings, you don't specify a Retain Until Date. Instead, you specify a duration, in either days or years, for which every object version placed in the bucket should be protected.

The bucket default settings will override any explicit retention mode or period you request on an object version - If your request to place an object version in a bucket contains an explicit retention mode and period, those settings override any bucket default settings for that object version.

Reference:

https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lock-overview.html

Correct option:

Create a DB snapshot of your existing DB instance and create a new instance from the restored snapshot. Initiate a version upgrade on this new instance and safely experiment with the instance

You can trial test the new version before opting it for production systems. To do so, create a DB snapshot of your existing DB instance, restore from the DB snapshot to create a new DB instance, and then initiate a version upgrade for the new DB instance. You can then experiment safely on the upgraded copy of your DB instance before deciding whether or not to upgrade your original DB instance.

Incorrect options:

Create a configuration similar to the one in production using CloudFormation templates. You can reuse these templates to create any number of instances whenever required - CloudFormation templates help in creating resources with the same configuration multiple times, in multiple AWS accounts, if needed. The given use-case requires an exact copy of the existing production database to trial test and CloudFormation cannot help in this scenario.

Create a read replica of the RDS instance in production. Upgrade the read replica to the latest version and experiment with this instance

Procure an instance that has the new version of the database engine. Take the snapshot of your existing database and restore the snapshot to this instance. Test on this instance

These two options are incorrect because to trial test a production database, we need a running database, in the same status as the existing one. This running database instance will be upgraded and then tested thoroughly to know its viability for production. The read replica operates as a DB instance that allows just read-only connections. Applications can connect to a read replica just as they would to any DB instance. The order of activities should be exactly the way it will be in production, so the upgrade goes smoothly without any glitches when done on the live system.

Reference:

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

Correct option:

Use 'Export' field in the Output section of the stack's template

To share information between stacks, export a stack's output values. Other stacks that are in the same AWS account and region can import the exported values.

To export a stack's output value, use the Export field in the Output section of the stack's template. To import those values, use the Fn::ImportValue function in the template for the other stacks.

Incorrect options:

Use 'Expose' field in the Output section of the stack's template - 'Expose' is a made-up option, and only given as a distractor.

Use Fn::ImportValue - To import the values exported by another stack, we use the Fn::ImportValue function in the template for the other stacks. This function is not useful for the current scenario.

Use Fn::Transform - The intrinsic function Fn::Transform specifies a macro to perform custom processing on part of a stack template. Macros enable you to perform custom processing on templates, from simple actions like find-and-replace operations to extensive transformations of entire templates. This function is not useful for the current scenario.

Reference:

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-exports.html

Correct option:

Queue name of the SQS queue should be used to fetch the necessary data from CloudWatch metrics

Amazon SQS sends a number of metrics to CloudWatch, some of which are ApproximateAgeOfOldestMessage, ApproximateNumberOfMessagesDelayed, NumberOfMessagesDeleted and so on. Some metrics are calculated from a service perspective and can include retries. AWS suggests not to rely on the absolute values of these metrics, or use them to estimate current queue status.

The only dimension that Amazon SQS sends to CloudWatch is QueueName. This means that all available statistics are filtered by QueueName.

Incorrect options:

Queue ID should be used to fetch the SQS queue data from the CloudWatch metrics

A key-value pair of name:<queue name> and value:<value> needs to be considered for fetching SQS queue data from CloudWatch metrics

A composite key Queue Name - Queue ID is used to fetch SQS queue data from CloudWatch metrics

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

Reference:

https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html

Correct options:

A delete marker is set on the deleted object, but the actual object is not deleted - A delete marker in Amazon S3 is a placeholder (or marker) for a versioned object that was named in a simple DELETE request. Because the object is in a versioning-enabled bucket, the object is not deleted. But the delete marker makes Amazon S3 behave as if it is deleted. A delete marker has a key name (or key) and version ID like any other object. It does not have data associated with it. It is not associated with an access control list (ACL) value.

GET requests do not retrieve delete marker objects - The only way to list delete markers (and other versions of an object) is by using the versions subresource in a GET Bucket versions request. A simple GET does not retrieve delete marker objects.

What Delete Markers are:

https://docs.aws.amazon.com/AmazonS3/latest/userguide/DeleteMarker.html

Incorrect options:

GET requests can retrieve delete marker objects

A delete marker has a key, version ID and Access Control List (ACL) associated with it

The delete marker has the same data associated with it, as the actual object

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

Reference:

https://docs.aws.amazon.com/AmazonS3/latest/userguide/DeleteMarker.html

Correct option:

Create a backup plan in AWS Backup. Assign tags to resources based on the environment ( Production, Development, Testing). Create one backup policy for production environments and one backup policy for non-production environments. Schedule the backup plan based on the organization's backup policies

AWS Backup is a fully managed and cost-effective backup service that simplifies and automates data backup across AWS services including Amazon EBS, Amazon EC2, Amazon RDS, Amazon Aurora, Amazon DynamoDB, Amazon EFS, and AWS Storage Gateway. In addition, AWS Backup leverages AWS Organizations to implement and maintain a central view of backup policy across resources in a multi-account AWS environment. Customers simply tag and associate their AWS resources with backup policies managed by AWS Backup for Cross-Region data replication.

The following post shows how to centrally manage backup tasks across AWS accounts in your organization by deploying backup policies with AWS Backup.

Example AWS Backup Architecture: 

https://aws.amazon.com/blogs/storage/centralized-cross-account-management-with-cross-region-copy-using-aws-backup/

Incorrect options:

Configure AWS Systems Manager Maintenance Windows to schedule backup tasks as per the company's policies. Tag the resources to help identify them by the AWS environment they run in. Amazon CloudWatch dashboards hosted by Systems Manager to get an overall view of the status of all resources under the AWS account

AWS Systems Manager Maintenance Windows let you define a schedule for when to perform potentially disruptive actions on your instances such as patching an operating system, updating drivers, or installing software or patches. Although a useful service, it is not suited for the given requirements.

Use Amazon EventBridge to create a workflow for scheduled backup of all AWS resources under an account. Amazon S3 lifecycle policies, Amazon EC2 instance backups, and Amazon RDS backups can be used to create the events for the EventBridge. The same workflow can be scheduled to work on production and non-production environments, based on the tags created - Amazon EventBridge is a serverless event bus that makes it easy to connect applications together using data from your own applications, integrated Software-as-a-Service (SaaS) applications, and AWS services. It is possible to build a backup solution using EventBridge, but it will not be an optimized one, since AWS offers services with better features for centrally managing backups.

Use Amazon Data Lifecycle Manager to manage creation, deletion and managing of all the AWS resources under an account. Tag all the resources that need to be backed up and use lifecycle policies to customize the backup management to cater to the needs of the organization - DLM provides a simple way to manage the lifecycle of EBS resources, such as volume snapshots. You should use DLM when you want to automate the creation, retention, and deletion of EBS snapshots.

References:

https://aws.amazon.com/blogs/storage/centralized-cross-account-management-with-cross-region-copy-using-aws-backup/

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

https://aws.amazon.com/eventbridge/

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html

Correct option:

The error indicates the IAM role is not correctly configured. After you've created a flow log, you cannot change its configuration. Instead, you need to delete the flow log and create a new one with the required configuration

Access error can be caused by one of the following reasons:

The IAM role for your flow log does not have sufficient permissions to publish flow log records to the CloudWatch log group

The IAM role does not have a trust relationship with the flow logs service

The trust relationship does not specify the flow logs service as the principal

After you've created a flow log, you cannot change its configuration or the flow log record format. For example, you can't associate a different IAM role with the flow log or add or remove fields in the flow log record. Instead, you can delete the flow log and create a new one with the required configuration.

Incorrect options:

The error indicates that the IAM role does not have a trust relationship with the flow logs service. Change the trust relationship from flow log configuration - As discussed above, the VPC flow log configuration cannot be changed once created.

The flow log is still in the process of being created. It sometimes takes almost 10 minutes to start the logs - This scenario is possible when you have just configured the flow logs. However, the status of the flow logs will not be in an error state.

The error indicates an internal error has occurred in the flow logs service. Raise a service request with AWS - This is a made-up option, given only as a distractor.

References:

https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-troubleshooting.html

https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html#flow-log-records

Correct option:

For Amazon CloudFront, you use key pairs to create signed URLs for private content, such as when you want to distribute restricted content that someone paid for.

CloudFront Key Pairs - IAM users can't create CloudFront key pairs. You must log in using root credentials to create key pairs.

Incorrect options:

EC2 Instance Key Pairs - You use key pairs to access Amazon EC2 instances, such as when you use SSH to log in to a Linux instance. These key pairs can be created from the IAM user login and do not need root user access.

IAM User Access Keys - Access keys consist of two parts: an access key ID and a secret access key. You use access keys to sign programmatic requests that you make to AWS if you use AWS CLI commands (using the SDKs) or using AWS API operations. IAM users can create their own Access Keys. This process does not need root access.

IAM User passwords - Every IAM user has access to his own credentials and can reset the password whenever they need to.

References:

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

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-trusted-signers.html