SOA-C02 Practice Questions

To design a high-traffic static website that is highly available and provides low latency globally, you

can use Amazon S3, CloudFront, and Route 53. This solution leverages the global edge locations of

CloudFront to deliver content with low latency.

Create an Amazon S3 Bucket:

Open the S3 console at Amazon S3 Console.

Create a new bucket and upload your website content.

Configure S3 for Static Website Hosting:

Go to the Properties tab of your bucket.

Enable Static website hosting and set the index document (e.g., index.html).

Create a CloudFront Distribution:

Open the CloudFront console at Amazon CloudFront Console.

Create a new distribution and set the S3 bucket as the origin.

Configure distribution settings, including caching behaviors and SSL/TLS settings.

Create Route 53 Alias Record:

Open the Route 53 console at Amazon Route 53 Console.

Select the hosted zone for your domain.

Create a new record set, choose ALIAS as the record type, and point it to the CloudFront distribution.

Amazon S3 Static Website Hosting

Creating a CloudFront Distribution

Routing Traffic to a CloudFront Distribution

Scaling Policies in Auto Scaling:

When multiple scaling policies trigger at the same time, each policy is executed independently.

If both policies are set to add 5 instances when CPU utilization reaches 80%, they will both be

executed when the threshold is met.

Therefore, the total number of instances added will be the sum of the instances specified in both

policies.

In this case, 5 instances from one policy and 5 instances from the other policy will result in a total of

10 instances being added.

Steps to Configure and Verify Scaling Policies:

Go to the AWS Management Console.

Navigate to EC2 and select "Auto Scaling Groups."

Select your Auto Scaling group and review the scaling policies.

Ensure that both scaling policies are configured to trigger at 80% CPU utilization.

Monitor the Auto Scaling group's activity to verify the addition of instances when the CPU utilization

threshold is reached.

Scaling Policies for Amazon EC2 Auto Scaling

When using Amazon S3 Object Lock configured in governance mode, deleting objects before their

retention period ends requires specific permissions. To bypass these governance restrictions, the

administrator must:

C: Assume a role that has the s3:BypassGovernanceRetention permission. This permission allows the

role to override the governance mode restrictions.

D: Include the x-amz-bypass-governance-retention:true header in the delete request. This header is

necessary to programmatically bypass the governance retention settings when making a delete

request via the AWS CLI or SDK. These steps enable the deletion of objects under governance mode

retention without waiting for the retention period to expire, addressing the need to remove

unintended data uploads effectively. For further details, refer to the AWS documentation on S3

Object Lock Amazon S3 Object Lock.

AWS Config Managed Rule for S3 Logging:

The s3-bucket-logging-enabled AWS Config rule checks whether S3 buckets have logging enabled.

Steps:

Go to the AWS Management Console.

Navigate to AWS Config.

Create a rule using s3-bucket-logging-enabled.

Add a remediation action using an AWS Lambda function or Systems Manager Automation runbook.

AWS Config Managed Rules

Using AWS Lambda for Remediation:

Create a Lambda function that enables logging on S3 buckets.

Steps:

Write a Lambda function in Python or Node.js to enable logging.

Configure the function to trigger on non-compliant buckets.

Reference: AWS Lambda

Using AWS Systems Manager Automation:

The AWS-ConfigureS3BucketLogging runbook automates enabling logging.

Steps:

Go to the AWS Management Console.

Navigate to Systems Manager.

Create an Automation document or use the existing AWS-ConfigureS3BucketLogging runbook.

Configure the remediation action to use this runbook.

Reference: AWS Systems Manager Automation

To correctly route traffic through CloudFront, the CNAME record should point to the CloudFront

distribution's domain (dllllllabcdef8.cloudfront.net). This ensures that requests reach CloudFront

first, which then forwards them to the S3 bucket as configured.

Correcting the DNS Record: Changing the DNS CNAME record to point to the CloudFront distribution

ensures that all requests go through CloudFront, leveraging its caching and content delivery

capabilities.

No Need to Modify S3 Bucket: Since CloudFront accesses the S3 origin through its identity, there’s no

need to disable S3 Block Public Access.

The problem requires modifying the inbound SSH rule to restrict access to a list of trusted IPs instead

of deleting it entirely. AWS Config rules can be configured with automatic remediation actions using

either Systems Manager Automation runbooks or Lambda functions. However, AWS Systems

Manager Automation runbooks are often more appropriate for managing infrastructure changes like

security group modifications because they are reusable, parameterized, and easier to audit.

Create a Systems Manager Automation runbook: This runbook will contain steps to add or modify

the existing security group rule, allowing SSH access only from the specified IP addresses.

Update the AWS Config rule: Modify the Config rule to call this new runbook for its automatic

remediation. This will prevent deletion of the SSH rule and instead update it based on the IP list.

You are correct that an A record typically points to an IP address. However, in the case of an

Application Load Balancer (ALB), you cannot use an A record with an IP address because the IP

addresses of an ALB can change over time. Instead, you can use an alias record to point to the DNS

name of the ALB. An alias record is a Route 53 extension to DNS that allows you to route traffic to

selected AWS resources, such as an ALB, by using a friendly DNS name, such as example.com, instead

of the resource’s IP address or DNS name.

Using AWS Systems Manager Patch Manager with a maintenance window is a best practice for

automating OS patch management across instances in an Auto Scaling group.

Patch Manager: Allows for scheduled patching according to maintenance windows, ensuring minimal

impact on application uptime.

RebootOption parameter: Setting this to RebootIfNeeded ensures patches are applied fully when a

reboot is required.

AWS-RunPatchBaseline: This document automates the patching process and can be customized

based on compliance requirements.

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Concepts.General.SSL.htm

Amazon RDS supports SSL/TLS encryption for connections to the database, and this can be enabled

by creating a custom parameter group and setting the rds.force_ssl parameter to 1. This will ensure

that all connections to the database are encrypted, protecting the data and maintaining compliance

with the company's requirements.l

To make the production environment highly available in accordance with company policy:

Database Migration: Move the MariaDB database from a single EC2 instance to Amazon RDS for

MariaDB configured for Multi-AZ. This setup ensures high availability of the database with

synchronous replication to a standby instance in a different Availability Zone.

Application Scalability: Deploy the application on EC2 instances within an Auto Scaling group.

Configure the Auto Scaling group to operate across multiple Availability Zones to ensure that the

application remains available even if one zone becomes unavailable.

Load Balancing: Place the EC2 instances behind an Elastic Load Balancer (ELB). The load balancer will

distribute incoming application traffic across the multiple, geographically dispersed EC2 instances,

further enhancing the availability and fault tolerance of the application.

This solution leverages AWS managed services to increase the reliability and availability of both the

application and database layers, adhering to best practices for deploying critical production

environments on AWS.