Free Practice Questions for Amazon Web Services SOA-C02 Exam

To securely manage and rotate the credentials for an Amazon RDS database created by a CloudFormation template, you should use AWS Secrets Manager. The AWS::SecretsManager::Secret resource can be used to create a secret, and the resolve:secretsmanager dynamic reference can be used to retrieve the secret.

Define Secrets Manager Resource in CloudFormation Template:

Add an AWS::SecretsManager::Secret resource to the CloudFormation template to store the database credentials.

Reference the Secret in RDS Resource:

Use the resolve:secretsmanager dynamic reference to retrieve the secret when creating the AWS::RDS::DBInstance resource.

Example CloudFormation Template:

MyDatabaseSecret:

Type: AWS::SecretsManager::Secret

Properties:

Name: MyDatabaseSecret

GenerateSecretString:

SecretStringTemplate: '{"username": "admin"}'

GenerateStringKey: "password"

PasswordLength: 16

ExcludeCharacters: '"@/\\'

MyRDSInstance:

Type: AWS::RDS::DBInstance

Properties:

DBInstanceIdentifier: MyRDSInstance

Engine: mysql

MasterUsername: !Sub '{{resolve:secretsmanager:MyDatabaseSecret:SecretString:username}}'

MasterUserPassword: !Sub '{{resolve:secretsmanager:MyDatabaseSecret:SecretString:password}}'

DBInstanceClass: db.t2.micro

AllocatedStorage: 20

AWS::SecretsManager::Secret

Dynamic References

For improving upload performance globally for an Amazon S3 bucket, enabling S3 Transfer Acceleration is the best solution. This service optimizes file transfers to S3 using Amazon CloudFront's globally distributed edge locations. After enabling this feature, uploads to the S3 bucket are first routed to an AWS edge location and then transferred to S3 over an optimized network path. Option C is correct, and the developers should use the provided accelerate endpoint in their API calls. For more details, consult the AWS documentation on S3 Transfer Acceleration Amazon S3 Transfer Acceleration.

A CloudFormation stack in the DELETE_FAILED state typically indicates that some resources could not be deleted. One common reason is that S3 buckets in the stack still contain objects.

Steps:

Identify the Failed Resources:

Open the AWS CloudFormation console.

Select the stack in the DELETE_FAILED state.

Check the "Events" tab to identify the resource(s) that caused the failure.

Delete S3 Objects:

Open the Amazon S3 console.

Navigate to the bucket(s) listed in the CloudFormation events.

Delete all objects in the bucket. You can use the S3 console, AWS CLI, or an S3 batch operation to delete the objects.

Retry Stack Deletion:

After clearing the S3 bucket(s), go back to the CloudFormation console.

Select the stack and choose "Delete" to retry the deletion process.

Modifying the DB instance to a Multi-AZ deployment is the recommended solution for failover and high availability in RDS. Multi-AZ RDS automatically provisions and maintains a synchronous standby replica in a different Availability Zone, allowing automatic failover in case of an instance or Availability Zone failure.

Multi-AZ Deployment: Provides resilience with automatic failover and minimizes application downtime.

No Application Changes Needed: Multi-AZ is managed by AWS, so the failover is transparent to the application.

Read replicas and Auto Scaling groups do not provide automatic failover for write operations, and RDS Proxy only improves connection management rather than high availability.

Step-by-Step Explanation:

Understand the Problem:

Each Lambda function generates 1 GB of log data daily in its own CloudWatch Logs log group.

The security team needs a count of application errors, grouped by type, across all log groups.

Analyze the Requirements:

Aggregate and analyze log data across multiple log groups.

Count and group errors by type.

Evaluate the Options:

Option A: Perform a CloudWatch Logs Insights query.

CloudWatch Logs Insights allows querying and analyzing log data.

The stats command and count function can aggregate and count errors across log groups.

Option B: Perform a CloudWatch Logs search with groupby and count.

CloudWatch Logs search does not support these functions; Logs Insights is needed for advanced queries.

Option C: Perform an Amazon Athena query.

