Request More Information

Email:  WhatsApp:

koenig-logo

AWS Certified Solutions Architect – Professional (Advanced Architecting on AWS) Quiz Questions and Answers

Answer :
  • Create a CloudFront distribution with S3 access restricted only to the CloudFront identity and partition the blog entry’s location in S3 according to the month it was uploaded to be used with CloudFront behaviors.

Explanation :

The scenario here is that (a) blogs have high access/updates rate in the first 3 months of their creation, (b) this rate drops after 6 months. The main architectural consideration is that the user's load time of the blog needs to be improved. This question is based on making the best use of CloudFront's Cache Behavior. You need to understand two things about CloudFront for such scenario: (1) CloudFront is a service that is designed to give geographically distributed users the fast access to the content by maintaining the content in the cache that is maintained at multiple edge locations, and (2) using the cache-behavior of CloudFront, you can control the origin and path of the content, time to live (TTL), and control the user access using trusted signers. In this scenario, you need to control the content based on the time period at which the blog is published. i.e. when a blog is published, you need to cache the update for first 3 months, so that it can be quickly accessed by the users, and after six months from the update, the content can be removed from the cache, as it is rarely accessed. Also, you need to make sure that the content is only accessed by the CloudFront. Option A is incorrect because maintaining two separate buckets is not going to improve the load time for the users. Option B is incorrect as the location-wise distribution is not going to improve the load time for the users. Option C is CORRECT because it (a) the content is only accessed by CloudFront, and (b) if the content is partitioned at the origin based on the month it was uploaded, you can control the cache behavior accordingly, and keep only the latest updated content in the CloudFront cache, so that it can be accessed with fast load-time; hence, improving the performance. Option D is incorrect. The scenario states that the customer is running a public access blogging website. So there is no need to restrict viewer access.
Answer :
  • The mobile application will send the device location using SQS. EC2 instances will retrieve the relevant offers from DynamoDB. AWS Mobile Push will be used to send offers to the mobile application.

Explanation :

The scenario has following architectural considerations: (1) the users should get notifications about the real estate in the area near to their location, (2) only subscribed users should get the notification, (3) the notification delivery should be fast, (4) the architecture should be scalable, and (5) it should be cost effective. When the question has considerations for scalability, always think about DynamoDB as it is the most recommended database solution to handle huge amount of data/records. For automated notifications, always think about SNS. Option A is incorrect because (a) setting up EC2 instances and ELB to handle 5 millions users will not be cost effective, and (b) sending the notifications via mobile earners/device providers as alerts is neither feasible nor cost effective (certainly not as cost effective as SNS). Option B is incorrect because (a) setting up EC2 instances and ELB to handle 5 millions users will not be cost effective, (b) receiving location via Direct Connect and carrier connection is not cost effective, also it does not deal with subscriptions, and (c) sending the notifications via mobile carriers as alerts is not cost effective (certainly not as cost effective as SNS). Option C is CORRECT because (a) SQS is a highly scalable, cost effective solution for carrying out utility tasks such as holding the location of millions of users, (b) it uses highly scalable DynamoDB, and (c) it uses the cost effective AWS SNS Mobile Push service to send push notification messages directly to apps on mobile devices. Option D is incorrect because AWS SNS Mobile Push service to used for sending push notification messages to the mobile devices, not to get the location of the mobile devices.
Answer :
  • Use S3 to store I/O files. Use SQS to distribute elaboration commands to a group of hosts working in parallel. Then use Auto scaling to dynamically size the group of hosts depending on the length of the SQS queue.

Explanation :

The scenario in this question is that (a) there any EC2 instances that need to process high number of input files, (b) currently the processing takes 20 hrs a day, which needs to be reduced, (c) the availability needs to be improved. Looking at all the option, it appears that there are two choices to be made. (1) between S3 and EBO with PIOPS, and (2) between SQS and SNS. First, let's see whether we should choose S3 or EBS with PIOPS. It appears that all the options have auto-scaling in common. i.e. there will be multiple EC2 instances working in parallel on the input data. This should reduce the overall elaboration time, satisfying one of the requirements. Since a single EBS volume cannot be attached to multiple instances, using EBS volume seems an illogical choice. Moreover, S3 provides high availability, which satisfies the other requirement. Second, SQS is a great option to do the autonomous tasks and can queue the service requests and can be scaled to meet the high demand. SNS is a mere notification service and would not hold the tasks. Hence, SQS is certainly the correct choice. Option A is CORRECT because, as mentioned above, it provides high availability, and can store the massive amount of data. Auto-scaling of EC2 instances reduces the overall processing time and SQS helps distributing the commands/tasks to the group of EC2 instances. Option B is incorrect because, as mentioned above, neither EBS nor SNS is a valid choice in this scenario. Option C is incorrect because, as mentioned above, SNS is not a valid choice in this scenario. Option D is incorrect because, as mentioned above, EBS is not a valid choice in this scenario.
Answer :
  • Stateless instances for the web and application tier that are in an auto-scaling group, synchronized using Elasticache Memcached and monitored with CloudWatch. RDS configured with reading replicas for the backend.

