You try to connect via SSH to a newly created Amazon EC2 instance and get one of the following error
messages:
“Network error: Connection timed out” or “Error connecting to [instance], reason: -> Connection timed
out: connect,”
You have confirmed that the network and security group rules are configured correctly and the instance is
passing status checks. What steps should you take to identify the source of the behavior? Choose 2 answers
A.
Verify that the private key file corresponds to the Amazon EC2 key pair assigned at launch.
B.
Verify that your IAM user policy has permission to launch Amazon EC2 instances.
C.
Verify that you are connecting with the appropriate user name for your AMI.
D.
Verify that the Amazon EC2 Instance was launched with the proper IAM role.
E.
Verify that your federation trust to AWS has been established.
Explanation:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html
Correct answer is D and E
Actually you are wrong, it’s A and C, try it.
I choose A & C also b/c Vladam did on the following post and he is pretty much right on everything
http://www.aiotestking.com/amazon/what-steps-should-you-take-to-identify-the-source-of-the-behavior/
After a lot of reading blog posts though, probably best bet is to get the other questions right and guess A & C on this one…
https://acloud.guru/forums/aws-certified-solutions-architect-associate/discussion/-KGg5a-irzSkhi7bQLSI/passed-heres-three-questions-that-are-new-to-me
from the given possibilities I would choose A and C as well
however: none of these answers is correct! 🙁
or does anyone of you get a timeout-error when you connect with a wrong username to a linux-instance?
normally you get some kind of a not-authorized response
br!
Carl
Agree! None of the answers is correct.
None of these would time out a connection. They are all bogus.
None of the situation will get “Connection timed out” error message.
A & C will get error message “Permission denied (publickey)”.
According to the aws documentation (explanation link), you should:
* Check security group inbound rule (allow port 22)
* Check the route table for the subnet. Make sure you have a route that sends all traffic destined outside the VPC to the igw
* Check subnet ACL
* Make sure your corporate network (firewall) is not blocking the traffic
* Check that your instance has a public IPv4 address
* Check the CPU load on your instance