DEV Community: Olumuyiwa Kolayemi

Certified Cloud Native Platform Engineering Associate Exam: Know Before You Go

Olumuyiwa Kolayemi — Fri, 20 Jun 2025 12:16:30 +0000

"My experience taking the Certified Cloud Native Platform Engineering Associate (CNPA) beta exam and how you can prepare effectively."

CNPA: Know Before You Go

I recently had the opportunity to take the Certified Cloud Native Platform Engineering Associate (CNPA) beta exam on May 11. It was a 3-hour, proctored exam with 185 questions, administered via PSI. I’m pleased to share that I passed the exam with a score of 94%, well above the 75% passing threshold.

Now that the certification has been officially released, it's clear that CNPA is designed to validate your foundational knowledge of cloud-native technologies, covering core concepts like microservices, containers, CI/CD, Infrastructure as Code (IaC), observability, and platform security. Whether you're a platform engineer, DevOps practitioner, SRE, or cloud-native enthusiast, this certification offers a practical entry point for those with 6–12 months of hands-on experience in a supporting role within platform engineering teams.

The official exam is 90 minutes long, consists of multiple-choice questions, and includes one retake. Certification is valid for two years, and candidates have a 12-month window of eligibility to schedule their exam.

Want to see the exam domains? Check them out here

My Experience and Study Strategy

While the CNPA is designed as an introductory certification, my previous experience with KCNA (Kubernetes and Cloud Native Associate) proved incredibly valuable. KCNA laid the groundwork for many core concepts that appeared in the CNPA.

A Tight Timeline

Since this was a beta exam, no official study materials were available when I got the invite. I had just one week to prepare. Here's what worked for me:

1. ChatGPT Deep Search for Study Notes

I used ChatGPT’s Deep Search feature to generate detailed study notes for each domain of the exam. These notes included key definitions, principles, tools, and best practices.

2. NotebookLM + Podcast-Style Learning

A friend introduced me to NotebookLM by Google, and it was a game-changer. I transformed my notes into a 32-minute, two-host podcast, which I could listen to while juggling chores and “dad duty” with my two daughters.

You can find both my study notes and the audio podcast here: audio podcast

Note:

The Linux Foundation Education team released official training content alongside the exam earlier this month. After reviewing the published domains and competencies on their platform, I can confidently say it covers everything you need to succeed in the exam. I’ve included a link to the course in the resources section of this article.

Key Topics You Should Master

Here’s a high-level checklist of concepts you should understand before taking the CNPA exam:

Platform Engineering Principles
DevOps and Platform Engineering: Where they overlap
DORA Metrics for platform performance
Deep understanding of GitOps:
- Understanding of operational models in GitOps workflows
- Familiarity with synchronization and state management mechanisms
Mechanisms for maintaining system consistency through state reconciliation
- Awareness of configuration management strategies in modern delivery pipelines
Selecting appropriate orchestration and provisioning frameworks based on workload requirements
Policy engines in the cloud-native stack
Approaches to secure inter-service communication within distributed systems
Understanding service orchestration frameworks based on traffic management and policy enforcement needs
Approaches to enforcing access control and traffic segmentation in containerized environments
Foundational knowledge of observability practices in cloud-native platforms:
- Understanding core capabilities
- Recognizing current limitations
- Awareness of complementary ecosystem tools
The Kubernetes Reconciliation Loop
What are Internal Developer Platforms (IDPs)?
- Building extensible, API-first systems
- Facilitating self-service via developer portals
- How to measure IDP success

Recommended Resources

Review Important Exam information (including exam curriculum) here:

Final Thoughts

If you can confidently tackle the topics listed above, you're in great shape for the CNPA. Whether you're new to platform engineering or looking to formalize your knowledge, this exam offers a meaningful credential for the cloud-native ecosystem.

I'd love to hear your thoughts or answer questions if you're preparing for the exam!

Connect with Me

Thanks for reading — and good luck on your CNPA journey!

Cross-Account Parameter Sharing in AWS with RAM using Terraform: A Practical Guide

Olumuyiwa Kolayemi — Wed, 26 Mar 2025 04:55:12 +0000

Introduction

