Bounty:

• Points: 10
• Path: Cloud Engineer

Difficulty:

• Level: 1
• Estimated time: 1-3 hours

Deliverables:

• A DynamoDB table configured based on requirements

Prototype description:

A DynamoDB table needs to be created based on the requirements collected by the team.
Once the table is set up, the team will load the sample data and test the application to make sure everything is back to normal.
One of the tests will attempt to write an item into the new DynamoDB table.

Requirements:

General

• The DynamoDB table name shall start with:

  ooggi-r-events-table-
• The DynamoDB table shall be deployed in the Ireland (eu-west-1) region

Table properties

• The table shall be configured with the On-demand, pay per request option
• The table shall be configured with the Standard Infrequent Access (DynamoDB Standard-IA)
• The table shall use the “AWS managed key” encryption option (The key is stored in your account and is managed by AWS Key Management Service (AWS KMS)

Table Structure / Indexes

• Main Table Schema Partition Key – client_id (Data Type: String)
• Main Table Schema Sort Key – timestamp (Data Type: String)
• Local secondary Index #1 – amount (Data Type: String), LSI Name: amount-index
• Local secondary Index #2 – category (Data Type: String), LSI Name: category-index

Testing set-up

• The Test Helper IAM Role stack should be deployed to allow the testing platform to interact with your DynamoDB table.

Artifacts/Resources:

• To provide the test environment with permissions to interact with your DynamoDB table, the following stack needs to be deployed:
  CloudFormation Template Link
  *The IAM Role ARN (Amazon Resource Name) should later be provided on the solution submission page.
  *The IAM Role ARN can be found in the Outputs section of the deployed CloudFormation stack.

Your mission, if you choose to accept it,
is to deploy a DynamoDB table based on the requirements.

Bounty:

• Points: 20
• Path: Cloud Engineer

Difficulty:

• Level: 2
• Estimated time: 1-6 hours

Deliverables:

• A DynamoDB table configured based on requirements

Prototype description:

A DynamoDB table set up with the relevant main structure and indexes, populated with the sample items provided.
The table design / indexes will support the following queries:

Main query pattern:

• Writing, getting and updating a specific challenge submission item based on its submission ID.
  *Allows the app to record submissions and allows the support team to quickly look up
  submission details in case of issues.

Secondary query pattern:

• Getting all challenge submissions items for a specific challenge.
• Getting all challenge submissions items for a specific challenge from the last X minutes.
  *Allow the team to monitor submissions for specific challenges. This is useful for
  analytics and monitoring for issues.

Requirements:

General

• The DynamoDB table name shall start with:

  ooggi-r-challenge-table-
• The DynamoDB table shall be deployed in the Ireland (eu-west-1) region
• The table shall be configured with the On-demand, pay per request option.

Sample Items

• All sample items provided in the dataset.csv resource file should be written/loaded into the table.
• The Data Types for all properties of the items in DynamoDB shall be set to the String Data Type.

Querying/Indexes

• Given a specific submission_id in a DynamoDB query the relevant item will be returned with all properties.
• Given only a specific challenge_id in a DynamoDB query, all submission items for that challenge shall be returned.
• Given a specific challenge_id and a condition on the submission_time property, the relevant subset of submission items for the specific challenge shall be returned.
  For example: Get all the submission items where challenge_id is equal to X and where the value of submission_time is bigger than Y.

Other properties

• The table shall not allow for duplicate items with the same submission_id to exist.
• The table shall support the strong consistency option for queries to get/read specific submission items based on the submission_id.

Testing set-up

• The Test Helper IAM Role stack should be deployed to allow the testing platform to interact with your DynamoDB table.

Artifacts/Resources:

• A CSV file with the sample DynamoDB items to be loaded into the table:
  dataset.csv
• To provide the test environment with permissions to interact with your DynamoDB table, the following stack needs to be deployed:
  CloudFormation Template Link
  *The IAM Role ARN (Amazon Resource Name) should later be provided on the solution submission page.
  *The IAM Role ARN can be found in the Outputs section of the deployed CloudFormation stack.

Your mission, if you choose to accept it,
is to deploy a DynamoDB table with the required indexes as a proof of concept.

Bounty:

• Points: 30
• Path: Cloud Engineer

Difficulty:

• Level: 3
• Estimated time: 2-12 hours

Deliverables:

• A system that will provide a Kinesis Data Stream for ingestion and write anomalous events to an output Kinesis Data Stream after applying specific anomaly detection logic

Prototype description:

An Amazon Kinesis Data Stream will be used for ingestion of events.
Events written into the main ingestion stream will be read by the anomaly detection service that will apply the required logic. Events that will be detected as anomalous will be written to an output Kinesis Data Stream.

An IAM Role with the relevant IAM policy is needed to generate temporary credentials that will allow the testing system to access both the main ingestion Kinesis stream and the output / anomaly Kinesis Data Stream.
The test will write different events into the main ingestion stream and will expect to find only anomalous events in the output / anomaly stream.

Requirements:

• The prototype shall ingest events via a Kinesis stream and write the events that are detected as anomalous to an output Kinesis stream
• The main ingestion Kinesis stream name shall start with:

  main-input-stream
• The output / anomaly Kinesis stream name shall start with:

  anomaly-stream
• All resources shall be deployed in the Ireland (eu-west-1) region
• Temporary IAM credentials shall be provided for the test that will allow the following API actions on the relevant Kinesis streams
  Main input stream:

  kinesis:PutRecord
  kinesis:PutRecords
  

  Anomaly/output stream:

  kinesis:GetRecords
  kinesis:GetShardIterator
  kinesis:DescribeStream
  kinesis:ListShards
  kinesis:ListStreams
  

• The client application will write events (JSON) with the following structure into the main ingestion Kinesis stream:

  {"event_id" : "[Event ID]" , "transaction_amount" : [Transaction amount]}
  

  Example event:

  {"event_id" : "12345678" , "transaction_amount" : 120}
  
• Events with a transaction_amount value higher than 100, shall be written into the output/anomaly stream
• No action is required at this time on events with a transaction_amount equal or lower than 100
• The original event (with the same structure and JSON data types) is expected in the output/anomaly stream (only relevant events)
• The maximum time from event ingestion into the main ingestion stream to the relevant event being available in the output/anomaly stream shall be 2 seconds

Your mission, if you choose to accept it,
is to deploy an ingestion service with Kinesis with a custom event processing component and an output Kinesis stream.

Bounty:

• Points: 30
• Path: Cloud Engineer

Difficulty:

• Level: 3
• Estimated time: 2-12 hours

Deliverables:

• An SQS queue, a lightweight message processing service and a DynamoDB table, all integrated based on the requirements.

Prototype description:

A standard SQS queue will be used for ingestion of messages. Messages written into the queue will be read by a service that will enrich the events, validate their structure and then write validated requests only into a DynamoDB table.
Basic enriched and validation rules will be provided in the requirement section.
An IAM Role with the relevant IAM policy is required to generate temporary credentials that will allow the testing system to access both the SQS queue and the DynamoDB table.
The test will write messages with specific content to SQS and expect to find the relevant records DynamoDB.

Requirements:

• The new service shall read the messages from the SQS queue, enrich the messages by adding an additional field and write each message as an item into a DynamoDB table.
• The SQS Queue name shall start with:

  challenge-queue
• The DynamoDB table name shall start with:

  challenge-table
• All resources shall be deployed in the Ireland (eu-west-1) region
• Temporary IAM credentials shall be provided for the test that will allow the following API actions on the relevant SQS queue and DynamoDB table in your AWS account.

  sqs:SendMessage
  dynamodb:GetItem
  

• The client application will send messages with the following structure into the SQS queue:

  {"question_id" : "[Question ID]" , "question_text" : "[Question Text]"}
  

  Example message:

  {"question_id" : "1234567" , "question_text" : "How to generate temporary IAM credentials?"}
  
• The DynamoDB table shall be configured with a Partition Key only (no Range/Sort Key)
• The question_id attribute shall be configured as the Partition Key
• All attributes in the DynamoDB table shall be of type String (“question_id”, “question_text”, “user_type”)
• The following item structure is expected in DynamoDB:

  {"question_id" : "[Question ID]" , "question_text" : "[Question Text]", "user_type" : "[Random String]"}
  

  Example message:

  {"question_id" : "1234567" , "question_text" : "How to generate temporary IAM credentials?", "user_type" : "A+"}
  
• The maximum time from message ingestion into the SQS queue to the item being available in the DynamoDB table shall be 2 seconds.

Your mission, if you choose to accept it,
is to deploy an ingestion service with SQS, a custom processing component and DynamoDB.

Bounty:

• Points: 10
• Path: Cloud Engineer

Difficulty:

• Level: 1
• Estimated time: 1 hour

Deliverables:

• An S3 set up supporting pre-signed S3 URLs pointing to an S3 object as described below

Prototype description:

The S3 presigned URL feature would be very useful in this scenario.
The team would like to see how the links can be generated and how expiry time can be set at creation time. They are also interested in the behaviour of expired links and the resulting error type and message.
The S3 presigned URL should provide only temporary access. The S3 object should not be made publicly available.
The proof of concept will consist of a single accessible (active) presigned URL and another URL that has expired.

Requirements:

An active S3 presigned URL with the following properties:

• The url shall have an expiration time of 3 days (259200 seconds)
• The presigned URL shall enable access to an S3 object with the following content:

  {
  "Report ID" : "12345",
  "Report": "Looking good"
  }
  
• The object shall be a simple text file (not a pdf file)
• The S3 object shall not be publicly available (It should only be accessible via the presigned URL)

An expired S3 presigned URL with the following properties:

• The presigned URL provided shall respond with an HTTP 403 Forbidden message (The default behaviour for an expired presigned URL)
• The S3 object shall not be publicly available

Your mission, if you choose to accept it,
is to configure the S3 environment and generate the required URLs.

Bounty:

• Points: 10
• Path: Cloud Engineer

Difficulty:

• Level: 1
• Estimated time: 1 hour

Deliverables:

• A publicly available S3 Static Website with the relevant content

Prototype description:

At this time, a decision was made to use a publicly available S3 Static Website and host the relevant user-friendly error HTML page there.

Later, a Route53 Failover policy will be configured with a health check so that if the main website environment is not responsive (doesn’t pass the Route53 health check) an Alias record will be used to point to the S3 Static Website endpoint.
The S3 bucket configuration must accommodate the above Route53 failover strategy.

It’s understood that the S3 Static Website feature does not support HTTPS and that this set-up will only work for HTTP. At a later time, CloudFront with a custom domain / SSL certificates setup will be considered on top of the static S3 website.

Requirements:

• The S3 bucket shall be created in the Ireland (eu-west-1) region.
• The S3 bucket name shall comply with the following structure:

  www.[your-random-string].com

  *This is to support the Alias record option as part of the Route53 failover policy described above. More information is available in the AWS documentation.
  For example, a valid bucket name can be:

  www.my-random-string.com
• The S3 Static Website will be available on the following URL:

  http://www.[your-random-string].com.s3-website-eu-west-1.amazonaws.com
• HTTPS support is not required (Only HTTP access will be checked).
• The S3 Static Website shall return the following HTML page when accessed on the base path:

  <!doctype html>
  <html>
    <head>
      <title>Title</title>
    </head>
    <body>
      <h1>Something went wrong :/</h1>
      <p>Please try again in a bit.</p>
    </body>
  </html>
  

  For example, when one browses to:

  http://www.[your-random-string].com.s3-website-eu-west-1.amazonaws.com

  They’ll get a basic HTML page with the following content:

  Something went wrong :/
  We’ll be up and running in a bit.
  
• If the website is accessed on any other path, the same HTML page will be returned, with the relevant HTTP response code.
  For example, the following requests will return the same HTML page as described above with a 404 HTTP (NotFound) response code:

  http://www.[your-random-string].com.s3-website-eu-west-1.amazonaws.com/hi
  http://www.[your-random-string].com.s3-website-eu-west-1.amazonaws.com/foo.html
  

Your mission, if you choose to accept it,
is to set up a static S3 website with the required configuration.

Bounty:

• Points: 20
• Path: Cloud Engineer

Difficulty:

• Level: 2
• Estimated time: 1-2 hours

Deliverables:

• A set of temporary credentials (Access Key, Secret Key, Token) that will allow the inspection of a remote AWS account

Prototype description:

IAM Roles and policies should be configured with the principle of least privilege in mind. Once these are in place, temporary AWS credentials should be created to allow the caller to describe the EC2 Security Groups across the account.
The credentials will be passed on security to the team and the test will be executed.
If all works well, this setup will be replicated to other AWS accounts in the organization to facilitate a broader inspection.

Requirements:

• A set of active temporary credentials shall be provided which include an AWS Access Key, Secret Key and Session Token. For Example:
  Access Key ID:

  AKIAIOSFODNN7EXAMPLE

  Secret Access Key:

  wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

  Session Token:

  AQoDYXdzEPT//////////wEXAMPLEtc764bNrC9SAPBSM22wDOk4x4HIZ8j4FZTwdQWLWsKWHGBuFqwAeMicRXmxfpSPfIeoIYRqTflfKD8YUuwthAx7mSEI/qkPpKPi/kMcGdQrmGdeehM4IC1NtBmUpp2wUE8phUZampKsburEDy0KPkyQDYwT7WZ0wq5VSXDvp75YU9HFvlRd8Tx6q6fE8YQcHNVXAkiY9q6d+xo0rKwT38xVqr7ZD0u0iPPkUL64lIZbqBAz+scqKmlzm8FDrypNC9Yjc8fPOLn9FX9KSYvKTr4rvx3iSIlTJabIQwj2ICCR/oLxBA==
• The temporary credentials shall not be valid for longer than 30 minutes.
• The provided credentials shall provide to a calling application with the following permission:

  ec2:DescribeSecurityGroups

• An API call to describe Security Groups in the Ireland (eu-west-1) region shall uncover at least one Security Group with a name prefixed by:

  ooggi-sg-test

  For example:

  ooggi-sg-test-my-sg
• The Security Group can be created in any VPC as long as the region is the Ireland (eu-west-1) region.
• Any other API call using the provided temporary credentials (besides ec2:DescribeSecurityGroups) shall fail with the appropriate error response from the AWS API.

Your mission, if you choose to accept it,
is to set up AWS IAM to allow a remote application to inspect the Security Group configuration of an AWS account.

Bounty:

• Points: 30
• Path: Cloud Engineer

Difficulty:

• Level: 3
• Estimated time: 1-12 hours

Deliverables:

• A live CloudFront deployment with a redirect feature (implemented with CloudFront only or with a custom Origin)

Prototype description:

The team has agreed that a good solution at this time would be to set up an HTTP redirect (301 response code) for the GET method on the resource/path mentioned earlier (https://xxxxxxxxxxxxxx.cloudfront.net/reservations).

The existing 3-tier web application stack behind the ALB can’t be updated or changed.
The redirect needs to be implemented before the request reaches the web/application servers themselves.

A prototype should be created with Amazon CloudFront to simulate the existing environment that will demonstrate this capability. When a specific path is accessed with a GET request, the HTTP client should be redirected to a new domain name as described in the requirements below.
Solutions that will minimize the latency added by the redirect are preferred (A redirect as close as possible to the HTTP client).

Requirements:

• The prototype shall be deployed using the AWS CloudFront service.
  The URL provided for the redirection test must have the following structure:

  https://[distribution-id].cloudfront.net
• A GET request to the following path:

  https://[distribution-id].cloudfront.net/reservations

  Shall result in a HTTP 301 Redirect response to the following location:

  https://ooggi.com/the_blog/
• A GET request to a different path shall not result in a HTTP 301 Redirect response. For example:

  https://[distribution-id].cloudfront.net/

  https://[distribution-id].cloudfront.net/cases
• Any other HTTP method (POST, DELETE, etc) to any path shall not result in a HTTP 301 Redirect response.
• The prototype shall be deployed with a valid HTTPS certificate and accessible with HTTPS.
• The prototype can be deployed as a public API. There’s no need to implement authentication/authorization on Amazon CloudFront.

Your mission, if you choose to accept it,
is to create a prototype with Amazon CloudFront based on the requirements and share the URL with the customer.

Bounty:

• Points: 20
• Path: Cloud Engineer

Difficulty:

• Level: 2
• Estimated time: 1-6 hours

Deliverables:

• A live AWS API Gateway deployment set-up based on the requirements

Prototype description:

As a first step the customer would like to see a working prototype with an authentication feature.
The team that will own the final project is familiar with AWS and manages some AWS infrastructure, such as their EC2 based R&D and Dev/Test environments.
They plan to design and deploy the future application infrastructure needed for the API’s in AWS and have a clear strategy around leveraging managed cloud services when possible.
For the above reason, the request is to deploy the first prototype by leveraging the AWS API Gateway service.

Requirements:

• The prototype shall be deployed using the Amazon API Gateway solution.
• The API DNS Name shall have the following structure:

  *.execute-api.[region_name].amazonaws.com

  example:

  https://xxxxxxxxxx.execute-api.[region_name].amazonaws.com/test

• The API shall be deployed in the closest proximity to the company’s current client base in Sydney, Australia. This in order to reduce latency as much as possible.
• The API shall support authentication by using a key that is specified in the request header.
  API Key to configure as allowed access for the test:

  YpazbHRJmWuaWd7p5y2d

  Request header that will be used in the test:

  x-api-key: "YpazbHRJmWuaWd7p5y2d"

• A GET request with the above header and key to the following path:

  [API Gateway deployment path]/test

  should result in a 200 HTTP response code with an application/json response type with the following content:

  {"test" : "complete"}

• Unauthenticated requests or those with the wrong API key to the above path should result in a response with a 403 HTTP code.

Your mission, if you choose to accept it,
is to create a prototype AWS Gateway deployment based on the requirements and share the URL with the customer.