Introduction
Hi, I'm miruky.
A Lambda test event is JSON input that the AWS Console sends directly to a deployed function. It is useful when I need to separate a handler check from an EventBridge rule, API Gateway route, Amazon SQS queue, or another integration.
This Console run creates a minimal Python function, stores an empty private test event, and reads the fixed response from one synchronous invocation. The handler does not read the event, environment variables, account data, or the invocation context.
Private test events are available only to their creator. AWS currently allows up to 10 private events per function, and the Console documentation says they require no additional permissions to use. A Console test still counts as a Lambda request and execution duration, and the invocation writes a small record to CloudWatch Logs, so current Lambda and CloudWatch pricing still applies.
1. Create a narrow execution role
Lambda functions are Regional, so this exercise keeps the function and its test in us-east-1.
The header confirms the English Console and United States (N. Virginia) before any Regional resource is created.
Open IAM, choose Roles, and create a role for the Lambda service. Attach the AWS managed AWSLambdaBasicExecutionRole policy, then enter the generated role name miruky-vkgewtncrkrrykpz.
The review fixes the generated role name and Lambda use case before creation. AWSLambdaBasicExecutionRole grants the log-group, log-stream, and log-event permissions needed for basic CloudWatch logging; it does not grant access to application data in another AWS service.
Open the new role and choose Trust relationships. The trusted service must be lambda.amazonaws.com, because Lambda assumes this role when it invokes the function.
The trust policy contains lambda.amazonaws.com, the Lambda service principal, while the account-scoped ARN is masked. I also checked that the role had one attached managed policy and no inline policy before using it.
2. Create and deploy the fixed handler
Open Lambda and search for the exact generated function name miruky-wcyrodwkfbmgaqxd. The validation account had no function with that name before creation.
The table reports Functions (0) while the full generated name is in the filter. That empty result establishes the ownership boundary for the function used in this run.
Choose Create function and Author from scratch. Enter miruky-wcyrodwkfbmgaqxd, choose Python 3.14, leave the ARM64 switch off for the default x86_64 architecture, and enable Custom execution role. Select miruky-vkgewtncrkrrykpz as the existing role.
The two retained form sections show the inputs that matter for the exercise. The ARM64 option is off, and its label identifies x86_64 as the default.
After the function is created, replace the sample code in lambda_function.py with this handler and choose Deploy.
def lambda_handler(event, context):
# Keep the response fixed so the test event cannot change the result.
return {"status": "running"}
The default handler setting for a Python function created in the Console is lambda_function.lambda_handler, so the file and function names already match that configuration.
The editor contains no credential, account identifier, environment lookup, or request metadata. The deployment confirmation establishes that the later test runs this version rather than an unsaved editor change.
3. Save an empty private test event
On the function's Test tab, create a new event. Enter the generated event name miruky-debteowwasuirptw, keep Private selected, and replace the template with an empty JSON object:
{}
The handler ignores its input, so an empty object is enough. Keeping the event private avoids creating a shareable EventBridge schema and avoids exposing the event to other IAM users in the account.
The event editor shows {} and leaves Shareable unselected. Choose Save before invoking the function so the same named event can be selected again later.
The success banner contains the generated event name. It confirms that the event was stored before the invocation result was collected.
4. Invoke the deployed function
With miruky-debteowwasuirptw selected, choose Test. The invocation is synchronous, so Lambda waits for the handler response before returning the result or an invocation error.
Expand Details under the execution result. The expected response is:
{
"status": "running"
}
The result reports Executing function: succeeded and returns the same object that the deployed handler contains. Because the event is empty and the response is fixed, this result verifies the deployed runtime, handler name, code, and execution role without adding an external trigger.
This test does not prove that an API Gateway route, queue, stream, schedule, or resource policy is configured correctly. Those integrations need their own end-to-end test with the real event shape and permissions. The private Console event is the smaller check that I run before introducing those variables.
Wrap-up
The useful evidence is a short chain: an exact-name-empty function inventory, a named execution role with Lambda trust, deployed deterministic code, a saved private {} event, and a synchronous success response.
Private events are convenient for repeatable manual checks and account-specific payloads that should not be shared. For a build pipeline or repeated regression suite, move the same assertion into an automated test rather than depending on a person to choose Test in the Console.
Thanks for reading this far.
See you in the next one.
Disclosure: This article was written with AI assistance and independently verified against the linked primary sources and observed results.
