Deployment Flashcards
You are developing a website which allows customers to purchase tickets to popular sporting events. Your application uses S3 for static web hosting, Lambda for business logic, stores transaction data in RDS and uses DynamoDB for product and stock information. After the customer has paid for their purchase, a message is sent to an SQS queue to trigger a confirmation email to be sent out to the customer including an e-ticket for their chosen event. You want to send out the email as soon as the payment has been processed, however during testing you discover that the confirmation emails are being processed a few seconds before the stock control database has finished updating. This sometimes results in selling the same ticket twice. How can you quickly fix this without re-engineering the application?
Use an SQS delay queue to let you postpone the delivery of SQS messages by a few seconds
Delay queues let you postpone the delivery of new messages to a queue for a number of seconds. If you create a delay queue, any messages that you send to the queue remain invisible to consumers for the duration of the delay period. The default (minimum) delay for a queue is 0 seconds. The maximum is 15 minutes. SQS Delay Queues
You have an application running on a number of Docker containers running on AWS Elastic Container Service. You have noticed significant performance degradation after you made a number of changes to the application and would like to troubleshoot the application end-to-end to find out where the problem lies. What should you do?
Deploy the AWS X-Ray daemon as a new container alongside your application
Within a micro-service architecture, each application component runs as its own service. Micro-services are built around business capabilities, and each service performs a single function. So if you want to add X-Ray to a Dockerized application, it makes the most sense to run the X-Ray daemon in a new Docker container and have it run alongside the other micro-services which make up your application
An application connects to an external third-party service with API keys being managed by AWS Secrets Manager. The development team uses CodeBuild for source code compilation activities in their CI/CD process. Where should the reference to the third-party service API keys be specified?
BuildSpec file
CodeBuild uses the BuildSpec file as a specification of build commands and settings. “secrets-manager” syntax can be used to retrieve API Keys stored in AWS Secrets Manager. Build Environment variables should NOT be used for storing sensitive information as they are displayed in plain text. AppSpec file is used by CodeDeploy to specify and manage deployments. CloudFormation templates are used by CloudFormation and not by CodeBuild.
A serverless application consists of multiple Lambda Functions and a DynamoDB table. The application must be deployed by calling the CloudFormation APIs using AWS CLI. The CloudFormation template and the files containing the code for all the Lambda functions are located on a local computer.
What should the Developer do to deploy the application?
Use the aws cloudformation package command and deploy using aws cloudformation deploy.
The aws cloudformation package command packages the local artifacts (local paths) that your AWS CloudFormation template references. The command uploads local artifacts, such as source code for an AWS Lambda function or a Swagger file for an AWS API Gateway REST API, to an S3 bucket. The command returns a copy of your template, replacing references to local artifacts with the S3 location where the command uploaded the artifacts.
Use this command to quickly upload local artifacts that might be required by your template. After you package your template’s artifacts, run the aws cloudformation deploy command to deploy the returned template.
Since we have local artifacts (source code for the AWS Lambda functions), we should use the package command. After running the package command, we must deploy the packaged output file by running the deploy command.
