AWS DVA-C02 Drill: API Gateway API Keys - The Usage Plan Association Trap

Jeff’s Note

#

Jeff’s Note

#

“Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.”

“For DVA-C02 candidates, the confusion often lies in mistaking API key creation for complete API key activation. In production, this is about knowing exactly the three-step API Gateway API key lifecycle: Create → Associate → Deploy. The exam loves testing whether you understand that CreateApiKey alone doesn’t grant access—you must explicitly link it to a Usage Plan. Let’s drill down.”

The Certification Drill

#

Scenario

#

TechStream Solutions operates a subscription-based analytics API platform. The backend team uses Amazon API Gateway with native API key validation to control access. After launching a new customer onboarding portal, the development team implemented automatic API key provisioning: when a user completes registration, the system calls the CreateApiKey SDK method and emails the generated key to the user.

However, support tickets are flooding in—newly registered users receive 403 Forbidden errors when attempting their first API call. Existing customers continue to access the API without any issues. The development team has verified that:

• The API keys are successfully created in API Gateway
• The keys are being transmitted correctly to users
• The API Gateway stage is deployed and functional for existing users

The Requirement

#

Identify the specific SDK method call that must be added to the registration workflow to grant new users immediate API access without disrupting existing customers.

The Options

#

• A) Call the createDeployment method to redeploy the API and include the newly created API key in the current stage
• B) Call the updateAuthorizer method to update the API’s authorizer configuration to recognize the newly created API key
• C) Call the importApiKeys method to import all newly created API keys into the current stage of the API Gateway
• D) Call the createUsagePlanKey method to associate the newly created API key with the correct usage plan

Correct Answer

#

Option D.

Quick Insight: The API Key Lifecycle Imperative

#

For DVA-C02 Developers, this tests your understanding of the two-phase API key activation model:

1. Creation Phase: CreateApiKey generates the key but leaves it orphaned
2. Association Phase: CreateUsagePlanKey binds the key to a Usage Plan (which defines throttling, quota, and stage access)

An API key without a Usage Plan association is like a database credential without IAM permissions—it exists but grants no access. This is a critical SDK implementation detail that separates candidates who’ve built production API Gateway integrations from those who’ve only read documentation.

Content Locked: The Expert Analysis

#

You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?

The Expert’s Analysis

#

Correct Answer

#

Option D: Call the createUsagePlanKey method

The Winning Logic

#

The solution requires understanding API Gateway’s three-tier access control architecture:

1. API Key Creation (CreateApiKey): Generates a token but grants zero permissions
2. Usage Plan Association (CreateUsagePlanKey): Links the key to a Usage Plan that defines:
   • Which API stages the key can access
   • Throttling limits (requests per second)
   • Quota limits (total requests per day/week/month)
3. Stage Deployment (already exists for existing users): Makes the API callable

Why Option D is correct:

• The SDK method createUsagePlanKey accepts two required parameters:

  {
    "usagePlanId": "abc123",
    "keyId": "def456",
    "keyType": "API_KEY"
  }
  

• This creates a UsagePlanKey resource that binds the orphaned API key to the existing Usage Plan
• The binding is immediate—no redeployment required
• Existing users are unaffected because their keys already have Usage Plan associations

Developer-Specific Implementation Detail: After calling CreateApiKey, you must capture the id field from the response (not the value field) and pass it as keyId to CreateUsagePlanKey. This is a common production bug—developers often confuse the API key’s display value (sent to users) with its resource ID (used for API calls).

The Trap (Distractor Analysis)

#

Why not Option A (createDeployment)?

• Deployment controls when API configuration changes (resources, methods, integrations) become live
• It has no relationship to API key permissions
• Calling createDeployment without configuration changes simply creates a redundant deployment version
• The exam tests whether you know that API keys and deployments are orthogonal concerns

Why not Option B (updateAuthorizer)?

• This is a category error: API Gateway has two separate authentication mechanisms:
  1. Authorizers (Lambda/Cognito-based, for JWT/OAuth tokens)
  2. API Keys (native API Gateway feature)
• The updateAuthorizer method modifies Lambda authorizer configurations—it doesn’t interact with the API key system at all
• This distractor exploits confusion between authentication types

Why not Option C (importApiKeys)?

