PAS-C01 Flashcards — Free AWS Certified SAP on AWS Specialty PAS-C01 Study Cards

Increase the size of the existing EBS gp2 volume to a larger size.

Increasing the size of an existing gp2 volume is the most cost-effective solution because gp2 volumes have a baseline performance of 3 IOPS per GB, and they can burst up to 3,000 IOPS for volumes up to 1,000 GB. By increasing the volume size, you raise the baseline IOPS, which reduces the queue depth without incurring the higher per-GB cost of io1 or io2 volumes. This directly addresses the high latency caused by queue depth exceeding the recommended threshold during peak hours.

Use multiple io2 EBS volumes with Block Express striped together using LVM.

It combines multiple io2 Block Express EBS volumes striped via LVM, which delivers the highest possible IOPS and throughput for SAP HANA on AWS. io2 Block Express volumes support up to 256,000 IOPS and 4,000 MB/s throughput per volume, and striping multiple volumes linearly scales these limits to meet the demands of a 1.9 TB memory HANA database. This configuration also ensures data durability through EBS replication within an Availability Zone, unlike instance store volumes.

Use AWS Backup with the SAP HANA Backup and Restore feature (Backint integration) to perform continuous backups to S3.

AWS Backup with the SAP HANA Backup and Restore feature (Backint integration) provides continuous, incremental backups to Amazon S3, achieving an RPO of less than 5 minutes with automated, policy-driven backups. This solution minimizes operational overhead by eliminating manual scripting and infrastructure management, while supporting point-in-time recovery within the required RTO of under 2 hours.

Place all servers in a single Availability Zone and use a cluster placement group.

A cluster placement group is the correct choice because it provides the lowest possible latency and highest throughput by ensuring that all SAP application and database servers are placed in close physical proximity within a single Availability Zone. This placement minimizes network hops and leverages non-blocking, high-bandwidth networking, which is critical for SAP's latency-sensitive communication between application and database layers.

Use io2 Block Express volumes with provisioned IOPS.

The io2 Block Express volume type provides the highest durability and consistent low-latency performance for SAP workloads, with up to 256,000 provisioned IOPS per volume. For /usr/sap, which is sensitive to read latency due to frequent binary and configuration file access, io2 Block Express ensures predictable sub-millisecond latency even under high I/O demand, directly addressing the high read latency issue.

Add a scheduled scaling action to increase capacity before the flash sale.

A scheduled scaling action proactively increases capacity before the flash sale, eliminating the lag inherent in dynamic scaling policies. Dynamic scaling reacts to metrics like average CPU utilization, which can take minutes to trigger and propagate, causing request failures during sudden spikes. By pre-scaling, the Auto Scaling group has sufficient instances ready to handle the traffic surge immediately.

Clients are behind a NAT gateway, so the source IP changes between requests, breaking stickiness. Use a 'stitched' cookie or switch to an Application Load Balancer.

Clients behind a NAT gateway will have their source IP address translated to the NAT gateway's public IP, which remains consistent for all requests from that gateway. However, if multiple clients share the same NAT gateway, the source IP is the same, but the NLB's source IP stickiness is based on the client's source IP as seen by the NLB. If the NAT gateway uses multiple public IPs or if clients are behind different NAT gateways, the source IP can change between requests, breaking stickiness. The solution is to use a 'stitched' cookie or switch to an Application Load Balancer, which supports cookie-based session persistence independent of source IP.

A Multi-AZ deployment with synchronous replication.

Amazon RDS Multi-AZ deployments with synchronous replication provide automatic failover to a standby instance in a different Availability Zone, ensuring data is committed to both primary and standby before acknowledging a write. This achieves an RPO of effectively zero (less than 5 seconds) and an RTO typically under 1 minute, meeting the stated requirements.

Set a stack policy that allows updates to the specific RDS DB instance resource.

A stack policy in AWS CloudFormation can be set to explicitly allow updates to a specific resource (e.g., the RDS DB instance) while denying updates to all other resources by default. Since the update requires a replacement of the database, the policy must permit the update action on that exact resource logical ID, ensuring the DB engine version change proceeds without risking unintended modifications to other stack resources.

AWS Directory Service for Microsoft Active Directory

AWS Directory Service for Microsoft Active Directory is the correct choice because it provides a fully managed Microsoft Active Directory in the AWS cloud, which natively supports Windows Authentication and Kerberos-based authentication without requiring any code changes. This service allows the migrated .NET application to seamlessly integrate with the existing on-premises Active Directory through a trust relationship or by extending the directory directly into AWS, preserving the application's authentication logic.

Use AWS Snowball to transfer the data offline, then use DMS for CDC

The 50 TB database over a 100 Mbps link would take approximately 48 days for a full load (50 TB * 8 / 100 Mbps / 86400 seconds/day), far exceeding the 5-day deadline. AWS Snowball allows offline transfer of the full database snapshot, bypassing network bandwidth constraints, after which AWS DMS can be used for ongoing change data capture (CDC) to replicate incremental changes. This hybrid approach meets the deadline while ensuring minimal data loss.

Use AWS Database Migration Service (DMS) with ongoing replication

AWS Database Migration Service (DMS) with ongoing replication (change data capture, CDC) allows you to perform a live migration with minimal downtime. You can start a full load of the 500 GB MySQL database while the source remains operational, then enable CDC to replicate ongoing changes until you cut over to the target RDS instance, reducing the downtime window to seconds.

Increase the size of the DMS replication instance

The error 'insufficient memory' during the initial full load in AWS DMS typically indicates that the replication instance does not have enough memory to handle the data volume or LOB processing. Increasing the size of the DMS replication instance provides more memory for caching, transformation, and LOB handling, directly resolving the resource constraint without altering the source database or task structure.

Review CloudWatch metrics for the instance and the ALB target group

Reviewing CloudWatch metrics for the instance and the ALB target group is the correct first step because it provides immediate visibility into the root cause of intermittent connectivity issues. Metrics such as TargetResponseTime, RequestCount, and HealthyHostCount can reveal whether the problem is due to high latency, request failures, or the instance being marked unhealthy by the ALB health checks. This data-driven approach avoids unnecessary changes and aligns with the AWS Well-Architected Framework's principle of observability.

The VPC endpoint for SSM does not have a security group that allows HTTPS outbound to the endpoint

The error 'Unable to retrieve patch baseline' indicates that the EC2 instances cannot communicate with the AWS Systems Manager service to fetch the patch baseline configuration. Since the instances are in a private subnet with a VPC endpoint for SSM, the most likely cause is that the VPC endpoint's security group does not allow HTTPS outbound traffic (port 443) to the endpoint itself. Without this outbound rule, the SSM Agent on the instance cannot establish the TLS connection required to retrieve the patch baseline from the SSM API.

Configure the service as a systemd unit with Restart=on-failure

Systemd, the default init system on Amazon Linux 2, provides a built-in `Restart=` directive that can be set to `on-failure`. This instructs systemd to automatically restart the service unit when it exits with a non-zero exit code or is terminated by a signal, without requiring any external monitoring or additional infrastructure. This is the most operationally efficient approach as it leverages the native service manager functionality with zero external dependencies.