API key management in Microservices - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to generate a unique API key using UUID.

Microservices

import uuid

def generate_api_key():
    return str(uuid.[1]())

Drag options to blanks, or click blank then click option'

Auuid3

Buuid1

Cuuid4

Duuid5

Attempts:

3 left

💡 Hint

Common Mistakes

Using uuid1 which is time-based and less secure.

The uuid4() function generates a random UUID which is ideal for API keys to ensure uniqueness and unpredictability.

2fill in blank

medium

Complete the code to store the API key with an expiration time in a key-value store.

Microservices

def store_api_key(store, key, user_id):
    expiration = 3600  # 1 hour in seconds
    store.set(key, user_id, [1]=expiration)

Drag options to blanks, or click blank then click option'

Aexpire

Bttl

Ctimeout

Dduration

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'expire' which is a method, not a parameter.

The ttl (time to live) parameter is commonly used in key-value stores like Redis to set expiration for keys.

3fill in blank

hard

Fix the error in the code that validates the API key from the request headers.

Microservices

def validate_api_key(request, store):
    api_key = request.headers.get('[1]')
    if not api_key:
        return False
    return store.exists(api_key)

Drag options to blanks, or click blank then click option'

AX-API-Key

BAuthorization

CApi-Key

DToken

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'Authorization' which is for bearer tokens, not API keys.

The standard header for passing API keys is often X-API-Key, which is a common convention for custom headers.

4fill in blank

hard

Fill both blanks to implement rate limiting using API keys and a Redis counter.

Microservices

def is_rate_limited(store, api_key):
    count = store.get(api_key) or 0
    if count [1] 100:
        return True
    store.incr(api_key)
    store.expire(api_key, [2])
    return False

Drag options to blanks, or click blank then click option'

A>=

B<=

C60

D3600

Attempts:

3 left

💡 Hint

Common Mistakes

Using '<=' which would allow too many requests.

Setting expiration to 60 seconds which is too short.

The code checks if the count is greater than or equal to 100 requests, then sets the expiration to 3600 seconds (1 hour) for rate limiting.

5fill in blank

hard

Fill all three blanks to create a dictionary comprehension that maps API keys to user IDs only if the keys are active.

Microservices

active_keys = {key: store.get(key) for key in keys if store.[1](key) and store.[2](key) > 0 and store.[3](key) == 'active'}

Drag options to blanks, or click blank then click option'

Aexists

Bttl

Chget

Dget

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'get' instead of 'hget' for hash fields.

Not checking if the key exists before other calls.

The comprehension checks if the key exists, has a positive TTL (not expired), and the hash field 'active' is set, using exists, ttl, and hget respectively.

Practice

1. What is the primary purpose of API key management in microservices?

easy

A. To generate random data for APIs

B. To speed up API response times

C. To store user passwords securely

D. To control and monitor access to APIs

Solution

1. Step 1: Understand API key management role

   API key management is about controlling who can use APIs and tracking their usage.

2. Step 2: Identify the main goal

   The main goal is to secure APIs by controlling and monitoring access, not speeding up or storing passwords.

3. Final Answer:

   To control and monitor access to APIs -> Option D

4. Quick Check:

   API key management = Access control [OK]

Hint: API keys control who uses your API [OK]

Common Mistakes:

• Confusing API keys with password storage
• Thinking API keys improve speed
• Assuming API keys generate data

2. Which of the following is the correct way to represent an API key in a request header?

easy

A. Auth-Key: <API_KEY>

B. Authorization: Bearer <API_KEY>

C. API-Key: <API_KEY>

D. Key: <API_KEY>

Solution

1. Step 1: Review common API key header formats

   API keys are often sent in headers named API-Key or similar, but Authorization: Bearer is usually for tokens, not API keys.

2. Step 2: Identify the standard header for API keys

   API-Key is the widely accepted header for API keys, making API-Key: <API_KEY> correct.

3. Final Answer:

   API-Key: <API_KEY> -> Option C

4. Quick Check:

   API key header = API-Key [OK]

Hint: API keys use 'API-Key' header, not 'Authorization: Bearer' [OK]

Common Mistakes:

• Using 'Authorization: Bearer' for API keys
• Confusing header names
• Omitting the key value

3. Given this pseudocode for API key validation:

function validateKey(request) {
  key = request.headers['API-Key']
  if key is null or key not in validKeys:
    return 'Access Denied'
  else:
    return 'Access Granted'
}

What will be the output if the request has no 'API-Key' header?

medium

A. Access Denied

B. Error: Missing header

C. Access Granted

D. Access Pending

Solution

1. Step 1: Check header presence condition

   The code checks if the key is null or not in validKeys. If the header is missing, key is null.

2. Step 2: Determine the return value for missing key

   Since key is null, the condition is true, so the function returns 'Access Denied'.

3. Final Answer:

   Access Denied -> Option A

4. Quick Check:

   Missing key = Access Denied [OK]

Hint: No API-Key header means deny access [OK]

Common Mistakes:

• Assuming missing key grants access
• Expecting an error instead of denial
• Confusing 'null' with empty string

4. A developer wrote this code snippet to revoke an API key:

function revokeKey(key) {
  if key in activeKeys:
    activeKeys.remove(key)
  else:
    print('Key not found')
}

But the key is still accepted after revocation. What is the likely issue?

medium

A. The remove method does not delete keys properly

B. The key is not removed from the validKeys list used for validation

C. The function does not print 'Key revoked' message

D. The key is being re-added automatically elsewhere

Solution

1. Step 1: Understand key revocation logic

   The function removes the key from activeKeys, but validation likely checks validKeys.

2. Step 2: Identify mismatch in key storage

   If validation uses validKeys and revoke removes from activeKeys, the key remains valid.

3. Final Answer:

   The key is not removed from the validKeys list used for validation -> Option B

4. Quick Check:

   Revocation must remove key from validation list [OK]

Hint: Revoking must remove key from validation store [OK]

Common Mistakes:

• Removing key from wrong list
• Assuming print messages affect logic
• Ignoring other code re-adding keys

5. You need to design an API key management system for a microservices platform that supports millions of users. Which approach best balances security, scalability, and ease of revocation?

hard

A. Store API keys in a centralized database with caching and use short-lived keys with rotation

B. Embed API keys directly in client apps without server validation

C. Use a single global API key for all users to simplify management

D. Store API keys only in memory on each microservice without persistence

Solution

1. Step 1: Evaluate security and scalability needs

   Millions of users require scalable storage and fast validation. Centralized DB with caching supports this.

2. Step 2: Consider revocation and key rotation

   Short-lived keys with rotation improve security and allow easy revocation without downtime.

3. Step 3: Eliminate insecure or unscalable options

   Embedding keys in clients or using a single key is insecure; in-memory only storage lacks persistence and scalability.

4. Final Answer:

   Store API keys in a centralized database with caching and use short-lived keys with rotation -> Option A

5. Quick Check:

   Central DB + caching + rotation = secure & scalable [OK]

Hint: Use central DB with caching and rotate keys regularly [OK]

Common Mistakes:

• Using single global key for all users
• Not persisting keys for revocation
• Embedding keys insecurely in clients