Many organizations maintain common system configuration parameters that are stored centrally and shared across different cloud environments. For instance, an organization's security team might be tasked with creating a golden AMI that is compliant and certified for use across their AWS environments and accounts. While AMI IDs themselves are not inherently sensitive, they can become a concern in specific contexts—such as when they point to proprietary, internal, or specially configured images that reveal details about the organization's infrastructure. Managing multiple AWS accounts often involves securely sharing such sensitive configuration data—like AMI IDs in these contexts, along with API keys, database credentials, or application secrets—across accounts. If exposed, these configurations could compromise security or critical infrastructure. The key players for this implementation are SSM Parameter Store and RAM.

AWS Resource Access Manager (RAM) allows for the secure sharing of AWS resources, such as subnets, transit gateways, and Systems Manager (SSM) parameters, across accounts in your organization or with specific AWS accounts. By enabling centralized access to shared resources, RAM reduces duplication and improves efficiency in multi-account setups. When integrated with SSM, RAM facilitates the secure sharing of advanced parameters, making it easier to manage sensitive configuration data across accounts while maintaining security and scalability.

AWS Systems Manager (SSM) Parameter Store is a secure and scalable solution for managing configuration data and secrets. One of its standout features is the ability to organize parameters using a hierarchical naming structure (e.g., /prod/app1/db-password), which makes it easier to logically group and retrieve related configurations. This structured approach simplifies parameter management across multiple environments and applications. Moreover, SSM Parameter Store supports cross-account sharing of parameters, enhancing collaboration in multi-account setups. Something to keep in mind for this use case is that the SSM parameter being shared must meet a few key requirements. Specifically, it must be an Advanced Tier SSM parameter and must be encrypted with a customer-managed key if you are sharing secured strings.

If you are very familiar with AWS, I know you must be thinking that yes, you can use AWS Secrets Manager for this. To clarify your options, here’s a comparison of SSM Parameter Store (Advanced Tier) and AWS Secrets Manager, two services that can handle configuration data effectively in AWS:

Fig 1: Comparison between SSM Parameter Store (Advanced Tier) & Secrets Manager

With this comparison and requirements in mind, you can better understand which service aligns with your use case as we dive into implementing a solution for securely sharing AWS Systems Manager parameters.

Architecture Overview

Fig 2: Cross-Account Parameter Sharing Architecture

The solution involves two AWS accounts:

Security Account: Acts as the source of truth for sensitive parameters. It stores and shares parameters securely using AWS SSM Parameter Store and AWS RAM.
Development Account: Consumes the shared parameters to deploy resources, such as EC2 instances, using Terraform.

Key AWS Services Used:

AWS Systems Manager Parameter Store: For storing and managing parameters.
AWS Resource Access Manager (RAM): For securely sharing resources across accounts.
AWS Key Management Service (KMS): For encrypting sensitive parameters.
AWS EC2: For deploying resources that consume shared parameters.

Prerequisite set up:

For my developer environment set up, I use VSCode with AWS CLI that is configured with an Admin User profile in the AWS Security account. I created two separate folders - security_account and dev_account to have separate terraform states for resources deployed to these different environments/accounts. See folder structure below.

Fig 3: Implementation Folder Structure

Provider configuration of the security account:

This file ensures that Terraform is properly authenticated and authorized to create and manage resources in the security account.
Key details to note;

Profile: Indicates the AWS CLI profile to use for authentication. In this case, the profile Muyi-Admin is used, which corresponds to an IAM user with administrative privileges in the security account.

Fig 4: Terraform User for Security Account Deployments

Provider configuration of the dev account:

For the dev account, I used the AssumeRole method of authentication for terraform deployments.

In this setup, the Development Account does not have direct access to resources (e.g., SSM parameters) in the Security Account. To securely retrieve these resources, the Development Account assumes an IAM role in the Security Account that has the necessary permissions. This is achieved using the assume_role block in the AWS provider configuration. See image below.

# AWS Provider configuration for dev account
provider "aws" {
  region = "us-west-2"
  assume_role {
    role_arn     = "arn:aws:iam::${dev_account_id}:role/TerraformAssumeRole"
    session_name = "dev-muykol"
  }
}

AWS generates temporary security credentials (access key, secret key, and session token) for the assumed role, which Terraform uses to interact with resources in the Security Account. The Development Account does not need long-term credentials for the Security Account. Instead, it uses temporary credentials generated by the assumed role. See figure 6 below for details.

