Hard Difficulty Questions

Assign the patch baseline to the instance IDs directly.

Why wrong: Patch baselines are assigned to patch groups, not individual instances.

Ensure that the instances have the appropriate IAM role that allows them to be patched.

Why wrong: While necessary, this is a prerequisite and not a troubleshooting step for specific failures.

Configure a Maintenance Window for the patching operation.

Why wrong: Maintenance Windows are optional; patching can be done on demand.

Back up HANA data directly to Amazon S3 using standard tools.

Why wrong: HANA does not directly support S3 backup without Backint.

Replicate backups to another AWS Region using S3 Cross-Region Replication.

Why wrong: This is for disaster recovery, not backup strategy.

Configure the ECS task definition to assign a public IP address to the tasks and ensure the tasks have a route to the internet via a NAT gateway

Why wrong: Assigning public IPs and using a NAT gateway is unnecessary for private subnet communication within the same VPC and could introduce security risks.

Place both the ECS tasks and the RDS instance in the same public subnet to ensure network connectivity

Why wrong: Placing resources in public subnets is not a best practice and may not be allowed due to security policies. Also, the issue is likely not about public vs private.

Modify the RDS security group inbound rule to allow traffic from the CIDR block of the ECS tasks’ private subnets instead of the security group ID

Why wrong: While this would work, it is less secure than using security group references and is not the best practice. The existing rule using the security group ID should already work if properly configured.

Change the scaling policy to a simple scaling policy instead of dynamic scaling

Why wrong: Simple scaling does not prevent session loss; the core issue is that session state is stored in memory on the instance.

Enable sticky sessions (session affinity) on the Application Load Balancer

Why wrong: Stickiness routes users to the same instance, but if that instance is terminated due to scaling in, the session is still lost.

Increase the cooldown period for the Auto Scaling group

Why wrong: Cooldown period only affects when new scaling activities can start; it does not preserve session data.

Use a single DMS task with full LOB mode

Why wrong: Full LOB mode can slow down migration; limited parallelism.

Use S3 multipart upload for the data

Why wrong: DMS does not use S3 internally for data transfer.

Disable transaction logging on the source

Why wrong: Disabling logging would compromise data integrity and CDC.

Disable LOB support in the DMS task

Why wrong: May truncate or lose LOB data, which is not acceptable.

Split the migration into multiple smaller tasks

Why wrong: Reduces per-task load but may still hit memory limits; scaling instance is more direct.

Increase the memory of the source EC2 instance

Why wrong: DMS memory error is on the replication instance, not the source.

Revert the migration and keep the application on-premises with a VPN connection to AWS for other services.

Why wrong: This does not solve the migration goal and adds complexity with potential latency.

Provision a Dedicated Host and associate the instance with it to control hardware IDs.

Why wrong: Dedicated Hosts are more expensive and provide physical server control, but not a flexible solution for a single application.

Modify the application's license file to accept the new hardware ID.

Why wrong: This is likely a breach of the license agreement and may cause legal issues.

Use AWS Database Migration Service (DMS) to migrate to Amazon RDS in a single-AZ deployment, then manually take snapshots.

Why wrong: Single-AZ RDS does not provide automatic failover; manual snapshots lead to longer downtime.

Migrate the database to a single large Amazon EC2 instance using AWS Application Migration Service.

Why wrong: A single instance is a single point of failure, no high availability.

Migrate to Amazon RDS with Multi-AZ deployment and use DMS for initial load.

Why wrong: DMS is used for initial migration, but Multi-AZ provides HA; however, DMS is not needed if using native RDS restore, but this option is plausible but not the best because DMS adds complexity.

Convert the application to run on Amazon Linux 2 to simplify future management.

Why wrong: Converting to Amazon Linux would require significant rework and testing, not a simple migration step.

Use AWS Database Migration Service (DMS) to migrate the application server.

Why wrong: DMS is for databases, not for migrating entire servers or applications.

Configure binary logging on the target MySQL RDS instance.

Why wrong: The error is about the source Oracle database, not the target MySQL.

Stop and restart the DMS task to clear the error.

Why wrong: Restarting without fixing the logging will cause the same error again.

Switch the target database to Amazon RDS for Oracle to maintain compatibility.

Why wrong: Changing the target engine is not required; the issue is with source logging.

Place the instances in a placement group to ensure high availability

Why wrong: Placement groups are for low latency, not high availability across AZs.

Use an Application Load Balancer to distribute traffic to the instances

Why wrong: ALB does not provide a static IP; it uses a DNS name.

Review VPC Flow Logs to identify if traffic is reaching the ALB.

Why wrong: Flow logs show network-level traffic, not application-level errors.

Enable automated backups with a short retention period.

Why wrong: Backups are unrelated to failover connection handling.

Increase the TTL of the RDS DNS record to 300 seconds.

Why wrong: Higher TTL means clients cache old IP longer, increasing downtime.

Place a Network Load Balancer in front of the RDS instance.

Why wrong: NLB does not support RDS directly; adds unnecessary complexity.

Examine the S3 server access logs for the bucket.

Why wrong: Server access logs do not include management API calls.

Review the configuration timeline in AWS Config for the S3 bucket.

Why wrong: Config shows the changes but not the user identity.

Use AWS Systems Manager Automation to run a script that checks CloudWatch Logs.

Why wrong: Inefficient and not the direct tool.

Use the AWS Management Console to modify the volume and enable encryption in place

Why wrong: EBS does not support enabling encryption on an existing unencrypted volume in place.

Take a snapshot of the volume, copy the snapshot with encryption enabled, then restore to a new volume and attach it to the instance

Why wrong: This works but requires an extra step (copy) compared to directly creating an encrypted snapshot.

Detach the volume, enable encryption using the ModifyVolume API, then reattach

Why wrong: The ModifyVolume API does not support changing encryption status.

Attach an EC2 Auto Scaling group to the ECS service to handle capacity.

Why wrong: Fargate manages underlying infrastructure; no EC2 needed.

Configure step scaling policies to add multiple tasks at once.

Why wrong: Target tracking is simpler and sufficient; step scaling is optional.

The SQS visibility timeout is too short; increase it.

Why wrong: Visibility timeout affects retries, not throttling.

The Lambda function's dead-letter queue (DLQ) is not configured; set up a DLQ.

Why wrong: DLQ handles failed messages, not throttling.

The SQS queue's redrive policy is too aggressive; reduce the maxReceiveCount.

Why wrong: Not related to throttling.

Manually delete the DynamoDB table and then retry the stack update.

Why wrong: Manual deletion may cause data loss and does not resolve the rollback state.

Delete the stack and recreate it from the template.

Why wrong: Deleting the stack removes all resources, including the DynamoDB table with data.

Update the stack again with a different change set to bypass the failed resource.

Why wrong: Updating again is not possible while the stack is in UPDATE_ROLLBACK_FAILED state.

The instance was stopped instead of terminated, and the persistent data volume was detached during the stop.

Why wrong: Stopping an instance does not delete volumes; the volume would still exist.

The persistent data volume (vol-0f1e2d3c4b5a67890) had DeleteOnTermination set to false, but the administrator inadvertently changed it before termination.

Why wrong: The exhibit shows DeleteOnTermination is false for that volume, so it should not be deleted upon termination.

The persistent data volume was not properly attached to the instance before termination.

Why wrong: The exhibit shows the volume is attached with status 'attached'.

AWS Storage Gateway for on-premises caching

Why wrong: Storage Gateway is for hybrid, not directly for SAP cost optimization.

Amazon S3 Standard for all data

Why wrong: Standard is costly for infrequently accessed data.