Explanation :

The scenario asks for 2 things: (1) a performance improving solution for read heavy web tier and database tier. Hint: Always see if any of the options contain caching solution such as ElastiCache, CloudFront, or Read Replicas, and (2) whether to use stateless or stateful instances. Stateful instances are not suitable for distributed systems, as they retain the state or connection between client and web server, database remains engaged as long as the session is active. Hence, it increases the load on the server as well as database. Stateless instances, however are distributed and easy to scale in/scale out. Hence, the stateless application tend to improve the performance of a distributed application. Option A is CORRECT because (a) it uses stateless instances, (b) the web server uses ElastiCache for read operations, (c) it uses CloudWatch which monitors the fluctuations in the traffic and notifies to auto-scaling group to scale in/scale out accordingly, and (d) it uses read replicas for RDS to handle the read heavy workload. Option B is incorrect because (a) it uses stateful instances, and (b) it does not use any caching mechanism for web and application tier. Option C is incorrect because (a) it uses stateful instances, (b) it does not use any caching mechanism for web and application tier, and (c) multi-AZ RDS does not improve read performance. Option D is incorrect because multi-AZ RDS does not improve read performance.
Answer :
  • Use CloudFront and an Elastic Load Balancer in front of an auto-scaled set of web servers, the web servers will first login with Amazon service to authenticate the user, the web servers will process the users' vote and store the result into an SQS queue using IAM Roles for EC2 Instances to gain permissions to the SQS queue. A set of application servers will then retrieve the items from the queue and store the result into a DynamoDB table.

Explanation :

This scenario has following architectural considerations:(1) the application need to be scalable so that it can handle traffic coming from millions of users, (2) the application should handle rapid influx of traffic maintaining good performance, and (3) the cost should be kept to minimum. When the application needs to handle the data coming from millions of users, always think about using DynamoDB. Also, to provide the global users with high performance content access, you need to consider CloudFront, and you need to set the appropriate IAM Role for the front end / web servers to give access to DynamoDB tables. Option A is incorrect because multi-AZ RDS is expensive solution compared to DynamoDB. Option B is incorrect because although this would work, it is not scalable and storing all the data directly in DynamoDB would consume read and write capacity and increase the cost. Option C is incorrect because it is not scalable and storing all the data directly in DynamoDB would consume read and write capacity and increase the cost. Option D is CORRECT because (a) it is highly scalable, (b) creates appropriate IAM Role to access the DynamoDB database, and (c) more importantly uses SQS to hold the user data/votes such that the application does not consume read and write provisioned capacity of DynamoDB.
Answer :
  • Use a separate ELB for each instance type and distribute the load to ELBs with Route53 Weighted Routing.

Explanation :

In this question, the problem is that the newly added c5.2xlarge instances are not fully utilized. This is happening because the load is spread evenly across all the instances. There is no logic on how much traffic is to be routed to which instance types. Hence, there is need to add some logic where higher (more-weighted) traffic should be routed to c5.2xlarge instances and light-weighted to the other instances. Route 53's weighted routing policy does exactly this, so you should look for this option. Option A is CORRECT because it first creates separate ELBs, one each for set of different instance type and uses Route 53's weighted routing policy such that higher proportion of the load is routed to the ELB that has c5.2xlarge instances and smaller proportion to the one with smaller instances. Option B is incorrect because shutting down c5.2xlarge instances will not be an effective use of the EC2 capacity. You have already paid for the instance. So you would lose money here. Option C is incorrect because latency based routing may not always distribute heavy traffic to the large instance. You must use weighted routing policy. Option D is incorrect because this option is not a good use of the existing capacity, and in fact, would add to the cost.
Answer :
  • File a change request to implement Proxy Protocol Support. The application uses an ELB with a TCP Listener and Proxy Protocol enabled to distribute the load on two application servers in different AZs.

