VishaalY/solutions-architect-hf-dataset huggingface dataset:
Question: How do I add the testng.xml file to the root of the *-tests.jar file in my Appium Java TestNG test package for AWS Device Farm?

I want to configure Appium Java TestNG tests for my AWS Device Farm project. However, I need to add a testng.xml file into the root of the *-tests.jar file in my Appium test package first. How do I do that?Short descriptionConfigure the Apache Maven pom.xml file to package your testng.xml file into the root of your Appium test package's *-tests.jar file.Note: In Device Farm's standard test environment, only a subset of the features in the testng.xml file are supported. Use the custom test environment if your project requires any of the following testng.xml file features:Priority'include' and 'exclude' tagsComplex groupingAny TestNG parameters defined in your testng.xml fileResolution1.    In your Apache Maven pom.xml file, verify that the testResources tag includes the following directory: src/test/resources. If you don't see the directory, add the following directory configuration to the file:<testResources>     <testResource>        <directory>${project.basedir}/src/test/resources</directory>     </testResource></testResources>Note: You can specify another directory to use for this procedure. If you choose to use another directory, make sure that you use that same directory in steps 2 and 3.2.    Add your testng.xml file to your pom.xml file's src/test/resources directory.3.    (Optional) To run tests locally, add the following Maven Surefire plugin to your pom.xml file's <plugins> list.<plugin>    <groupId>org.apache.maven.plugins</groupId>     <artifactId>maven-surefire-plugin</artifactId>    <version>2.12.4</version>     <configuration>       <suiteXmlFiles> <suiteXmlFile>src/test/resources/testng.xml</suiteXmlFile></suiteXmlFiles>    </configuration></plugin>Note: It's a best practice to run tests locally before uploading projects to Device Farm. The Maven Surefire plugin allows your pom.xml file to reference your testng.xml file during local tests.4.    Clean your pom.xml file's target directory and repackage your test files by running the following Maven command:$ mvn clean package -DskipTests=trueNote: The DskipTests=True value specifies that the build won't run the unit tests.The command creates a zip-with-dependencies.zip file in your pom.xml file's target directory. This zip file is your Appium test package and includes your testng.xml file in the root of its *-tests.jar file.5.    Verify that your testng.xml file is in the root of your Appium test package's *-tests.jar file by running one of the following commands:To see a snapshot of files in your *-tests.jar file, run the following jar command:$ jar tvf foo-1.0.0-SNAPSHOT-tests.jar-or-To extract all of the files in your *-tests.jar file into a folder, run the following unzip command:$ unzip foo-1.0.0-SNAPSHOT-tests.jar -d sampletestsjarcontentsYou can now upload your test package to Device Farm and create a test run using your app and the zip-with-dependencies.zip file.

Related informationTroubleshooting Appium Java TestNG web applications in AWS Device FarmWorking with custom test environments in AWS Device Farm
Question: How do I find my Amazon Connect instance ID?

I want to find my Amazon Connect instance ID.

ResolutionYour Amazon Connect instance ID is the 36-character string at the end of your instance's Amazon Resource Name (ARN).To see your instance's ARN, follow the instructions in Find your Amazon Connect instance ID/ARN.

Related informationCreate an Amazon Connect instance
Question: How can I prevent or restrict users from updating or deleting my Route 53 health checks?

I created several Amazon Route 53 health checks. I want to either prevent all other users from modifying these health checks, or control which users can modify them.