• ImportApiKeys is designed for bulk migration scenarios (importing keys from CSV files)
• It’s a management operation, not part of the runtime provisioning workflow
• Even if called, it doesn’t create Usage Plan associations—you’d still need CreateUsagePlanKey
• Performance anti-pattern: importing all keys on every registration would cause exponential overhead

The Technical Blueprint

#

Production-Ready Registration Flow (Python SDK Example):

import boto3
import json

client = boto3.client('apigateway')

def provision_new_user_api_access(email, usage_plan_id):
    """
    Complete API key provisioning workflow for new user registration.
    
    Args:
        email: User's email address
        usage_plan_id: The existing Usage Plan ID (e.g., 'abc123')
    
    Returns:
        str: The API key value to send to the user
    """
    
    # Step 1: Create the API Key
    try:
        create_response = client.create_api_key(
            name=f'key-{email}',
            description=f'API key for {email}',
            enabled=True
        )
        
        api_key_id = create_response['id']        # Resource ID for AWS operations
        api_key_value = create_response['value']  # Secret value for user
        
        print(f"✓ Created API key with ID: {api_key_id}")
        
    except Exception as e:
        print(f"✗ CreateApiKey failed: {str(e)}")
        raise
    
    # Step 2: Associate with Usage Plan (THE CRITICAL STEP)
    try:
        client.create_usage_plan_key(
            usagePlanId=usage_plan_id,
            keyId=api_key_id,           # NOT api_key_value!
            keyType='API_KEY'
        )
        
        print(f"✓ Associated key {api_key_id} with Usage Plan {usage_plan_id}")
        
    except Exception as e:
        # Cleanup: Delete the orphaned API key
        client.delete_api_key(apiKey=api_key_id)
        print(f"✗ CreateUsagePlanKey failed, rolled back key creation: {str(e)}")
        raise
    
    # Step 3: Return the key value to send to user
    return api_key_value

# Example usage
if __name__ == "__main__":
    new_key = provision_new_user_api_access(
        email='[email protected]',
        usage_plan_id='xyz789'  # Retrieve from environment/config
    )
    
    # Send new_key to user via email/SMS
    print(f"Send this key to user: {new_key}")

Key Implementation Notes:

1. Error Handling: Always wrap in try-except to handle race conditions
2. Idempotency: Check if key already exists before creation (use get_api_keys with filter)
3. Cleanup Logic: Delete orphaned keys if Usage Plan association fails
4. CloudWatch Logging: Log both api_key_id and association status for troubleshooting

The Comparative Analysis

#

DVA-C02 Exam Pattern:

• AWS always expects the most specific, low-overhead solution
• When you see “403 Forbidden” with API keys → think missing Usage Plan association
• When you see “newly created resource not working” → check for two-step activation requirements (common in API Gateway, Cognito, Secrets Manager)

Real-World Application

#

Exam Rule

#

“For the DVA-C02 exam, when you see an API Gateway scenario where CreateApiKey is called but 403 errors occur, immediately select the option mentioning Usage Plan association (CreateUsagePlanKey). Ignore any distractors mentioning deployment or authorizers—they’re testing whether you know the API key lifecycle.”

Real World

#

“In production systems at scale, we implement several enhancements beyond the exam scenario:

1. Usage Plan Tiering: Maintain separate Usage Plans for Free/Pro/Enterprise tiers with different rate limits

   usage_plan_mapping = {
       'free': 'usageplan-free-tier',
       'pro': 'usageplan-pro-tier',
       'enterprise': 'usageplan-enterprise-tier'
   }
   

2. Idempotency with DynamoDB: Store key associations in DynamoDB to prevent duplicate provisioning during retries

3. Async Provisioning: Use SQS + Lambda to decouple key creation from registration flow (improves user experience during API Gateway throttling)

4. Key Rotation Strategy: Implement automatic 90-day key rotation using EventBridge + Lambda, calling UpdateApiKey to mark old keys as disabled before creating replacements

5. Monitoring: Set CloudWatch alarms on the Count metric for 4XX errors filtered by API key ID to catch provisioning failures immediately

The exam tests the minimum viable implementation. Production systems require defensive programming around API Gateway’s eventual consistency model (especially when creating and immediately associating resources).”

Stop Guessing, Start Mastering

#

Disclaimer

This is a study note based on simulated scenarios for the AWS DVA-C02 exam. All company names and scenarios are fictional and created for educational purposes. Always refer to official AWS documentation and hands-on practice for certification preparation.