Fig 6: STS Test Session for the Terraform AssumedRole

Now that we have our developer environment set up, let’s get to the implementation proper.

Part A: Configure the Security Account

Set up a KMS Key:
- A KMS key is created in the security account to encrypt sensitive parameters stored in the SSM Parameter Store. This ensures that the parameters are protected at rest.
- Key rotation is enabled to enhance security by periodically updating the encryption key.
- The KMS key is configured to allow access only to authorized users and services, ensuring that only the intended accounts and roles can decrypt the parameters.

resource "aws_kms_key" "shared_params_key" {
  description             = "KMS key for shared parameters"
  deletion_window_in_days = 30
  enable_key_rotation     = true
  multi_region            = true
}

resource "aws_kms_alias" "shared_params_alias" {
  name          = "alias/${var.key_alias}"
  target_key_id = aws_kms_key.shared_params_key.key_id
}

resource "aws_kms_key_policy" "shared_params_key_policy" {
  key_id     = aws_kms_key.shared_params_key.key_id
  policy     = data.aws_iam_policy_document.shared_params_key_policy.json
  depends_on = [aws_kms_key.shared_params_key]
}

Fig 7: Terraform Plan for KMS Deployment

Create SSM Parameters:
- Parameters are stored in the SSM Parameter Store using the SecureString type, which ensures that the values are encrypted.
- The KMS key created earlier is associated with the parameters to provide encryption.
- Parameters are named using a consistent naming convention (e.g., /golden-ami/latest) to make them easily identifiable and manageable.

resource "random_string" "random_params" {
  length  = 8
  special = false
}

# Create SSM Parameter for AMI ID
resource "aws_ssm_parameter" "golden_ami" {
  name       = "/golden-ami/latest"
  tier       = "Advanced"
  type       = "SecureString"
  value      = "REPLACEPLEASE-${random_string.random_params.result}"
  key_id     = aws_kms_key.shared_params_key.key_id
  depends_on = [aws_kms_key.shared_params_key]

  lifecycle {
    ignore_changes = [value]
  }

  tags = {
    Environment = "shared"
    Purpose     = "Golden AMI Reference"
  }
}

Fig 8: Shared Parameter Deployed

Set Up RAM Resource Sharing:
- AWS Resource Access Manager (RAM) is used to share the SSM parameters with the development account.
- A RAM resource share is created, and the SSM parameter is added as a shared resource.
- The development account is specified as the principal in the resource share, granting it access to the shared parameter.
- This setup ensures that the parameter is securely shared without duplicating it in the development account.

# Create RAM Resource Share
resource "aws_ram_resource_share" "ssm_share" {
  name                      = "golden-ami-parameter-share"
  allow_external_principals = true

  tags = {
    Environment = "shared"
  }
}

# Associate SSM Parameter with RAM Share
resource "aws_ram_resource_association" "ssm_association" {
  resource_arn       = aws_ssm_parameter.golden_ami.arn
  resource_share_arn = aws_ram_resource_share.ssm_share.arn
}

# Share with Dev Account
resource "aws_ram_principal_association" "dev_shared_params" {
  principal          = var.dev_account_id
  resource_share_arn = aws_ram_resource_share.ssm_share.arn
}

Fig 9: Resource Shares Deployed

Part B: Configure the Development Account

Access the Shared Parameter:
- Terraform AssumedRole was used to retrieve the shared parameter value dynamically using its ARN, ensuring that the latest version of the parameter is always used and necessary IAM permissions were granted to access the shared parameter through the RAM resource share.

Fig 10: Shared Parameter Policy

Fig 11: Dev Account Trust Policy Updated

Validate the Shared Parameter in AWS RAM on Dev Account: In the Shared with me Resource shares on Dev Account, you should be able to see the resource share arn that is pointing to the /golden-ami/latest parameter stored in the RAM on Security Account.

Fig 12: Resource share Validation on Dev Account

Deploy Resources Using Shared Parameters: To test the retrieved parameter value, I updated the golden-ami value to one of the available AMI-ID in the US-West-2 region for demo purpose. This will correspond to the AMI-ID of the golden-image baked by the Security team in an enterprise setup. The retrieved parameter value was used by Terraform to deploy EC2 instances on Dev Account.

