Application Integration and Security at Full Sail University

This post covers my experience with Application Integration and Security at Full Sail University. This course stood apart from everything that came before it for a few reasons. It introduced Python, a language I had not touched anywhere in the degree, while simultaneously covering authentication patterns, vulnerability management, and secure cloud deployment. It also carried a two-strike policy, meaning it had to be passed within two attempts or the program ended. Coming directly off Project and Portfolio III and the full server-side block that preceded it, I had built real backend applications and shipped them to production. This course asked a different question: not whether I could build something that worked, but whether I understood what made it safe. Below is a breakdown of each week and what it contributed.

---

Week 1: Learning Python From Scratch

My thoughts at the time

Starting a new programming language mid-degree is a strange experience. I had spent months building fluency in JavaScript and TypeScript, and the first week of Python felt like learning to write with my non-dominant hand. The syntax was different in ways that were small enough to seem trivial but significant enough to constantly break my mental autopilot. Indentation as a structural requirement rather than a style preference was the adjustment that took the longest to internalize.

Once I pushed past the initial friction, Python started to feel surprisingly natural. The ability to print to the console and test small functions immediately made experimentation easy. Basic data types, variables, conditionals, loops, and functions in Python cover the same conceptual ground as JavaScript, but the way Python expresses them is clean in a way that grew on me quickly. By the end of the week I was writing functions that felt readable in a way that early JavaScript never quite did.

Retrospective insight

This week reinforced something that becomes more valuable the further into development you get: the underlying concepts of programming transfer across languages much more reliably than the syntax does. Once I accepted that I was not starting over but just switching notation, the learning curve shortened considerably. Python has shown up again in data-related and scripting work since this course, and having a working foundation from this week made each subsequent encounter noticeably easier.

---

Week 2: Authentication and Securing Application Interactions

My thoughts at the time

Week two shifted into authentication and the security challenges that come with applications communicating with each other. In Project and Portfolio III I had implemented JWT authentication end to end as part of the alumni networking app. That gave me a working implementation. This course gave me the framing for why it mattered. The question shifted from "how do I get tokens to work" to "what happens to users when the mechanism is wrong or missing."

The two-strike policy was at the back of my mind all week. It added a layer of urgency to the material that I am not sure was entirely negative. I was more deliberate about engaging with the concepts rather than moving through them quickly, and I asked more questions than I normally would have.

Retrospective insight

This week gave me a more complete mental model of authentication as a systems concern rather than just a user experience feature. Understanding how trust is established between services, how tokens are validated, and what happens when those mechanisms are missing or misconfigured has influenced how I think about security in every application I have built since. The pressure of the course format also left me with a more thorough understanding of the material than a lower-stakes week might have.

---

Week 3: Vulnerability Management and Security Frameworks

My thoughts at the time

Week three was the most conceptually broad week of the course. Analyzing source code using third-party scanners was a practical exercise I had not encountered before in the program. Running automated tools against real code and interpreting their output required a different kind of critical thinking than writing features does. The tools surfaced issues that I likely would not have noticed manually, which was humbling and useful in equal measure.

The discussion of security frameworks, audits, and regulations added context to the technical work. Understanding that there are established standards for how software should be secured and audited made the field feel more structured than I had previously appreciated. Security is not just a collection of individual techniques applied at the end of a project. It is a continuous process with defined frameworks for how that process should be conducted across all phases of the SDLC: planning, creating, testing, and deploying.

Retrospective insight

This week changed how I read code. Running vulnerability scanners and reviewing the results trained me to look at source code with a different question in mind: not just whether it works, but whether it could be exploited. That shift in perspective is persistent. I notice things in code reviews and in my own writing that I would have overlooked before this week. The awareness of security audits and regulatory frameworks also gave me a better understanding of why enterprise software development moves the way it does.

---

Week 4: Containerizing a Python Application and Deploying to AWS

My thoughts at the time

The final week brought everything together in a way that felt like the most complete practical exercise of the course. Converting the Python application to a containerized format and publishing it to AWS required pulling from multiple places at once. Docker containers had appeared in Server-Side Languages as the environment for MongoDB. The Cloud Application Development course had covered AWS infrastructure and tracking vulnerabilities in deployed containers. This week was the first time I had taken a Python application specifically through the full process of containerization and cloud deployment from start to finish.

Tracking container vulnerabilities in AWS was the part of the week that felt most directly connected to professional security work. The idea that deployment is not the end of security responsibility but the beginning of an ongoing monitoring obligation was a perspective shift I had not fully internalized before.

Retrospective insight

This week gave me a realistic picture of what secure DevOps looks like at the end of a development cycle. Shipping code is only one part of the responsibility. Understanding where to look for vulnerabilities in deployed containers, how to interpret what monitoring tools surface, and how to respond to identified issues are skills that continue to grow in relevance the more production-adjacent my work becomes. Getting through the two-strike course with a strong final week also felt like a meaningful checkpoint in the program: confirmation that the material had actually landed.

---

Closing Thoughts

Application Integration and Security was one of the most demanding courses in the program in terms of both breadth and stakes. Learning Python, working through authentication and vulnerability concepts, and shipping a containerized application to AWS all within four weeks under a two-strike policy created conditions that required real engagement with the material. The security mindset this course developed has had lasting influence on how I write and review code, and the Python foundation opened doors to types of work that would not have been accessible otherwise.

Credits and Collaboration

A huge thank you to Esther Allin for designing the blog banner art! If you're looking for a professional digital media specialist, Connect with her on LinkedIn!