ResolutionUse AWS Identity and Access Management (IAM) policies to prevent changes to your Route 53 health checks. For more information, see Using identity-based policies (IAM policies) for Amazon Route 53.Option 1: Explicitly deny other users from deleting or updating health checksTo restrict other users from running the delete and update commands on your health checks, use the following IAM policy :{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Deny",      "Action": [        "route53:DeleteHealthCheck",        "route53:UpdateHealthCheck"      ],      "Resource": "*"    }  ]}Option 2: Require other users to perform multi-factor authentication (MFA) to delete or update health checksTo control which users can update health checks, use MFA to be sure that only MFA authenticated users can modify them. If a user isn't MFA authenticated, then any update or delete calls that they attempt fail.The following statement specifies that any MFA unauthenticated user can't perform the listed actions:{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "VisualEditor0",      "Effect": "Deny",      "Action": [        "route53:UpdateHealthCheck",        "route53:DeleteHealthCheck"      ],      "Resource": "*",      "Condition": {        "BoolIfExists": {          "aws:MultiFactorAuthPresent": "false"        }      }    }  ]}For more information, see How do I use an MFA token to authenticate access to my AWS resources through the AWS Command Line Interface (AWS CLI)?
Question: How do I move a Direct Connect connection from one AWS account to another?

I want to move an AWS Direct Connect connection from one AWS account to another. How can I do this?Short descriptionTo move a Direct Connect connection between AWS accounts, you must transfer ownership of that connection. The source (current owner) and destination (new owner) AWS accounts must each open separate AWS Support cases to transfer ownership of the Direct Connect connection. This process helps verify that both the source and the destination AWS accounts agree to the transfer.The transfer of a Direct Connect connection changes ownership and billing of the connection to the transferred account. No changes are made to the Direct Connect connection during the transfer. No network outages occur during the ownership transfer of Direct Connect connections from one AWS account to another.Note:This ownership transfer is only for the Direct Connect connection.Transfer of ownership is available only for AWS Direct Connect dedicated connections. If you have a hosted connection from an AWS partner, then transfer of ownership isn’t possible.Virtual interfaces associated with the Direct Connect connection aren't part of the transfer. They remain associated with the AWS account where they were created.Direct Connect gateways can't be moved from one AWS account to another.

ResolutionBefore you begin, be sure that both the current and new owners agree to the Direct Connect connection transfer.1.    Open an AWS Support case from the source account (the current owner of the Direct Connect connection). Be sure to grant permission for AWS Support to transfer the Direct Connect connection from this account to the destination account. Also, be sure to provide the Direct Connect connection ID.2.    Open an AWS Support case from the destination account (the new owner of the Direct Connect connection). Be sure to grant permission for this account to accept ownership of the Direct Connect connection. Also, be sure to provide the Direct Connect connection ID.3.    After the destination account's case is created, note the case ID.4.    Update the source account's case with the destination account's case number.5.    Wait for AWS Support to review both cases and process the ownership transfer.

Related informationAWS Direct Connect connections
Question: Why do my AWS Health events still appear in the AWS Health Dashboard after I've taken the requested notification action?

I took the requested action in the AWS Health Dashboard but the notification still appears.

Short descriptionYou can use the AWS Health Dashboard to view the health of all AWS services. Health events (public or account-specific) might request you to act on resources in your AWS account. For example, stopping an Amazon Elastic Compute Cloud (Amazon EC2) instance that has scheduled maintenance. You can review the event description to understand the issue, identify affected resources, and follow the requested actions. The event status tells you if the Health event is open, closed, or upcoming. You can view Health events in the AWS Health Dashboard, or the AWS Health API, for up to 90 days.For more information, see AWS Health events.

ResolutionAfter taking the requested action, the Health event might still appear in the AWS Health Dashboard. For example, under the Open and recent issues and Scheduled changes sections the Health event is still displayed after taking the requested action. The Other notifications section displays events for several days or until the scheduled end time has been reached.If you've already taken the requested action in the AWS Health Dashboard, then you can ignore the notification.For more information, see AWS Health Dashboard – Service health.

Related informationAre you a first-time AWS Health user?How can I use AWS Health Aware to send events to channels across my organization in Organizations?
Question: How do I know if my dedicated IP address for Amazon SES is warmed up?

I leased a dedicated IP address for my Amazon Simple Email Service (Amazon SES) account. How can I confirm that the dedicated IP address is warmed up?ResolutionTo view the warm-up status of your dedicated IP address, follow these steps:Open the Amazon SES console.From the navigation pane, under Email Sending, choose Dedicated IPs.On this page, you can view the percent completion for the warm-up process: IP Address Warm Up Status (% completed)Related InformationWarming up Dedicated IP Addresses
Question: How do I assign a static hostname to an Amazon EC2 instance running RHEL 7 or CentOS 7?

I changed the hostname of my Amazon Elastic Compute Cloud (Amazon EC2) instance. However, when I reboot or stop and then start the instance, the hostname changes back.

Short descriptionTo make a hostname persist when you reboot or stop and start your EC2 instance, add the hostname to the appropriate configuration files on the instance.Note: The following steps apply to RHEL 7 or CentOS 7. For instructions that apply to other distributions, see one of the following:Change the system hostnameHow do I assign a static hostname to an Amazon EC2 instance running RHEL 5 or 6, CentOS 5 or 6, or Amazon Linux?How do I assign a static hostname to an Amazon EC2 instance running SLES?How do I assign a static hostname to an Amazon EC2 instance running Ubuntu Linux?Resolution1.    Run the hostnamectl command  from the shell to update the hostname of your RHEL 7 or CentOS 7 Linux instance. Replace persistent-hostname with the name you want the instance to use:sudo hostnamectl set-hostname --static persistent-hostnameNote: Changing the hostname by using the hostnamectl command doesn't update the /etc/hosts file. However, if necessary, you can manually edit this file to add the new hostname.2.    Use the vi text editor to update the /etc/cloud/cloud.cfg file on your RHEL 7 or CentOS 7 Linux instance. For general information about using the vi editor, run the command info vi from the command shell:Note: For instances running RHEL 7.4 and above, skip this step.sudo vi /etc/cloud/cloud.cfg3.    Add the following string to the bottom of the /etc/cloud/cloud.cfg file to be sure that the new hostname is preserved between restarts and reboots:preserve_hostname: trueSave and exit the vi editor.4.    Run the reboot command to reboot the EC2 instance and associate the new hostname with the instance:sudo reboot5.    Run the Linux hostname command without any parameters to verify that the hostname change persisted:hostnameThe command returns the new hostname that you specified in step 1.Note: If you install any system updates that affect the /etc/hosts file, the hostname file, or the hostname utility, then you must run these steps again.
Question: How do I recover deleted DNS records from my Route 53 hosted zone?

I want to recover deleted DNS records from my Amazon Route 53 hosted zone.

ResolutionCheck your CloudTrail event history1.    Open the AWS CloudTrail console. Be sure that you're in the N. Virginia Region. Route 53 DNS service API calls are logged in this Region only.2.    In the navigation pane, choose Event history.3.    Choose the Event name filter.4.    Enter the event name as ChangeResourceRecordSets.You can now view all events that are logged when a DNS record is created, changed, or deleted. An event is in JSON format and provides information such as name, type, and TTL. To narrow your search, you can use the time filter.Note: Different record types have different JSON syntax. For more information, see change-resource-record-sets.Download CloudTrail eventsIf you're not sure when the DNS record was deleted, then you can download all events and filter the results using the DELETE action:1.    Choose Download events.2.    Choose Download as JSON.3.    Search for the DELETE keyword, and then review the details about the deleted DNS record.View CloudTrail events using the AWS CLINote: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.Use the lookup-events command to view the CloudTrail event history for the DELETE action:aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=ChangeResourceRecordSets --region us-east-1 | grep "DELETE"Use the details about the deleted DNS record to create the record in the desired Route 53 hosted zone.Note: You can view event history for only the past 90 days. To view CloudTrail logs that are older than 90 days, create a trail. Then, send the logs to an Amazon Simple Storage Service (Amazon S3) bucket or to Amazon CloudWatch Logs. Note that it can take up to 15 minutes for events to be logged in CloudTrail.
Question: Why aren't my Savings Plans applying to my AWS billing in the way that I expected?

I purchased a Savings Plan, but it's being used in a way that I didn't expect.

ResolutionAWS Cost Explorer shows you details on the savings realized with your Savings Plans. You can also use the Savings Plans performance reports in AWS Cost Explorer to understand how well you are using your Savings Plans.For Savings Plans to apply, the following conditions must be true:The upfront cost (partial or all) for your Savings Plan must process successfully. Check the status of your payments on the Payment History page of the Billing and Cost Management console. To retry a failed Savings Plans payment, contact AWS Support. Failed Savings Plans purchases from previous billing periods can’t be retried.Your Savings Plan must still be active. When you purchase a Savings Plan, you choose a one-year or three-year term. After the term expires, your usage is billed at the On-Demand Instance price. To continue receiving the savings, purchase another Savings Plan with the same specifications. To check if your Savings Plans are active, you can check the AWS Cost Management console.Tip: To avoid gaps in savings, set Savings Plans alerts.You must have AWS compute usage in a supported service with the corresponding plan type. Amazon Elastic Compute Cloud (Amazon EC2), AWS Fargate, AWS Lambda, or Amazon SageMaker are eligible services for Savings Plans.If the conditions listed above are met, consider the following scenarios:Savings Plans commitment are hourly and will apply up to the hourly commitment for each hour as long as there is eligible usage. As Savings Plans are hourly, there could be remaining Savings Plans commitment in some hours and additional On-Demand charges in other hours. The remaining Savings Plans commitment in one hour can't be applied to On-Demand charges in another hour.If you have both Reserved Instances (RI) and Savings plans, RIs will apply before Savings Plans and any uncovered On Demand usage will be covered by Savings Plans.When Savings Plans apply to usage, the On Demand charges are displayed first followed by a corresponding discount for that On Demand usage. Savings Plans are applied to the qualifying usage, starting with the usage that receives the largest calculated savings. If other usage provides a larger savings, AWS will apply the Savings Plans to that usage.AWS Free Tier benefits are applied before Savings Plan benefits. Any excess usage that isn't covered by free tier, will be covered by Savings Plans.If you have multiple Savings Plans active at the same time, your bill will be generated by taking into account all active Savings Plans.The benefit of Savings Plans is applied to usage every hour. Any unused benefits will not be carried over to the next hour.Savings Plans are applied differently in an organization's consolidated bill, depending on whether sharing is turned on or off. For more information, see How is the pricing benefit of a Savings Plan applied across an organization's consolidated bill?Related informationCan I schedule my Savings Plan to renew automatically?How do I save money on my AWS usage using a Savings Plan?
Question: Can I pin an application that's running on AWS to a certificate that was issued by ACM?

I want to know if I can pin an application that's running on AWS to a certificate that was issued by AWS Certificate Manager (ACM).

Short descriptionIt's not a best practice to pin your application to an SSL/TLS certificate issued by ACM. If you pin a certificate, then you provide a browser with an ID for the public key that's used for the website. If a user visits the website, the pin is cached by the browser. That pin is also then used to verify the public key during future visits. The pin information is usually included in the header in the HTTP response and the time to live (TTL) for the pin. If the certificate changes, for example, when the certificate is renewed, then that change can cause website visitors to receive errors. These errors occur because a secure connection to the website can't be established. For more information, see Certificate pinning.Important: Starting October 11, 2022 at 9:00 AM Pacific Time, public certificates obtained through ACM are issued from one of the intermediate CAs that Amazon manages. Multiple intermediate CAs chain to an existing Amazon Trust Services root CA. With this change, leaf certificates issued to you are signed by different intermediate CAs. Before this change, Amazon maintained a limited number of intermediate CAs and issued and renewed certificates from the same intermediate CAs. For more information, see Amazon introduces dynamic intermediate certificate authorities.

ResolutionIt's a best practice to pin your application to a root certificate authority (CA) rather than to an individual certificate or an intermediate CA certificate. When you pin an application to an Amazon Trust Services CA, pin the same application to all the CAs in the Amazon trust services table.Note: You must select all the CAs that you pin your application to because, when you request a certificate, ACM doesn't specify the certificate's origin.To pin a certificate, use one of the following options to be sure that the application can connect to the domain.Pin your application to an Amazon root certificateWhen you pin your application at the root certificate level, ACM-managed renewal renews the certificate under the same CA that issued the certificate. The certificate Amazon Resource Name (ARN) remains the same. You can also pin your application to multiple CAs as backup pins. If the certificate expires, then you can request a new certificate and apply the certificate to your load balancer to reduce application downtime.Import your own certificate into ACM, and then pin your application to the imported certificateImported certificates aren't renewed by the ACM-managed renewal process. You must manage the renewal of the certificate and keys. For more information, see Importing certificates into AWS Certificate Manager.

Related informationACM best practicesCertificate pinning problems
Question: How can I troubleshoot a failed CodeDeploy deployment on Amazon EC2 instances?

My AWS CodeDeploy deployment on Amazon Elastic Compute Cloud (Amazon EC2) instances failed.

Short descriptionYou can use the AWS Systems Manager AWSSupport-TroubleshootCodeDeploy Automation runbook to troubleshoot failed deployments. The runbook helps you identify when a deployment fails for the following reasons:The CodeDeploy agent isn't installed or isn't running on the instance.The required instance profile is missing.The instance profile doesn't have correct Amazon Simple Storage Service (Amazon S3) permissions.There's an issue with one of the lifecycle hooks that's managed by CodeDeploy, such as AllowTraffic or BlockTraffic.There's an issue with one of the customer-managed lifecycle hooks.An issue occurred with an Auto Scaling group scale down event during the deployment.An AppSpec file is missing or incorrectly formatted.

ResolutionImportant: Use the AWSSupport-TroubleshootCodeDeploy runbook in the same AWS Region where your CodeDeploy application is located.1.    Open the AWS Systems Manager console.2.    In the navigation pane, in the Change Management section, choose Automation.3.    Choose Execute automation.4.    On the Owned by Amazon tab, in the Automation document search box, enter AWSSupport-TroubleshootCodeDeploy. Then, select the search icon, or press Enter on your keyboard.5.    Select the radio button on the AWSSupport-TroubleshootCodeDeploy card.Note: Make sure that you select the radio button and not the hyperlinked automation name.6.    In the Document details section, choose Next.7.    In the Input parameters section, for DeploymentId, enter the deployment ID that failed.8.    For InstanceID, enter the instance ID where the deployment failed.9.    For AutomationAssumeRole, enter the Amazon Resource Name (ARN) of the role that allows Systems Manager Automation to perform actions.Note: If an AWS Identity and Access Management (IAM) role isn’t specified, Systems Manager Automation uses permissions of the IAM user role that runs the runbook. For more information about creating the assume role for Systems Manager Automation, see Task 1: Create a service role for Automation.Important: Either the AutomationAssumeRole or user role must have permissions for the following actions: codedeploy:GetDeployment, codedeploy:GetDeploymentTarget, and ec2:DescribeInstances.10.    Choose Execute.The runbook's output gives troubleshooting steps and recommendations for how to resolve the issue that caused your deployment failure.

Related informationTroubleshooting CodeDeployTroubleshoot EC2/on-premises deployment issues