# Retrieve the shared SSM parameter
data "aws_ssm_parameter" "shared_ami" {
  name = "arn:aws:ssm:us-west-2:${local.security_account_id}:parameter/golden-ami/latest"
}

locals {
  security_account_id = "724604039557"
}
# Create EC2 instance using the shared AMI ID
resource "aws_instance" "web_instance" {
  ami           = data.aws_ssm_parameter.shared_ami.value
  instance_type = "t2.micro"

  tags = {
    Name        = "Fikol Instance"
    Environment = "dev"
  }
}

Fig 13: Shared Parameter Updated

Fig 14: Successful EC2 Instance Launched

Benefits of This Approach

Security: Parameters are encrypted and securely shared using AWS RAM.
Scalability: Easily extend the solution to share parameters with additional accounts or regions.
Centralized Management: Simplifies parameter management by consolidating it in a single account.
Automation: Terraform ensures consistent and repeatable deployments across accounts.
Cost Efficiency: Reduces duplication of resources by sharing parameters instead of recreating them in each account.

Possible Improvement for this implementation;

Configure OIDC role and deploy using GitHub Action (deploy using an OIDC secured CICD Pipeline)

Conclusion

This implementation demonstrates a secure and scalable way to share sensitive configuration data across AWS accounts using Terraform. By leveraging AWS SSM Parameter Store, RAM, and KMS, you can centralize parameter management while maintaining strict security controls.

5 Ways to maximize AWS re:invent as an ABW Grantee

Olumuyiwa Kolayemi — Sun, 09 Oct 2022 21:53:13 +0000

Congratulations to all the All Builders Welcome (ABW) grantees for this year’s AWS re:invent. Two of my mentees got the grant this year, and I’m super excited for them. For context, All Builders Welcome (ABW) grants is a program developed by AWS to provide assistance to the underrepresented groups in tech who are less than 5 years into their tech career journey, with the aim of fostering diversity and inclusion. The grant covers free re:Invent entry ticket that is worth $1,799, Airfare to Las Vegas, accommodation during the conference, 1 free voucher for AWS certification exam, and access to over 100 re:Invent contents - Keynotes and Leadership sessions, Technical workshops, and many other fun activities.

As a former ABW grantee, I can tell that this year grantees will have a lot of questions about how to make the most of this largest annual tech gathering. Well, I’ve got your back! I hope these few tips would be helpful to you as you plan ahead of your trip to Las Vegas in the last week of November.

Create re:Invent action plan.
Before the event, take advantage of the power of LinkedIn. Be active on LinkedIn and Twitter to know who will be attending the event in your network. You can send them a DM If you would like to connect with them at the event. After you have reached out to some folks in your network, make a list of those people you’ve connected with and people you want to meet. Review your list. Categorise the people on your list in 2 groups: “Must Meet” and “Nice to Meet”.
Travel light.
Yes, this is very important as you are packing your luggage. One thing to note is that Las Vegas is warm and not as cold as some other states in the US around this time of the year. So, you don’t need to pack a lot of bulky clothes. And remember to make room for swags. I’m sure the ABW team will emphasize this during their info session for the grantees.
When you arrive at the re:Invent, be your authentic self. Don't fake it. You might be standing in line for registration with your future hiring manager or CEO. So, be generous, and look for ways to strike up a conversation even while in line to grab your conference tag or food.
Show up early. This is the best time for you to connect with the organizers - ABW team, guests speakers and sponsors. Also, there might be some surprise gifts for people that get to those sessions early (keep it a secret 🤫)
Strategically position yourself for people to connect with you. You should ensure that you are standing next to the food and drinks table. People tend to be more relaxed and willing to connect when they have food or a drink in hand.

After all of this networking extravaganza, the only thing that will make the effort worth it is making sure that you follow up. I prefer LinkedIn messages because most people are probably overwhelmed with the hundreds of emails in their inbox already. If the people you connected with make a post about their experience at the re:Invent, make sure to comment and engage with their content. This will help you build your personal brand as well.

Finally, I would recommend that you try to register for Chalk Talk sessions and other reserved sessions that’s open to ABW grantees. I found Chalk Talk sessions the most educational. Overall, don’t try to do too much. Learn as much as you can, have as much fun as you can, and rest as much as you can.