Helicopter Racing League (HRL) is a global sports league for competitive helicopter racing.
Each year HRL holds the world championship and several regional league competitions where teams compete to earn a spot in the world championship.
HRL offers a paid service to stream the races all over the world with live telemetry and predictions throughout each race.
Solution concept - HRL wants to migrate their existing service to a new platform to expand their use of managed AI and ML services to facilitate race predictions.
Additionally, as new fans engage with the sport, particularly in emerging regions, they want to move the serving of their content, both real-time and recorded, closer to their users.
Existing technical environment - HRL is a public cloud-first company; the core of their mission-critical applications runs on their current public cloud provider.
Video recording and editing is performed at the race tracks, and the content is encoded and transcoded, where needed, in the cloud.
Enterprise-grade connectivity and local compute is provided by truck-mounted mobile data centers.
Their race prediction services are hosted exclusively on their existing public cloud provider.
Their existing technical environment is as follows:Existing content is stored in an object storage service on their existing public cloud provider.Video encoding and transcoding is performed on VMs created for each job.Race predictions are performed using TensorFlow running on VMs in the current public cloud provider.
Business requirements - HRL's owners want to expand their predictive capabilities and reduce latency for their viewers in emerging markets.
Their requirements are:Support ability to expose the predictive models to partners.Increase predictive capabilities during and before races: -‹ Race results -‹ Mechanical failures -‹ Crowd sentimentIncrease telemetry and create additional insights.Measure fan engagement with new predictions.Enhance global availability and quality of the broadcasts.Increase the number of concurrent viewers.Minimize operational complexity.Ensure compliance with regulations.Create a merchandising revenue stream.
Technical requirements -Maintain or increase prediction throughput and accuracy.Reduce viewer latency.Increase transcoding performance.Create real-time analytics of viewer consumption patterns and engagement.Create a data mart to enable processing of large volumes of race data.
Executive statement - It must provide low latency at minimal cost.
It must be able to identify duplicate credit cards and must not store plaintext card numbers.
It should support annual key rotation.
Which storage approach should you adopt for your tokenization service?
Click on the arrows to vote for the correct answer
A. B. C. D.D.
To address the storage requirements for the tokenization service, we need to consider the business and technical requirements as well as the executive statement. The tokenization service is responsible for tokenizing credit card data and storing the tokens for subsequent use in HRL's systems. The key requirement for this service is to ensure the security and privacy of the credit card data while providing a low latency and scalable solution. Let's analyze each option and see which one fits best.
Option A: Store the card data in Secret Manager after running a query to identify duplicates. This option proposes to store the card data in Secret Manager after identifying and removing duplicates. Secret Manager is a fully managed secret management service that enables you to store and manage sensitive data such as API keys, passwords, certificates, and other secrets. While Secret Manager provides secure storage for sensitive data, it is not designed for storing large amounts of data such as credit card numbers. Also, this option does not provide tokenization, which means the credit card numbers are still stored in plaintext, which poses a significant security risk. Therefore, this option is not suitable for the tokenization service.
Option B: Encrypt the card data with a deterministic algorithm stored in Firestore using Datastore mode. This option suggests encrypting the card data with a deterministic algorithm and storing it in Firestore using Datastore mode. Firestore is a flexible, scalable, and fully managed NoSQL document database that provides real-time synchronization and offline support for mobile and web applications. Using deterministic encryption ensures that the same credit card number always generates the same token, which is required for tokenization. Firestore provides a secure storage solution for the encrypted data, and its scalable nature can accommodate large volumes of data. However, using a deterministic algorithm for encryption may not be secure enough, as it can potentially allow an attacker to reverse-engineer the encryption key and decrypt the credit card numbers. Additionally, using Firestore can increase the latency, which is not in line with the executive statement requirement for low latency. Therefore, while Firestore is a suitable storage solution for some use cases, it is not ideal for tokenization service.
Option C: Encrypt the card data with a deterministic algorithm and shard it across multiple Memorystore instances. This option proposes encrypting the card data with a deterministic algorithm and sharding it across multiple Memorystore instances. Memorystore is a fully managed Redis service that provides in-memory data storage and caching. Sharding enables distributing the data across multiple Redis instances to improve performance and scalability. Using deterministic encryption ensures that the same credit card number always generates the same token, which is required for tokenization. Sharding the data across multiple Memorystore instances provides a highly scalable and low-latency solution for tokenization. However, using a deterministic algorithm for encryption may not be secure enough, as it can potentially allow an attacker to reverse-engineer the encryption key and decrypt the credit card numbers. Therefore, while this option provides a highly scalable and low-latency solution for tokenization, it may not be secure enough for storing credit card data.
Option D: Use column-level encryption to store the data in Cloud SQL. This option suggests using column-level encryption to store the data in Cloud SQL. Cloud SQL is a fully managed relational database service that supports MySQL, PostgreSQL, and SQL Server. Column-level encryption enables encrypting specific columns in a table, providing fine-grained access control and secure storage for sensitive data. Cloud SQL provides a scalable and highly available storage solution for the encrypted credit card data. Using column-level encryption ensures that the data is encrypted at rest, and key rotation can be performed annually, as required by the executive statement. This option provides a secure and scalable solution for the tokenization service while meeting all the business and technical requirements.
Conclusion: Option D, using column-level encryption to store the data in Cloud SQL, is the most suitable