Athena can query data in S3 but is not directly applicable to CloudWatch Logs.

Option D: Perform an Amazon RDS query.

RDS queries are for database data, not applicable to log data in CloudWatch.

Select the Best Solution:

Option A: CloudWatch Logs Insights is designed for querying and analyzing log data, making it the appropriate choice for counting and grouping errors.

Amazon CloudWatch Logs Insights

CloudWatch Logs Insights provides powerful querying capabilities to aggregate and analyze log data, including counting and grouping errors.

To host a static website on Amazon S3, the SysOps administrator needs to configure the bucket for public access and set up the static website hosting. Here's how to complete this process:

Turn off "Block all public access": Amazon S3 buckets have "Block all public access" settings enabled by default for security. Since the webpage needs to be accessible publicly, this setting must be disabled. This step is crucial to allow public read access to the web content.

Set a bucket policy: After disabling "Block all public access," set a bucket policy that explicitly allows public read access to the S3 bucket. This policy should allow the s3:GetObject action for everyone, which can be set by specifying "Principal": "*". This policy ensures that anyone can view the webpage but does not grant permissions to modify or delete the content.

Create an index.html document and configure static website hosting: The next step is to create an index.html file, which will serve as the entry point of the website. After creating this file, upload it to the bucket. Then, configure the bucket for static website hosting through the S3 management console. This setting enables the S3 bucket to serve the webpage directly from the index.html file.

Combining these actions, the S3 bucket will be properly configured to host and serve the static website with minimal operational overhead and maximum accessibility.

To quickly remediate resources and bring them back into compliance with patch standards, AWS Systems Manager is the appropriate service to use.

Use AWS Systems Manager:

Leverage Systems Manager Patch Manager to automate the process of patching managed instances.

Use Systems Manager State Manager to ensure that resources remain in compliance with the desired configurations.

To ensure all EC2 instances upload build artifacts through a single IP address:

A: Move all of the EC2 instances behind a NAT gateway. Provide the IP address of the NAT gateway to the third-party service for the allow list. A NAT gateway enables instances in a private subnet to connect to services outside AWS (such as a third-party service) but prevents the internet from initiating connections with those instances. Using a NAT gateway standardizes all outgoing traffic to use a single IP address. More information on NAT gateways can be found in AWS documentation NAT Gateways.

Problem Analysis:

The Cache-Control header (max-age=1 hour) conflicts with the CloudFront Maximum TTL setting (5 minutes).

CloudFront adheres to the lower of the two settings, leading to assets being cached for only 5 minutes.

Understanding Cache Behavior in CloudFront:

CloudFront evaluates headers such as Cache-Control and Expires along with its TTL settings.

The effective cache duration is the minimum value among these settings.

Resolution:

Align the Cache-Control max-age header and CloudFront Maximum TTL settings:

Update the CloudFront behavior to use a consistent value (e.g., set both to 1 hour).

Why Other Options Are Incorrect:

A: The Expires header value is irrelevant as CloudFront primarily considers Cache-Control and TTL settings.

B: The issue is not about expiring cached assets but about the duration of cache retention.

C: Cache invalidation is not required as it addresses purging specific objects from cache.

When EC2 instances in a VPC cannot resolve on-premises DNS names like mssql.example.com, it is usually because the default DHCP options set provided by AWS does not allow forwarding DNS queries outside of the VPC.

To resolve this, you must:

Create a Route 53 Resolver outbound endpoint in your VPC.

Define a forwarding rule for the example.com domain, specifying the on-premises DNS server as the target.

Associate the forwarding rule with the VPC where the EC2 instance resides.

This setup enables DNS queries for example.com to be forwarded from AWS to the on-premises DNS servers, thereby enabling name resolution for hybrid environments.

Exact Reference from AWS Documentation:

AWS Route 53 Resolver enables hybrid cloud DNS resolution. An outbound endpoint forwards DNS queries from the VPC to on-premises DNS servers via defined rules.

[Source: Amazon Route 53 Resolver Documentation – Forwarding outbound queries]