Explanation :

AWS ELB has support for Proxy Protocol. It simply depends on a humanly readable header with the client's connection information to the TCP data sent to your server. As per the AWS documentation, the Proxy Protocol header helps you identify the IP address of a client when you have a load balancer that uses TCP for back-end connections. Because load balancers intercept traffic between clients and your instances, the access logs from your instance contain the IP address of the load balancer instead of the originating client. You can parse the first line of the request to retrieve your client's IP address and the port number. Option A is CORRECT because it implements the proxy protocol and uses ELB with TCP listener. Option B is incorrect because, although implementing cross-zone load balancing provides high availability, it is not going to give the IP address of the clients. The answer for B is still wrong because it states to use TCP forwarding, which does not support X-Forwarded-For. Option C is incorrect because Route53 latency based routing does not give the IP address of the clients. Option D is incorrect because Route53 Alias record does not give the IP address of the clients.
Answer :
  • Setup a DynamoDB table with an item for each user having the necessary attributes to hold the user preferences. The mobile application will query the user preferences directly from the DynamoDB table. Utilize STS. Web Identity Federation, and DynamoDB Fine-Grained Access Control to authenticate and authorize access.

Explanation :

This scenario has following architectural considerations:(1) the application should support millions of customers, so it should be scalable, (2) multiple mobile devices should be able to access the application, and (3) it should be cost effective, highly available and secure. Tip: Whenever the application needs to (a) support millions of users and scalability is most important, always think about DynamoDB, and (b) give mobile apps the access to AWS resource/service, always think about federated acccess using Web Identity Provider and "AssumeRoleWithWebIdentity" API. Option A is incorrect because RDS MySQL is not as scalable and cost-effective as DynamoDB. Option B is CORRECT because (a) it uses DynamoDB for scalability and cost efficiency, (b) It uses federated acccess using Web Identity Provider, and (c) uses fine grained access priviledges for authenticating the access. Option C is incorrect because (a) RDS MySQL is not as scalable and cost-effective as DynamoDB, and (b) user management and access privilege system cannot be used for controlling access. Option D is incorrect because accessing the data via S3 would be slower compared to DynamoDB.
Answer :
  • Create an RDS Read Replica for the batch analysis and SNS to notify the on-premises system to update the dashboard.

Explanation :

There are two architectural considerations here. (1) you need to improve read performance by reducing the load on the RDS MySQL instance, and (2) automate the process of notifying to the on-premise system. When the scenario asks you to improve the read performance of a DB instance, always look for options such as ElastiCache or Read Replicas. And when the question asks you to automate the notification process, always think of using SNS. Option A is incorrect because Redshift is used for OLAP scenarios whereas RDS is used for OLTP scenarios. Hence, replacing RDS with Redshift is not a solution. Option B is incorrect because Redshift is used for OLAP scenarios whereas RDS is used for OLTP scenarios. Hence, replacing RDS with Redshift is not a solution. Option C is CORRECT because (a) it uses Read Replicas which improves the read performance, and (b) it uses SNS which automates the process of notifying the on-premise system to update the dashboard. Option D is incorrect because SQS is not a service to be used for sending the notification.
Answer :
  • Use S3 to store and serve the scanned files. Use CloudSearch for query processing, and use Elastic Beanstalk to host the website across multiple availability zones.

Explanation :

This question presents following scenarios: (1) type of storage that can store large amount of data (17TB), (2) the commercial search product is at the end of its life, and (3) the architecture should be cost effective, highly available, and durable. Tip: Whenever a storage service that can store large amount of data with low cost, high availability, and high durability, always think about using S3. Option A is incorrect because even though it uses S3, it uses the commercial search software which is at the end of its life. Option B is incorrect because striped EBS is not as durable of a solution as S3 and certainly not as cost effective as S3. Also, it has maintenance overhead. Option C is CORRECT because (a) it uses S3 to store the images which is cost-effective, (b) instead of the commercial product that is at its end of life, it uses CloudSearch for query processing, and (c) with multi AZ implementation, it achieves high availability. Option D is incorrect because with single AZ RDS instance, it does not have high availability.